Bajar un WordPress de producción a local implica más que copiar la base y uploads. Dominio, cachés, configuraciones, plugins que generan archivos y datos serializados pueden dejar una copia aparentemente correcta que carga a medias o falla de formas difíciles de rastrear. Importar un WordPress no es copiarlo. Es reconstruir su entorno sin arrastrar problemas del original.
La base de datos no es solo texto
Uno de los errores clásicos al mover WordPress es reemplazar el dominio viejo por el nuevo con un buscar y reemplazar directo sobre SQL. A veces funciona. A veces rompe datos serializados. WordPress y muchos plugins guardan configuraciones en estructuras serializadas donde también se almacena la longitud de cada valor. Si cambiamos una URL por otra de distinta longitud sin respetar esa estructura, el dato deja de ser válido.
Por eso conviene usar herramientas que entiendan cómo WordPress almacena esos valores. WP-CLI, por ejemplo, permite hacer un search-replace respetando datos serializados. El cambio de dominio deja de ser una operación de texto y pasa a ser una operación sobre datos.
Los uploads son la parte fácil
En la mayoría de los casos, copiar wp-content/uploads no tiene demasiado misterio. El problema aparece cuando el sitio depende de archivos generados, como el CSS de Elementor o las cachés.
Lo mismo ocurre con miniaturas, assets compilados por plugins, archivos temporales y configuraciones con rutas absolutas. No todo lo que vive dentro de wp-content merece copiarse tal cual: algunas cosas conviene traerlas, otras regenerarlas y otras deberían quedarse en producción.
Los plugins también tienen contexto
Un sitio local no necesita comportarse exactamente igual que producción. Plugins de caché, seguridad, CDN, backups o envío de correo pueden generar problemas innecesarios en desarrollo. WP Rocket, por ejemplo, puede dejar archivos y configuraciones pensados para producción que no aportan nada localmente.
Otros plugins pueden intentar conectarse a servicios externos, ejecutar sincronizaciones o mandar emails reales. Después de importar conviene revisar qué debería seguir activo. Una copia local no tiene que ser una réplica ciega. Tiene que ser un entorno seguro para trabajar.
Elementor necesita una atención extra
En sitios construidos con Elementor, mover la base de datos no siempre alcanza. El plugin genera CSS y otros archivos a partir de la configuración almacenada. Después de cambiar de dominio o entorno, puede ser necesario regenerar esos archivos para evitar estilos viejos, referencias incorrectas o componentes que parecen rotos sin estarlo realmente.
Muchas veces el sitio "importó bien". Lo que quedó viejo fue la capa generada encima.
Producción y local no deberían compartir servicios externos
Este punto es fácil de olvidar. Un WordPress importado puede conservar:
- Claves de APIs
- Credenciales SMTP
- Webhooks
- Integraciones con CRM
- Servicios de analítica
- Tareas programadas
- Endpoints de terceros
Si levantamos el sitio local tal como está, algunas de esas conexiones pueden seguir funcionando. Eso significa que una prueba local podría crear datos reales, enviar emails, disparar automatizaciones o modificar información en un sistema externo. Antes de empezar a trabajar conviene saber qué conexiones existen y cuáles deben bloquearse o reemplazarse.
El dominio local debería ser predecible
Cada proyecto debería tener una URL local estable. Algo como:
https://mi-sitio.localhost parece un detalle pequeño, pero ayuda a que el entorno sea repetible. Si además usamos HTTPS válido, evitamos diferencias con producción en cookies seguras, redirecciones, recursos mixtos y servicios que esperan una conexión cifrada. Cuanto más parecido sea el comportamiento básico entre local y producción, menos sorpresas aparecen después.
Importar debería ser una operación repetible
Si copiar un sitio requiere una lista mental de quince pasos, tarde o temprano alguien va a olvidar uno. La operación incluye exportar, crear la base y copiar los archivos, entre otras tareas.
También hay que cambiar el dominio, corregir la serialización, desactivar la caché, regenerar CSS, bloquear emails y revisar servicios externos. Todo eso puede documentarse y gran parte puede automatizarse.
El objetivo no es solamente ahorrar tiempo en la primera importación. Ese flujo repetible también forma parte de un entorno WordPress bien resuelto sobre WSL2. Es poder hacerla de nuevo seis meses después sin depender de recordar exactamente qué hicimos la vez anterior.
Un sitio local debería quedar listo para romperse
Ese es, en parte, el objetivo. Local es donde podemos actualizar un plugin, modificar una integración, cambiar datos o probar una migración sin miedo a afectar usuarios reales. Pero para que eso sea cierto, la copia tiene que estar aislada de producción y suficientemente completa como para que las pruebas tengan sentido.
No necesitamos una réplica perfecta. Necesitamos una réplica útil. Traer el sitio es el primer paso. La importación termina cuando la copia está aislada, es repetible y sirve para probar cambios con confianza.