Migraciones de WordPress
Una migración es la operación más barata de hacer bien y la más cara de hacer mal.
Bien hecha, el visitante no se entera: el jueves el sitio está en un servidor y el viernes está en otro, con las mismas direcciones respondiendo lo mismo. Mal hecha, seis semanas después el tráfico está a la mitad, nadie sabe por qué, y recuperarlo cuesta tres veces lo que habría costado prepararlo.
La diferencia entre las dos no está en la herramienta. Casi cualquier plugin de migración copia archivos y base de datos razonablemente bien. La diferencia está en lo que se hace antes de copiar nada: el inventario de lo que existe, el mapa de a dónde va cada dirección, y la decisión de qué se queda fuera.
Qué tipo de migración necesitas
No todas son el mismo trabajo ni el mismo riesgo. Esto es lo que cambia:
| Tipo | Qué cambia | Riesgo para el posicionamiento | Lo que define el trabajo |
|---|---|---|---|
| Cambio de hosting | El servidor. Las URLs se quedan igual | Bajo, si se hace con orden | DNS, certificado, versión de PHP, correo. Google no tiene que mover nada |
| Cambio de dominio | El dominio completo | Alto | Redirecciones de todo, herramienta de cambio de dirección, señales que hay que transferir |
| Cambio de estructura de URLs | Los enlaces permanentes, las categorías, el idioma de los slugs | Alto | Mapa uno a uno. Es donde más tráfico se pierde y donde menos se espera |
| HTTP a HTTPS | El protocolo | Medio | Contenido mixto, canónicas, redirecciones. No se usa la herramienta de cambio de dirección |
| De otra plataforma a WordPress | Todo | Alto y distinto | Lo que se puede exportar del origen. Es lo que decide el proyecto entero → de Wix a WordPress |
| Unificación de dominios | Dos sitios se convierten en uno | Alto | Decidir qué URL gana en cada solape, y qué se consolida |
| A un entorno nuevo con rediseño | Diseño y a veces estructura | Alto | Son dos proyectos a la vez, y conviene separarlos → rediseño sin perder posicionamiento |
La primera fila es la que la mayoría de la gente cree que está contratando. Las demás son las que de verdad traen problemas, y conviene saber en cuál estás antes de empezar.
Dime qué va a cambiar y te digo en qué fila estás. Mándame por WhatsApp el dominio actual y qué tienes previsto mover: servidor, dominio, estructura o plataforma. Con eso te digo el riesgo real antes de que contrates nada.
Un cambio de hosting no debería costarte tráfico
Si las URLs no cambian, Google no tiene que mover nada. Esto es importante porque mucha gente contrata una preparación SEO para un cambio de servidor que no la necesita, y mucha otra pierde tráfico en un cambio de servidor por descuidar cuatro cosas que no son SEO. Lo que documenta Google para este caso:
Bajar el TTL del DNS una semana antes
A un valor conservadoramente bajo, al menos una semana antes. Así las cachés de los proveedores se refrescan rápido cuando llegue el cambio. Es gratis y es la diferencia entre un cambio limpio y dos días de visitantes repartidos entre dos servidores.
Probar el sitio nuevo de verdad antes de apuntar el dominio
Con un nombre temporal y noindex si hace falta. Y comprobar que el rastreador de Google llega: que el cortafuegos o la protección contra ataques no lo esté bloqueando, cosa que pasa más de lo que parece con los hostings con seguridad agresiva.
Quitar los bloqueos temporales antes de apuntar el DNS
El noindex o el Disallow del entorno de pruebas que viaja a producción es el error más común y el más caro de todos los que se cometen en una migración.
Vigilar los dos servidores hasta que el viejo llegue a cero
Y solo entonces apagarlo. Antes, no.
No asustarse con la bajada de rastreo
Google dice que el ritmo de rastreo puede caer justo después del cambio y recuperarse en los días siguientes, incluso superando el nivel anterior. Es normal, salvo que haya errores serios o lentitud.
Lo que Google no cubre y rompe migraciones de hosting igual: la versión de PHP del servidor nuevo, el correo saliente (que casi nunca viaja con el sitio), los certificados, las tareas programadas y las rutas absolutas guardadas en la base de datos.
Lo que se hace antes de mover nada
Son cinco trabajos y todos van antes.
El inventario
La lista real de URLs que existen y tienen valor: del sitemap, de Search Console con histórico, de los logs del servidor y de un rastreo propio. Las cuatro fuentes, porque ninguna está completa sola. Sin este inventario no se puede comprobar después si algo se quedó fuera, y esa comprobación es la única prueba de que la migración salió bien.
El mapa de redirecciones
URL vieja a URL nueva, una a una, en una hoja de cálculo que puedas auditar. Lo que no tiene equivalente se decide a mano: se recrea, se consolida o se cierra con un 410. Lo que no se hace es mandarlo todo a la portada — Google documenta que redirigir muchas URLs a un destino irrelevante puede tratarse como soft 404, con lo cual no se transfiere nada.
La preparación SEO
Es el trabajo que te ahorra la reparación posterior, y consiste en cosas aburridas: limpiar las cadenas de redirección que ya arrastras de migraciones anteriores, resolver los duplicados antes de arrastrarlos al sitio nuevo, verificar las propiedades de Search Console del origen y del destino antes de necesitarlas, y guardar una copia del sitemap y del inventario para poder comparar después.
La decisión de qué no viaja
Toda migración es una oportunidad de dejar atrás lo que no sirve, y toda migración mal planteada arrastra la basura al sitio nuevo. Lo que se queda fuera se decide con datos de tráfico, por escrito, antes de mover — no a mitad del proceso.
La ventana y el plan de vuelta
A qué hora, quién avisa a quién, y qué se hace si a las dos horas algo va mal. Una migración sin plan de vuelta atrás es una apuesta, no un proyecto.
Cuánto tarda Google en asimilar el cambio
Esto es lo que más ansiedad genera y lo que menos se explica, así que va con los números de Google: cuando cambian las URLs, para un sitio pequeño o mediano puede llevar unas semanas que la mayoría de las páginas se muevan; los sitios grandes tardan más. La velocidad depende del número de URLs y de la velocidad del servidor, y enviar un sitemap ayuda. La visibilidad fluctúa durante el proceso y las posiciones se asientan con el tiempo.
Cuando no cambian las URLs, no hay nada que asimilar: solo la bajada temporal del ritmo de rastreo que se recupera en días.
Vas a migrar y quieres hacerlo con red. Pide el diagnóstico técnico: sales con el inventario de URLs con su tráfico histórico, el mapa de redirecciones propuesto y la lista de lo que conviene dejar fuera. Por escrito y es tuyo, lo migres con quien lo migres.
Cómo trabajamos
| Fase | Qué se hace | Qué recibes |
|---|---|---|
| 1 · Inventario y auditoría | Las cuatro fuentes de URLs, estado de redirecciones heredadas, duplicados, versiones de PHP y plugins, correo y tareas programadas | Inventario con tráfico histórico y lista de problemas a resolver antes de mover |
| 2 · Mapa y decisiones | Mapa de redirecciones uno a uno y decisión escrita de lo que no viaja | Hoja de cálculo auditable, aprobada por ti antes de tocar nada |
| 3 · Montaje y pruebas | Sitio completo en el destino, con bloqueo de indexación, y pruebas reales: formularios, pagos, correo, tareas programadas | Informe de pruebas con lo que funciona y lo que falta |
| 4 · Ventana de cambio | TTL bajado con antelación, cambio de DNS o publicación, retirada de bloqueos, redirecciones activas desde el primer minuto | Confirmación de respuesta y saltos, URL por URL |
| 5 · Verificación | Comparación del inventario contra el sitio nuevo, URL por URL. Herramienta de cambio de dirección cuando aplica. Sitemap nuevo enviado | Informe de cobertura: qué responde, qué redirige, qué falta |
| 6 · Vigilancia de tres meses | Cobertura, posiciones de las URLs clave, errores nuevos, corrección sobre la marcha | Informe mensual con la curva |
La fase 5 es la que convierte esto en un trabajo verificable. Una migración que no se compara contra el inventario previo no está terminada: está entregada.
Lo que hace falta de tu lado: accesos al origen y al destino, Search Console con permiso de propietario, acceso a los logs si el hosting los da, y una persona que pueda decidir en la fase 2 qué contenido no viaja. Ese último punto es el que más retrasa migraciones, y conviene saberlo desde el principio.
Lo que no hacemos: mover un sitio a un servidor que no lo va a soportar. Si el destino que elegiste no da la versión de PHP, los recursos o los logs que el sitio necesita, lo digo antes de empezar y no acepto el trabajo a medias. No vendo el hosting: te digo qué necesitas y lo contratas donde quieras.
Aquí van dos migraciones con volumen: una industrial con web multiidioma y un medio con archivo de años. El número de URLs y el resultado de la verificación es lo que convierte esta página en una referencia.
Lo que viene en 2027
La comparación del antes y el después se va a volver más difícil. Desde junio de 2026 el tráfico de AI Mode está mezclado en el informe de rendimiento de Search Console bajo el tipo "Web", sin filtro propio, y los informes de IA generativa que Google lanzó el 3 de junio de 2026 reportan impresiones pero no clics. Si migras en 2027 y comparas contra 2026, la composición del tráfico ya no es la misma. Para una migración eso significa una cosa práctica: el inventario de la fase 1 hay que guardarlo con sus cifras, porque dentro de seis meses el panel no te va a dejar reconstruirlas.
El rendimiento va a pesar más en cada migración. Con INP midiendo la peor latencia de respuesta de toda la visita, un sitio nuevo con un constructor más pesado puede medir peor que el viejo aunque se vea mejor. Si la migración incluye cambio de tema o de constructor, conviene medir antes y después en lugar de dar por hecho que lo nuevo es más rápido.
Y las plataformas cerradas van a seguir siendo el caso más difícil. Lo que puedes sacar de una plataforma propietaria lo decide la plataforma, no tú, y esa decisión cambia sin aviso. Quien migra hoy de una de ellas se encuentra límites que no existían hace dos años y otros que desaparecieron. Es la razón por la que ese caso tiene página propia y por la que la revisamos cada trimestre.
Preguntas frecuentes
Si solo cambias de servidor y las URLs se quedan igual, no deberías: Google no tiene que mover nada. Si cambian las direcciones, la pérdida temporal es normal durante unas semanas y la pérdida permanente es evitable — depende enteramente de que el mapa de redirecciones esté completo.
El trabajo técnico depende del tamaño y del estado del origen, y lo doy por escrito. Lo que no depende de mí es lo que tarda Google: unas semanas para la mayoría de las páginas en sitios pequeños y medianos cuando cambian las URLs, y la visibilidad fluctúa mientras tanto.
Sí. Se monta completo en el destino, se prueba, y la ventana de cambio es el momento en que se apunta el DNS. Con el TTL bajado una semana antes, la transición es de minutos. Lo que sí conviene es elegir una hora de poca actividad.
Copia archivos y base de datos, y normalmente bien. Lo que ningún plugin hace es el inventario, el mapa de redirecciones, la decisión de qué no viaja y la verificación posterior. Ahí es donde se pierde el tráfico, y ahí es donde está el trabajo.
Google dice que se mantengan al menos un año, y mantenerlas indefinidamente es válido. Mi recomendación es no quitarlas nunca mientras no cuesten nada: lo que sí conviene es actualizar tus propios enlaces internos y pedir a los sitios que más te enlazan que apunten a la dirección nueva, para que las redirecciones dejen de usarse por desuso y no por borrado.
Se planifica aparte y se avisa antes, porque es el punto que más sustos da. El correo rara vez viaja con el sitio, y apuntar el DNS sin haber resuelto los registros de correo deja a una empresa sin recibir mensajes sin que nadie lo note durante horas.
Se puede, pero conviene separar las dos cosas en el tiempo. Si cambian las direcciones y el diseño a la vez y el tráfico baja, no vas a saber cuál de las dos cosas lo causó. Si el rediseño es el objetivo principal, empieza por rediseño sin perder posicionamiento.
Esta es para antes. Si ya pasó, lo que necesitas es recuperar el tráfico perdido tras la migración, que es un trabajo distinto y empieza por reconstruir el inventario que nadie guardó.
Elige por dónde entrar
Vas a migrar y quieres saber en qué te estás metiendo. Mándame por WhatsApp el dominio actual y qué va a cambiar: servidor, dominio, estructura o plataforma. Te digo el riesgo real y qué preparación necesita.
Escribir por WhatsAppQuieres el plan completo antes de comprometerte. El diagnóstico técnico se paga y se entrega: inventario de URLs con tráfico histórico, mapa de redirecciones propuesto y lista de lo que conviene dejar fuera.
Pedir el diagnóstico técnicoYa tienes decidido el destino y quieres presupuesto. Dime el dominio, cuántas URLs tiene, a dónde va y si cambian las direcciones. Te mando propuesta con fases y ventana de cambio.
Solicitar propuestaÚltima revisión: octubre de 2026.