Cómo Migrar WordPress sin Perder SEO ni Downtime

Migrar WordPress da miedo por dos razones concretas: perder el posicionamiento que ha costado meses o años construir, y que la web quede caída durante la transición justo cuando un cliente intenta visitarla. Ambos riesgos son reales, pero evitables con el proceso técnico correcto.

Esta guía te da los pasos exactos, con los comandos necesarios, para migrar sin ninguno de los dos sustos.

Para el panorama general de cuándo y por qué migrar, parte de Migración y Cambio de Hosting o Agencia en WordPress.

La preparación: todo lo que haces antes de tocar el DNS

La regla mental de toda esta guía es sencilla: el DNS se toca al final, no al principio. Todo el trabajo de copiar, importar y probar se hace mientras el tráfico real sigue yendo al servidor antiguo. Cuando por fin cambias el DNS, ya sabes que el destino funciona porque lo has verificado tú antes.

Backup completo y verificado

Antes de cualquier otra cosa, un backup completo de archivos y base de datos, verificado (no solo generado). El detalle de cómo hacerlo bien está en Backups y Recuperación de WordPress: Guía Completa. “Verificado” significa que has comprobado que el archivo abre y que la base de datos no está truncada, no solo que el plugin de backup dijo “completado”.

Anota la zona DNS actual entera, no solo el registro web

Este es el paso que más gente se salta y el que más caro sale. Antes de tocar nada, documenta todos los registros DNS actuales, no solo el A que apunta la web:

A / AAAA: la IP del servidor web.
MX: quién recibe tu correo. Si está en un proveedor distinto del hosting web (muy habitual), moverlos por error deja a la empresa sin email.
TXT de SPF, DKIM y DMARC: la autenticación del correo. Perderlos hace que tus emails caigan en spam.
CNAME: subdominios y verificaciones de servicios externos.

Migrar la web sin conservar el correo es el error más frecuente y el más doloroso. Copia la zona entera a un documento antes de empezar.

Documenta la estructura de URLs actual

Genera un listado completo de las URLs existentes de tu web, la mayoría de plugins de SEO o herramientas de rastreo pueden exportarlo automáticamente. Es tu red de seguridad para configurar redirecciones tras la migración, y tu lista de comprobación para revisar que ninguna página importante devuelve error después del cambio.

Prepara el entorno de destino sin activarlo aún

Configura el nuevo hosting completamente (WordPress instalado, dominio configurado a nivel de servidor) sin apuntar el DNS real todavía. Esto te permite probar sin ningún riesgo para el tráfico actual. Deja también preparado el certificado SSL en el destino para que no haya una ventana con el candado roto justo tras el cambio.

El traslado técnico

Copiar archivos y base de datos

Transfiere los archivos de WordPress (núcleo, plugins, tema, medios) al nuevo servidor, y exporta/importa la base de datos completa. La carpeta que más pesa es casi siempre wp-content/uploads (los medios); planifica ese trasvase con margen. Revisa además que la versión de PHP del nuevo servidor sea igual o superior a la del antiguo: bajar de versión de PHP es una fuente clásica de errores tras migrar.

Actualizar las referencias de URL si el dominio cambia

Si migras también de dominio (no solo de hosting), las URLs guardadas en la base de datos deben actualizarse. Antes del cambio real, hazlo en seco (--dry-run) para ver cuántas coincidencias tocará sin modificar nada:

wp search-replace 'https://dominio-antiguo.com' 'https://dominio-nuevo.com' --dry-run

Si el recuento tiene sentido, ejecútalo de verdad. WP-CLI maneja correctamente los datos serializados de PHP (los _meta y opciones que guardan longitudes de cadena), algo que un buscar-y-reemplazar directo en SQL rompería:

wp search-replace 'https://dominio-antiguo.com' 'https://dominio-nuevo.com' --skip-columns=guid --path=/ruta/al/wordpress

El --skip-columns=guid es importante: el campo guid identifica cada entrada ante los lectores RSS y no debe cambiarse aunque contenga el dominio antiguo. Si solo cambias de hosting manteniendo el mismo dominio, este paso no es necesario.

Probar en el nuevo entorno antes de cambiar el DNS

Antes de apuntar el tráfico real al nuevo servidor, verifica que todo funciona modificando temporalmente el archivo hosts de tu propio ordenador (no el DNS público), lo que te permite ver la web en el nuevo servidor sin que ningún otro visitante lo note aún:

# Archivo hosts local (solo en tu equipo, no en el servidor)
123.45.67.89    tudominio.com
123.45.67.89    www.tudominio.com

Con estas líneas, tu navegador resolverá tudominio.com hacia el nuevo servidor mientras el resto del mundo sigue viendo el antiguo. En Windows el archivo está en C:\Windows\System32\drivers\etc\hosts; en macOS y Linux, en /etc/hosts. Recuerda quitar esas líneas al terminar, o seguirás viendo el servidor viejo tú solo y creerás que la propagación falla.

Con el hosts apuntando al destino, recorre la web como un cliente: portada, una entrada, el buscador, un formulario y (si vendes) una compra de prueba. Es mucho más barato encontrar aquí un plugin que no arrancó que descubrirlo con el tráfico real encima.

El cambio de DNS sin downtime perceptible

Reduce el TTL con antelación

Al menos 24-48 horas antes de la migración, reduce el TTL (tiempo de vida) de tus registros DNS a un valor bajo (por ejemplo, 300 segundos). Esto hace que, cuando cambies el DNS de verdad, la propagación sea mucho más rápida. El motivo es que el TTL le dice a los resolutores cuánto tiempo pueden cachear la respuesta antigua; si estaba en 24 horas y lo cambias en el último momento, muchos seguirán sirviendo el valor viejo hasta que expire su caché. Por eso el TTL se baja antes, no a la vez que el cambio.

El cambio en sí: qué registro tocar

Cuando el destino está probado y el TTL lleva un día bajo, el cambio real es tan simple como actualizar el registro A (y www) hacia la IP del nuevo servidor. Si migras solo la web y el correo se queda donde estaba, esta es la regla de qué tocar:

Registro DNS	¿Se toca al migrar solo la web?
`A` / `AAAA` (web)	Sí: a la IP del nuevo servidor
`www` (CNAME o A)	Sí: igual que el registro `A`
`MX` (correo)	No
`TXT` SPF / DKIM / DMARC	No
Servidores de nombres (NS)	No: cambiarlos mueve toda la zona, correo incluido

Por eso se apunta un registro concreto y no se “cambian los servidores de nombres” a la ligera.

Sincroniza el contenido durante la transición

Durante las horas de propagación, cada visitante puede caer en el servidor viejo o en el nuevo. Para una web de contenido, lo más sencillo es acordar una ventana de congelación editorial: no publicar durante las pocas horas que dura la propagación con el TTL bajo, para que ningún contenido nuevo quede solo en uno de los dos servidores. En una tienda con pedidos constantes esto se complica y conviene una estrategia de sincronización o de modo mantenimiento; lo tratamos en Backup de WooCommerce sin Perder Pedidos.

Verifica la propagación

Usa herramientas de verificación de propagación DNS para confirmar cuándo el cambio se ha completado globalmente. Desde tu propio equipo puedes comprobar hacia dónde resuelve el dominio:

dig +short tudominio.com

Cuando la mayoría de ubicaciones devuelven ya la IP nueva, la propagación está prácticamente completa. Aun así, no des de baja el servidor antiguo el mismo día: mantenlo activo al menos una semana, porque mientras algún resolutor rezagado siga apuntando al viejo, esa copia debe seguir sirviendo la web.

Preservar el SEO: la parte que no debes saltarte

Mantén las mismas URLs siempre que sea posible

Si la estructura de URLs no cambia, el impacto en SEO de una migración de hosting bien hecha es prácticamente nulo, Google sigue viendo el mismo contenido en las mismas direcciones. Una migración de solo-hosting (mismo dominio, mismas URLs) es, de hecho, casi invisible para el buscador.

Fuerza HTTPS y una sola versión canónica

Un descuido típico tras migrar es acabar con la web accesible por varias direcciones a la vez (http://, https://, con www y sin www). Para Google eso son URLs distintas del mismo contenido, y diluye el SEO. Deja una sola versión canónica y redirige el resto hacia ella con 301: todo el http hacia https, y una única variante de dominio (la que ya usabas).

Configura redirecciones si algo cambia

Si por cualquier motivo alguna URL sí cambia, configura una redirección 301 (permanente) desde la antigua hacia la nueva. Sin esta redirección, Google trata la nueva URL como contenido completamente distinto, perdiendo el valor SEO acumulado en la antigua. Usa siempre 301 (permanente), nunca 302 (temporal): la 302 no traspasa el valor SEO porque le dice a Google que la antigua volverá.

Actualiza el sitemap y notifica a Search Console

Tras confirmar que la migración está completa, actualiza el sitemap.xml si es necesario y reenvíalo desde Google Search Console para acelerar el re-rastreo. Vigila el informe de cobertura los días siguientes por si aparecen errores 404 o de rastreo que no esperabas.

Pruebas post-migración: qué comprobar antes de cantar victoria

Que la portada cargue no significa que la migración esté bien. Antes de dar de baja el servidor antiguo, recorre esta comprobación con el DNS ya apuntando al destino:

Funcionalidad: portada, varias entradas y páginas internas, menús, buscador interno.
Formularios: envía uno de contacto de prueba y confirma que el correo llega de verdad al buzón. El email saliente es lo que más falla al cambiar de servidor.
Enlaces permanentes: si al abrir una entrada interna sale un error 404, casi siempre faltan las reglas de reescritura; regenéralas guardando de nuevo los enlaces permanentes en los ajustes de WordPress.
Medios e imágenes: que se vean (rutas rotas = uploads mal copiado o URLs sin reemplazar).
HTTPS: candado correcto en todas las páginas, sin avisos de contenido mixto.
Panel y errores del servidor: edita y guarda una entrada; revisa que no haya errores 500 en el log tras el cambio de versión de PHP.

Si vendes online, añade una compra de prueba de principio a fin (carrito, pago, correo de confirmación); el detalle está en Cómo Actualizar WooCommerce sin Romper el Checkout.

Ten preparado el plan de reversión

El botón de marcha atrás es lo que te permite hacer el cambio sin nervios, y es muy simple si respetaste dos reglas: no diste de baja el servidor antiguo y mantuviste el TTL bajo. Si algo grave se tuerce, vuelves a apuntar el registro A a la IP del servidor viejo y, con el TTL bajo, en minutos el tráfico regresa al entorno que funcionaba. Por eso la baja del servidor antiguo es siempre el último paso.

Checklist técnico de migración sin downtime

Preguntas Frecuentes

¿Es posible una migración con cero minutos de downtime? Sí, si se prueba completamente el nuevo entorno antes del cambio de DNS y se reduce el TTL con antelación, el usuario final no debería notar ninguna interrupción.

¿Cuánto tarda en propagarse un cambio de DNS? Con el TTL reducido previamente, puede completarse en minutos; sin esa preparación, puede tardar hasta 24-48 horas en propagarse globalmente.

¿Necesito herramientas especiales para probar el nuevo entorno antes del cambio de DNS? No, modificar el archivo hosts de tu propio ordenador es suficiente y no requiere ninguna herramienta adicional, aunque existen plugins que facilitan URLs de prueba temporales.

¿Qué pasa si publico contenido nuevo durante la migración? Si no sincronizas ambos entornos durante la transición, ese contenido puede perderse o quedar solo en uno de los dos servidores, lo ideal es evitar publicar contenido nuevo justo durante la ventana de migración.

¿Perderé mi posicionamiento si cambio de hosting pero mantengo el mismo dominio y URLs? El impacto debería ser mínimo o nulo, ya que Google identifica el contenido por dominio y URL, no por la infraestructura de hosting subyacente.

¿wp search-replace es seguro de ejecutar directamente en producción? Es más seguro ejecutarlo en el nuevo entorno antes de activarlo como producción, con backup previo, en lugar de ejecutarlo sobre la web ya en producción y en uso activo.

¿Debo migrar plugins y temas o reinstalarlos desde cero en el nuevo hosting? Migrar los mismos archivos garantiza que la configuración específica se mantenga intacta; reinstalar desde cero requeriría reconfigurar cada plugin manualmente.

¿Cómo verifico que la migración fue exitosa antes de eliminar el servidor antiguo? Verifica funcionalidad completa (contenido, formularios, checkout), rendimiento, y posicionamiento en Search Console durante al menos una semana antes de dar de baja definitivamente el hosting anterior.

Migro la web pero el correo se queda donde está. ¿Qué DNS toco? Solo el registro A (y www) hacia la IP del nuevo servidor. Deja intactos los MX y los TXT de SPF/DKIM/DMARC. El error clásico es “cambiar los servidores de nombres” en lugar de un registro concreto: eso mueve toda la zona de golpe y arrastra el correo sin querer.

Tras migrar, las entradas internas dan error 404 pero la portada carga. ¿Qué pasa? Casi siempre son las reglas de enlaces permanentes que no se han regenerado en el nuevo servidor. Entra en los ajustes de enlaces permanentes de WordPress y guarda de nuevo sin cambiar nada: eso reescribe las reglas y suele resolverlo al instante.

¿Por qué usar --skip-columns=guid en el search-replace? Porque el campo guid es el identificador único de cada entrada para los lectores de RSS y no debe cambiar nunca, aunque contenga el dominio antiguo. Si lo reemplazas, los agregadores pueden tratar todas tus entradas como nuevas. Reemplaza el dominio en todo salvo esa columna.

¿Cuánto tiempo debo mantener vivo el servidor antiguo? Al menos una semana. Mientras algún resolutor DNS rezagado siga apuntando al viejo por caché, esa copia tiene que seguir sirviendo la web para que nadie vea un error. Además, es tu plan de reversión inmediato si algo falla: solo funciona si el servidor antiguo sigue en pie.

Conclusión

Una migración sin perder SEO ni sufrir downtime no depende de suerte, depende de probar todo en el nuevo entorno antes de tocar el DNS, reducir el TTL con antelación, y mantener las mismas URLs o redirigir correctamente las que cambien. Con ese proceso, migrar deja de ser un salto al vacío.

Si prefieres que gestionemos nosotros este proceso técnico completo, en Avantys lo llevamos como parte de Gestión WordPress.