Cómo migrar tu WordPress a otro hosting sin perder posiciones en Google
Prepará una migración de WordPress con respaldo de archivos y base, ensayo de restauración, pruebas en staging y un plan de retorno antes de cambiar DNS.
Mover una instalación de WordPress implica trasladar archivos y base de datos, comprobar compatibilidad y coordinar el cambio de DNS. Este recorrido prioriza recuperar el sitio si algo falla. Una lista de pasos no garantiza conservar posiciones ni evitar toda interrupción.
Antes de iniciar, cotejá el entorno de destino con el comparador de requisitos WordPress y revisá los requisitos oficiales de WordPress.org vigentes el día de la mudanza. El comparador no evalúa velocidad, seguridad integral ni proveedores.
1. Inventario y respaldo coordinado
Anotá dominio y variantes, URLs, versión de WordPress, PHP y motor de base, tema y plugins activos, formularios, correo y servicios vinculados. Registrá los DNS actuales y quién controla la zona. Hacé una copia reciente de los archivos y un dump de la base como un mismo conjunto, guardalos fuera del servidor de origen y conservá el original sin cambios. WordPress explica por qué ambos componentes hacen falta para una restauración completa.
2. Compatibilidad y staging protegido
Confirmá las versiones y extensiones disponibles en el destino y comparalas con lo que usa el sitio, incluidos tema y plugins. Revisá límites de almacenamiento/subida, tareas programadas y acceso al panel. Las recomendaciones de WordPress.org cambian; verificá la página oficial el día de la mudanza, sin tratar una versión recomendada como garantía de compatibilidad del sitio.
Restaurá una copia en staging. Protegela con autenticación HTTP o restricción de acceso y evitá que buscadores indexen la copia. Si aplicás noindex, no bloquees el rastreo que necesita leerlo. Antes de habilitar la versión pública, retirale autenticación y directivas de no indexación al entorno de producción; dejá el staging aislado.
3. Ensayo de restore y lista de verificación
Importá el dump en el motor compatible y recuperá los archivos. Verificá que WordPress arranque, que funcione el acceso de administración, que carguen imágenes y páginas internas, y que operen formularios y funciones importantes. Si cambia el dominio, tratá las URLs con una herramienta que respete datos serializados; hacé dry run y guardá la base antes de aplicar reemplazos.
| Comprobación | Seguí si… | Detené el corte si… |
|---|---|---|
| Archivos y base recuperados | Se pueden leer/importar y el sitio usa la base esperada. | Falta un archivo, la importación informa errores o hay dudas sobre la copia. |
| Staging protegido | Administración, páginas clave, medios y funciones necesarias pasan pruebas. | Hay errores persistentes, datos ausentes, formularios o compras que no funcionan. |
| DNS y HTTPS | Los registros nuevos son correctos, el certificado corresponde y las URLs responden. | El dominio resuelve a un destino inesperado o HTTPS genera alertas. |
| Datos durante el corte | Se definió pausa o sincronización final para pedidos, cuentas y formularios. | Ambos sitios aceptarían escrituras divergentes sin reconciliación. |
4. Corte DNS con retorno previsto
Guardá los registros DNS anteriores y definí quién los puede volver a cargar. Revisá con anticipación el TTL; bajarlo puede ayudar a reducir cachés largas, pero no hace que todos los resolvers cambien al mismo tiempo. No supongas que volver al valor anterior es inmediato: durante un tiempo algunos visitantes pueden seguir llegando a un destino cacheado.
Cuando las pruebas estén aprobadas, actualizá solo los registros necesarios. Conservá el origen funcionando y sin borrar respaldos. Comprobá resolución desde más de una red, HTTPS, páginas clave y envíos. Para un sitio que recibe cambios, pausá escrituras o sincronizá el contenido final antes del corte y definí cuál instalación acepta datos nuevos.
5. Si necesitás revertir
Si aparece una falla crítica, volvé a cargar los registros de origen que guardaste y mantené ambos entornos disponibles mientras expiran las cachés DNS. Eso solicita una reversión; no garantiza que todos los visitantes vuelvan inmediatamente al servidor anterior. Evitá aceptar cambios en ambas bases a la vez. Identificá qué datos se escribieron en cada entorno y concilialos antes de reabrir el servicio.
Qué mostró una prueba local acotada
El 3 de octubre se ejecutó una prueba reproducible con datos inventados, fuera de WordPress: se modificó y restauró un archivo, cuyo SHA-256 restaurado coincidió con el previo (04007f63530244c994c0c9062a3c005a1a5dbc6bb079e4f219d6c6e1a31455e0). También se hizo rollback de una fila ficticia en SQLite; la consulta final devolvió (157, 'HostIN fixture before', 'publish'). Esos valores pertenecen a la fixture sintética y no a un artículo ni a un sitio real. El ejercicio no usó WordPress, MySQL/MariaDB, plugins, DNS ni datos de producción. Sirve para mostrar qué se verificó en esa práctica; para acreditar una migración hace falta ensayar un restore coordinado de archivos y base en staging con la plataforma y motor correspondientes.
La documentación oficial de backup y migración de WordPress complementa esta checklist. Adaptá cada paso al tamaño, actividad y configuración de tu sitio.