Una migración web es un cambio de fondo en tu sitio que afecta a cómo lo encuentran y lo entienden los buscadores: un dominio nuevo, el paso a HTTPS, otro CMS, otra estructura de URL, un rediseño o un cambio de alojamiento. Para hacerla sin perder posicionamiento SEO tienes que inventariar las URL que hoy traen visitas y enlaces, redirigir cada una que cambie, con una redirección permanente (301), a su equivalente en la web nueva, probarlo todo antes de publicar y vigilar Search Console durante las semanas siguientes.
Google avisa de que las posiciones pueden fluctuar mientras vuelve a rastrear e indexar la web, de que en un sitio pequeño o mediano el paso de la mayoría de las páginas a las URL nuevas suele llevar varias semanas y de que conviene hacer los cambios de uno en uno, no todos a la vez.
¿Qué es una migración web y cómo afecta al SEO?
En SEO, una migración es un cambio estructural de la web que obliga a Google a volver a rastrear, entender y colocar sus páginas. Google distingue dos grandes casos en su documentación: los traslados con cambios de URL, como pasar a HTTPS, cambiar de dominio o reorganizar las rutas, y los cambios de alojamiento sin cambios de URL, como mudarse a otro proveedor o a una red de distribución de contenido (CDN).
Tipos de migración web
El riesgo varía mucho de un caso a otro, y lo que más pesa es si cambian las URL: Google tiene que descubrir cada dirección nueva y relacionarla con la antigua para trasladarle sus señales. Esta tabla resume los casos más habituales y cuándo hace falta la herramienta Cambio de dirección de Search Console:
| Tipo de migración | Ejemplo | ¿Cambian las URL? | ¿Cambio de dirección en Search Console? |
|---|---|---|---|
| Cambio de alojamiento o CDN | El mismo dominio, en otro servidor | No | No |
| De HTTP a HTTPS | http://example.com → https://example.com | Sí | No |
| De www a sin www, o al revés | www.example.com → example.com | Sí | No |
| Cambio de dominio o de subdominio | example.com → example.net | Sí | Sí |
| Cambio de estructura de URL | /p.php?id=7 → /zapatillas/ | Sí | No |
| Cambio de CMS o rediseño | Otro gestor, otra plantilla u otro menú | Depende | Solo si también cambia el dominio |
Si vas a cambiar de dominio, de CMS y de diseño, Google propone hacerlo por etapas: primero el traslado al dominio nuevo y después el cambio de diseño. Y si cambias de CMS o rediseñas sin tocar las URL, no necesitas redirecciones, pero cambia lo que encuentra su robot (el HTML, los enlaces internos, las canónicas, el robots.txt o el sitemap), así que merece las mismas pruebas.
Impacto en el posicionamiento
Google indexa y muestra URL concretas, no webs enteras, y el traslado se hace URL a URL: su robot tiene que visitar al menos una vez todas las direcciones antiguas y nuevas para completarlo. Lo que conserva el terreno ganado son las redirecciones permanentes: según Google, una 301 no hace perder PageRank, y mantenerlas el tiempo suficiente le permite trasladar a las URL nuevas las señales de las antiguas, incluidos los enlaces que reciben de otras webs.
El riesgo aparece cuando la web nueva rompe esa continuidad: páginas que posicionaban y desaparecen, URL sin redirección o contenidos rehechos a la vez que cambian las direcciones. La ayuda de la herramienta Cambio de dirección lo advierte: «si aprovechas un traslado para rediseñar el contenido de un sitio web y cambiar su estructura de URLs, puede que notes un descenso en el tráfico, puesto que Google tiene que volver a identificar y evaluar cada página».
Riesgos de una mala migración SEO
Si la migración se planifica mal, Google puede dejar de mostrar páginas que hoy traen visitas y tardar en colocar las nuevas. Y con esas visitas se van los contactos y las ventas que llegan desde los buscadores.
No es un riesgo teórico. La propia guía de traslados de Google dedica un apartado a los errores más habituales al migrar con cambios de URL y avisa de que pueden impedir que la web nueva se indexe por completo: bloqueos con noindex o robots.txt que no se retiran, redirecciones hacia URL que no existen, otros errores de rastreo, un servidor sin capacidad suficiente y sitemaps sin actualizar.
Google no da una cifra de cuánto tráfico se pierde: avisa de que la visibilidad puede fluctuar durante el traslado y de que el posicionamiento puede tardar un tiempo en estabilizarse.
Checklist de migración SEO paso a paso
Esta checklist de migración web SEO sigue el orden de la guía de Google para trasladar un sitio, con algunas comprobaciones prácticas añadidas. No todos sus pasos valen para todas las migraciones: un cambio de alojamiento no necesita mapa de redirecciones y un paso a HTTPS no usa la herramienta Cambio de dirección.
Antes de la migración
Todo esto se prepara y se prueba sin tocar la web publicada:
- Decide qué cambia, en qué orden y cuándo. Elige una fecha de poco tráfico: si tu negocio tiene temporadas o días flojos, Google recomienda aprovecharlos, porque los fallos afectan a menos personas y el servidor tiene más margen para el rastreo.
- Guarda una foto de partida. Haz una auditoría SEO de la web actual y exporta el informe «Rendimiento» de Search Console por página y por búsqueda (clics, impresiones y posición media) y, de Google Analytics 4, las sesiones y los eventos clave por página de destino. Guarda también con un rastreador el título, la meta descripción, el H1 y la canónica de cada URL para compararlos después.
- Haz el inventario de URL. Google propone empezar por las más importantes y buscarlas en tus sitemaps, en la analítica o los registros del servidor, en el informe «Enlaces» de Search Console y en el propio CMS. Incluye las imágenes, los vídeos, los PDF y los archivos JavaScript y CSS: también tienen URL y también se trasladan.
- Decide el destino de cada contenido: mantenerlo, fusionarlo con otra página o retirarlo. Una auditoría de contenidos te ayuda a decidirlo. Lo que retires debe devolver un código 404 o 410, no una página vacía.
- Prepara el mapa de redirecciones (lo ves en detalle en el apartado siguiente).
- Trabaja en un entorno de pruebas cerrado, protegido con contraseña o con acceso limitado por IP. Si usas noindex, apunta en qué plantillas está para quitarlo el día del cambio. El robots.txt no sirve para esto: Google advierte de que no impide que una página aparezca en sus resultados.
- Prueba la web nueva antes de publicarla. Rastréala con un programa como Screaming Frog y comprueba que cada URL responde con un código 200, que su canónica apunta a su propia URL nueva, que el hreflang (si tienes varios idiomas) usa las URL nuevas, que los enlaces son enlaces HTML con atributo href (los que Google puede seguir) y que se conservan los datos estructurados.
- Prepara Search Console. Verifica la propiedad antigua y la nueva con todas sus variantes (con y sin www, http y https) y asegúrate de que el método de verificación sigue en la web nueva. Si has comprado el dominio, revisa que no arrastre acciones manuales ni retiradas de URL, y si tenías un archivo de desautorización de enlaces, súbelo también en la propiedad nueva.
- Prepara el servidor y el DNS. Tras un traslado con cambios de URL, Google rastrea la web nueva más de lo habitual y el servidor tiene que aguantarlo. Si cambias de alojamiento, baja el tiempo de vida (TTL) de los registros DNS a unas horas al menos una semana antes y comprueba que el cortafuegos o la protección contra ataques de denegación de servicio del nuevo proveedor no bloquean al robot de Google.
Cómo preparar el mapa de redirecciones
El mapa de redirecciones es la lista que empareja cada URL antigua con su destino en la web nueva. Si solo cambias de dominio y mantienes las rutas, Google explica que puede bastar una redirección de servidor con comodín; en los traslados más complejos hay que hacer la lista de URL antiguas y asignar a cada una su destino, con reglas por patrones cuando se pueda y empezando por las que tienen más tráfico y más enlaces. Por ejemplo:
| URL antigua | URL nueva | Respuesta | Motivo |
|---|---|---|---|
| /empresa/quienes-somos.php | /sobre-nosotros/ | 301 | La misma página, con otra ruta |
| /blog/?p=123 | /blog/guia-de-tallas/ | 301 | Cambio de formato de URL |
| /zapatilla-azul/ y /zapatilla-azul-2/ | /zapatillas/azul/ | 301 | Dos páginas fusionadas en una |
| /docs/catalogo-2025.pdf | /descargas/catalogo.pdf | 301 | Los archivos también se trasladan |
| /oferta-verano-2024/ | Ninguna | 404 o 410 | Contenido retirado sin sustituto |
Al rellenarlo, sigue dos reglas:
- Cada URL, a su equivalente más parecido. Si varias páginas se han unido en una, pueden redirigir todas a ella. Lo que Google desaconseja es mandar muchas URL a un destino sin relación, como la página de inicio: confunde a los usuarios y puede tratarlo como un error soft 404.
- Directas al destino final. Escribe la dirección definitiva completa, con HTTPS y con o sin www, y evita las cadenas del tipo A → B → C: el robot de Google sigue hasta 10 saltos, pero cada salto ralentiza la carga y no todos los navegadores admiten cadenas largas.
Durante la migración
El día del cambio, sigue estos pasos en este orden:
- Quita los bloqueos del entorno de pruebas: la contraseña, las etiquetas noindex y las reglas del robots.txt que impedían rastrear la web nueva. Es el primer error de la lista de problemas habituales de Google.
- Activa las redirecciones permanentes del servidor según el mapa, o cambia los registros DNS si solo cambias de alojamiento. En webs pequeñas y medianas, Google recomienda trasladar todas las URL de una vez; en las grandes, puede hacerse por secciones para detectar antes los problemas.
- Actualiza los enlaces internos del menú, el pie, las migas de pan y el contenido para que apunten directamente a las URL nuevas, y revisa que las canónicas y el hreflang ya las usan.
- Prueba las redirecciones. Rastrea la lista de URL antiguas con una herramienta o un script y comprueba que cada una responde con un 301 hacia el destino previsto y que ese destino responde con un 200. Para comprobar una URL concreta, tienes la herramienta de inspección de URLs de Search Console.
- Envía el sitemap nuevo en Search Console. Google sugiere enviar también el de las URL antiguas para seguir el traslado: sus páginas indexadas irán bajando mientras suben las del nuevo, y las advertencias de redirección que muestre son normales.
- Si cambias de dominio o de subdominio, usa la herramienta Cambio de dirección en la propiedad antigua, con todas sus variantes verificadas. No hace falta para pasar a HTTPS, para cambiar entre www y sin www ni para mover rutas dentro del mismo dominio.
Después de la migración
Las primeras semanas son las de más riesgo: revisa estos puntos a diario durante el primer mes y, después, cada semana.
- Vigila Search Console y la analítica. Los informes «Indexación de páginas», «Sitemaps» y «Rendimiento» te dicen si Google encuentra, indexa y muestra las URL nuevas; el informe en tiempo real de Google Analytics 4 y los registros del servidor, si las visitas y el robot de Google llegan adonde deben.
- Corrige deprisa los errores. Toda URL antigua que devuelva un 404 y tuviera tráfico o enlaces necesita su redirección, y las cadenas o los bucles de redirecciones, un destino directo.
- Actualiza los enlaces que dependen de ti. Pide a las webs que más visitas te envían que cambien sus enlaces, y actualiza tus perfiles en redes sociales, tu Perfil de Empresa de Google, Merchant Center si vendes online y las páginas de destino de tus campañas.
- Mantén las redirecciones como mínimo un año, que es el periodo que Google da para trasladar todas las señales a las URL nuevas, incluidos los enlaces de otras webs; pensando en los usuarios, aconseja conservarlas indefinidamente. Sigue pagando también el dominio antiguo al menos un año, para que nadie lo compre y lo use con malas intenciones.
- No des de baja el alojamiento antiguo antes de tiempo. En un cambio de servidor, Google aconseja apagarlo cuando sus registros muestren que ya no recibe tráfico, tampoco del robot de Google.
¿Qué redirecciones usar en una migración web?
Las permanentes del lado del servidor, con el código 301 o el 308. Son las que Google interpreta con más fiabilidad y las que toma como señal de que debe mostrar la URL nueva en sus resultados. Así trata los demás tipos, según su guía de redirecciones:
- 302 y 307, temporales. Google sigue la redirección, pero no la toma como señal de que el destino deba ser la página canónica, así que puede seguir mostrando la URL antigua. Sirven para cambios provisionales, no para una migración.
- Meta refresh. Si es instantánea, Google la interpreta como permanente, y es una alternativa cuando el servidor no permite redirecciones; si tiene retraso, cuenta como temporal.
- Redirección con JavaScript. Solo como último recurso: si falla el renderizado de la página, Google puede no detectarla.
Qué revisar en Search Console después de migrar
Google describe Search Console como tu aliado durante un traslado y aconseja revisar por separado los datos de la propiedad antigua y los de la nueva. Empieza por el informe «Indexación de páginas»; estos son los estados que conviene vigilar y lo que suelen indicar tras migrar:
| Estado | Qué suele indicar tras migrar | Qué hacer |
|---|---|---|
| Página con redirección | Lo esperado en las URL antiguas: redirigen y por eso no se indexan | Nada, si el destino es el correcto |
| No se ha encontrado (404) | Una URL antigua sin redirección, o una redirección hacia una URL que no existe | Redirigirla a su equivalente si tenía tráfico o enlaces |
| Soft 404 | Una página que parece vacía o de error, o muchas URL redirigidas a un destino sin relación | Redirigir al equivalente o devolver un 404 o 410 real |
| Error de redirección | Una cadena demasiado larga, un bucle o una URL vacía en la cadena | Redirigir directamente al destino final |
| La URL se ha marcado como «noindex» / El archivo robots.txt ha bloqueado la URL | Bloqueos del entorno de pruebas que siguen activos | Quitarlos de la web publicada |
| Duplicada: Google ha elegido una versión canónica diferente a la del usuario | Google ha preferido otra versión, por ejemplo una URL antigua que sigue accesible sin redirección | Redirigir la versión que sobra y usar la nueva en canónicas, enlaces y sitemap |
Completa la revisión con «Sitemaps», para ver cuántas URL nuevas se indexan; «Rendimiento», para comprobar que los clics y las impresiones de cada página antigua pasan a su URL nueva; y «Estadísticas de rastreo», en los ajustes de la propiedad, para ver qué respuestas recibe el robot de Google (Google indica que en webs de menos de mil páginas no hace falta). El informe «Enlaces» te dice qué páginas reciben más enlaces de otras webs: sus redirecciones son las primeras que debes comprobar. Tienes más detalle de cada informe en la guía de Google Search Console de este blog.
¿Cuánto tarda Google en asimilar una migración?
Según Google, en un sitio pequeño o mediano suelen hacer falta varias semanas para que la mayoría de las páginas pasen a las URL nuevas, y en los grandes, más; mientras tanto, es normal que la visibilidad fluctúe. La velocidad depende sobre todo del número de URL y de la rapidez del servidor, y enviar un sitemap acelera el descubrimiento.
Tras un cambio de dominio o de URL, Google rastrea la web nueva más de lo habitual; tras un cambio de alojamiento, en cambio, es normal que el rastreo baje justo después del lanzamiento y vaya subiendo en los días siguientes. Google también puede seguir mostrando de vez en cuando alguna URL antigua como nombre alternativo, algo que desaparece con el tiempo. Y si usas la herramienta Cambio de dirección, Google da prioridad al sitio nuevo durante 180 días.
¿La caída es por la migración o por una actualización de Google?
Para saberlo, cruza fechas y páginas. Google publica sus actualizaciones de posicionamiento más relevantes, con la fecha de inicio y la duración, en el panel de estado de la Búsqueda de Google (Search Status Dashboard): si la caída empezó con una de ellas, puede que la migración no sea la causa, o no la única. Si fue una actualización principal, la guía de Google sobre estas actualizaciones aconseja esperar al menos una semana desde que termine y comparar esa semana con otra anterior a su inicio. Mira también en «Rendimiento» cada URL antigua frente a la nueva y, si migraste por partes, las secciones que cambiaron frente a las que no. Si solo caen las páginas migradas y hay errores de rastreo o de redirección, lo más probable es que el problema esté en la migración.
¿Cómo afecta una migración a AI Overviews, el Modo IA y ChatGPT?
Igual que al resto de la Búsqueda, porque Google construye esas respuestas con páginas de su índice. Una página solo puede servir de fuente en AI Overviews (las vistas creadas con IA) o en el Modo IA si está indexada y puede mostrarse en Google con un fragmento, así que las URL nuevas no aparecerán ahí hasta que Google las indexe. Según su documentación sobre las funciones de IA, no hace falta ninguna optimización especial, pero sí conviene añadir tres comprobaciones:
- Que la propiedad nueva siga incluida en la IA generativa. Desde el 31 de agosto de 2026, todas las webs tienen en los ajustes de Search Console un control de la IA generativa de la Búsqueda, y Google exige estar incluido para aparecer en esas funciones. «Incluir» es la opción predeterminada, pero compruébalo en la propiedad del dominio nuevo. Ese mismo día, Google extendió a todas las webs el informe de rendimiento de IA generativa, que aparece cuando hay impresiones suficientes: en su pestaña «Páginas» verás si las impresiones en AI Overviews y el Modo IA pasan de las URL antiguas a las nuevas.
- Que el robots.txt y el cortafuegos no bloqueen a los rastreadores de los buscadores con IA. OpenAI explica que las webs que bloquean a OAI-SearchBot no se muestran en las respuestas de búsqueda de ChatGPT (como mucho, pueden salir como enlaces de navegación), y Perplexity recomienda permitir a PerplexityBot en el robots.txt y avisa de que, con un cortafuegos de aplicaciones web, puede que haya que autorizarlo expresamente. Un proveedor o una CDN nuevos pueden traer reglas contra bots distintas de las que tenías.
- Que los datos estructurados pasen a la web nueva. Google no pide marcado especial para sus funciones de IA, pero usa los datos estructurados para los resultados enriquecidos y recomienda que coincidan con el texto visible.
Para ir más allá de la migración, tienes una guía sobre SEO para AI Overviews y AI Mode.
Errores comunes en una migración web
Estos son los errores que más conviene evitar:
- Dejar puestos los bloqueos del entorno de pruebas, como un noindex en la plantilla o un «Disallow: /» en el robots.txt, que pueden impedir que Google indexe la web nueva.
- Redirigir todo a la página de inicio, algo que Google puede tratar como soft 404.
- Usar redirecciones temporales (302) en lugar de permanentes (301), con lo que Google puede seguir mostrando las URL antiguas.
- Olvidar las URL que no son páginas: imágenes, PDF, vídeos y archivos de estilo o JavaScript.
- Dejar enlaces internos, canónicas o hreflang con las URL antiguas: cada enlace obliga a pasar por una redirección y cada canónica antigua pide a Google que muestre una URL que ya redirige.
- Cambiarlo todo a la vez: dominio, CMS, diseño y estructura en el mismo lanzamiento multiplican los puntos de fallo y hacen casi imposible saber qué causó una caída.
- Quedarse corto de servidor justo cuando Google rastrea más de lo habitual.
- Retirar las redirecciones o dejar caducar el dominio antiguo antes de un año.
- No medir: sin foto de partida ni seguimiento, los errores se descubren cuando el tráfico ya ha caído.
Conclusión: el SEO entra en el proyecto el primer día
Una migración web no tiene por qué costar posicionamiento si se trata como un proyecto SEO y no como un trámite técnico del día del lanzamiento. Inventario de URL, una 301 de cada una a su equivalente, pruebas en un entorno cerrado, un cambio cada vez y Search Console vigilado durante las primeras semanas: con eso le pones fácil a Google trasladar a la web nueva lo que había ganado la antigua.
Si el proyecto lo lleva una agencia de desarrollo web, incluye en el encargo el inventario de URL, el mapa de redirecciones y las pruebas en el entorno cerrado, y deja claro quién revisará Search Console después del lanzamiento. Son tareas de SEO, pero se deciden mientras se construye la web, no cuando ya está publicada.