Hay un dato que cambia la conversación sobre migraciones y que no aparece en casi ninguna guía en español. SALT.agency analizó 1.052 migraciones de dominio y publicó los resultados en junio de 2026: solo el 22,8 % había recuperado su tráfico orgánico a los 90 días. La mediana de recuperación fue de 304 días. Y el 13,9 % no había vuelto a la línea base tres años después.
Léelo otra vez, porque contradice lo que te van a contar en la reunión de lanzamiento. La recuperación tarda meses, hay un porcentaje de proyectos que no vuelven nunca, y la diferencia entre acabar en el 22,8 % o en el 13,9 % se decide antes de tocar el DNS.
Esta guía es el proceso entero: qué inventariar, cómo construir el mapa de redirecciones, qué probar en staging, el orden exacto del día del lanzamiento, qué mirar las primeras 72 horas y qué mirar durante los tres meses siguientes. Con las fuentes oficiales donde las hay y avisando de lo que es criterio propio.
Si estás valorando una migración y quieres que alguien la revise antes, esto es exactamente lo que cubre una auditoría SEO técnica. Pero el proceso está aquí completo para que puedas ejecutarlo tú.
1. Qué cuenta como migración (y cuánto riesgo tiene cada tipo)
“Migración” se usa para cosas muy distintas y el riesgo no es el mismo en todas. La pregunta que ordena todo: ¿cambian las URLs?
| Tipo de cambio | ¿Cambian las URLs? | Riesgo | Por qué |
|---|---|---|---|
| Cambio de dominio | Sí, todas | Muy alto | Se pierde el histórico de la propiedad y hay que retransmitir todas las señales |
| Replatforming de CMS | Casi siempre | Alto | Cambia la estructura de URL, las plantillas y el renderizado a la vez |
| Rediseño con cambio de plantillas | A veces | Medio-alto | Aunque las URLs se mantengan, cambian enlazado interno, contenido y rendimiento |
| Cambio de estructura de URL | Sí | Alto | Es una migración aunque el dominio y el diseño no se toquen |
| Consolidación de dominios | Sí | Muy alto | Varias entidades pasando a una, con duplicidades y canibalización |
| HTTP a HTTPS | Sí, técnicamente | Bajo | Google lo detecta solo y no requiere cambio de dirección |
| Cambio de hosting sin cambio de URL | No | Bajo | El riesgo es de rendimiento y de errores 5xx, no de indexación |
| Internacionalización con hreflang | Sí | Muy alto | Se suman los errores de hreflang a los de la migración |
Los dos casos que más se subestiman son el rediseño sin cambio de URL y el cambio de hosting. En el rediseño la gente asume que si las URLs no cambian no hay riesgo, y luego resulta que el menú nuevo enlaza a la mitad de categorías que el viejo y el enlazado interno se desploma. Lo tienes desarrollado en rediseñar una web es peligroso para el SEO y en menús en JavaScript que Google no ve.
En el cambio de hosting el riesgo es que el servidor nuevo responda peor. Google lo dice sin rodeos en su guía de presupuesto de rastreo: si los tiempos de respuesta se mantienen o mejoran, el límite de rastreo sube, y si el sitio se ralentiza o devuelve 5xx, baja.
2. Cuánto se tarda de verdad en recuperar
Aquí es donde casi todas las guías te mienten, normalmente sin querer. Repiten “seis a ocho semanas” o “el 80-90 % del tráfico en dos o tres meses” sin ninguna fuente detrás.
Los números del estudio de SALT sobre 1.052 migraciones de dominio, con la recuperación definida como el mes en que el tráfico orgánico del dominio nuevo iguala o supera la media móvil de seis meses previa a la migración:
| Ventana | Migraciones que recuperan |
|---|---|
| 0 a 30 días | 5 % |
| 31 a 90 días | 18 % |
| 91 a 180 días | 13 % |
| 181 a 365 días | 24 % |
| 1 a 2 años | 24 % |
| Más de 2 años | 16 % |
| No recupera en 3 años | 13,9 % |
Mediana: 304 días. Media: 489 días, distorsionada por los casos largos.
Dos avisos antes de que uses esto en una presentación. El primero es que la muestra es de migraciones de dominio, el escenario más agresivo. Un replatforming que conserva el dominio y la estructura de URL se comporta bastante mejor. El segundo es que ahí dentro hay migraciones bien y mal ejecutadas mezcladas, así que el dato no dice “hagas lo que hagas tardarás 10 meses”: dice que la distribución real es mucho más larga de lo que se vende.
Google, por su parte, no da plazos concretos. Su documentación de mudanzas de sitio dice que en sitios de tamaño medio pueden pasar varias semanas o más hasta que empiece a mostrar las URLs nuevas, y que los sitios grandes tardan más.
Lo que hago yo con esto en un proyecto: fijar la expectativa en seis meses hasta la estabilización, con revisiones a 72 horas, 30 días y 90 días. Si recupera antes, perfecto. Si se prometen ocho semanas, a la novena empiezan las reuniones incómodas y las decisiones precipitadas, que es cuando de verdad se pierde el tráfico.
3. Fase 0: decidir si la migración merece la pena
Antes del inventario hay una fase que casi ninguna guía incluye, porque asume que la decisión ya está tomada.
El caso más didáctico es el de WooCommerce. En 2023 se movieron de woocommerce.com a woo.com como parte de un cambio de marca. En abril de 2024 anunciaron la vuelta al dominio original y lo explicaron con claridad: el cambio dificultó que los usuarios los encontraran en Google, y el problema empeoró tras el core update de marzo de 2024. Reunieron a un grupo de consultores SEO y la conclusión fue revertir.
Lo que hay que sacar de ahí no es “no cambies de dominio”. Es que una marca con la autoridad de WooCommerce, con recursos y con equipo técnico, perdió lo bastante como para dar marcha atrás un año después. Si tu caso se parece, la pregunta correcta no es “¿cómo migramos sin perder tráfico?” sino “¿qué ganamos que compense una mediana de 10 meses de recuperación?”.
Preguntas que conviene responder por escrito antes de aprobar el proyecto:
- ¿Qué problema de negocio resuelve la migración que no se pueda resolver sin cambiar URLs?
- ¿Cuánto vale el tráfico orgánico actual en euros al mes, y cuánto costaría perder el 30 % durante seis meses?
- ¿Hay alternativa parcial? Rediseñar sin tocar URLs, o cambiar de CMS conservando la estructura, reduce muchísimo el riesgo.
- Si hay cambio de marca, ¿el nombre nuevo tiene búsquedas de marca o partimos de cero?
Cuando la respuesta es “migramos igual” (que suele serlo, porque la decisión viene de arriba), al menos ya tienes documentado el riesgo y la expectativa temporal.
4. Fase 1: inventario y línea base
El error de esta fase es hacer un crawl con Screaming Frog y darlo por hecho. Un crawl solo encuentra lo que está enlazado. Todo lo que no lo esté (y hay más de lo que crees) se queda fuera del mapa y se convierte en un 404 el día del lanzamiento.
Las seis fuentes que hay que cruzar
| Fuente | Qué aporta que las demás no |
|---|---|
| Crawl completo (Screaming Frog o similar) | La arquitectura real y los códigos de estado actuales |
| Search Console, exportación de 16 meses | URLs con impresiones y clics, incluidas las que el crawl no alcanza |
| GA4 o tu analítica | Páginas con conversiones, que no siempre son las de más tráfico |
| Logs del servidor | URLs que Googlebot y los bots de IA piden de verdad, incluidas las heredadas |
| Backlinks (Ahrefs, Semrush, Search Console) | URLs con enlaces externos, que son las que más duele perder |
| Sitemaps y volcado del CMS | Páginas huérfanas y contenido no enlazado |
Los logs son la fuente que más se salta la gente y la que más rescata. Ahí aparecen rutas antiguas que siguen recibiendo peticiones desde marcadores, PDFs, campañas viejas y enlaces que nadie recuerda. Si no tienes claro cómo sacarlas, está el proceso entero con comandos en análisis de logs: qué hace Googlebot de verdad en tu servidor.
Un extracto rápido de URLs únicas que ha pedido Googlebot en 90 días:
zcat access.log*.gz | grep -i "googlebot" | awk '{print $7}' | sort -u > urls-legacy.txt
wc -l urls-legacy.txt
Compara esa cifra con la de tu crawl. La diferencia es lo que te habrías dejado fuera.
No olvides tampoco lo que no es HTML: PDFs, imágenes con enlaces entrantes, feeds RSS, robots.txt, favicon, ficheros de verificación y cualquier endpoint que consuma una integración externa.
La línea base que vas a necesitar dentro de tres meses
Esto es lo que más se agradece después y lo que menos se hace. Antes de tocar nada, congela y guarda fuera del sitio:
- Clics, impresiones, CTR y posición media por URL de los últimos 16 meses de Search Console
- Sesiones y conversiones orgánicas por página de los últimos 12 meses
- Ranking de tus 200 a 500 palabras clave prioritarias, con fecha
- Número de URLs indexadas, por sección
- Core Web Vitals por plantilla, de datos de campo y de laboratorio
- El crawl completo en formato exportable
Sin esa foto no puedes demostrar si la migración fue bien o mal, y acabarás discutiendo de memoria. Si necesitas ordenar qué medir, tienes el marco en KPIs SEO: qué medir.
Clasificar cada URL
Con el inventario cerrado, cada URL recibe una etiqueta. Sin excepciones y sin “ya lo vemos”:
| Etiqueta | Qué significa | Cuándo se usa |
|---|---|---|
| Keep | Se mantiene igual | La URL no cambia |
| Update | Misma URL, contenido o metadatos revisados | Aprovechas la migración para mejorarla |
| Merge | Se fusiona con otra | Dos páginas que compiten por lo mismo |
| Redirect | URL nueva, redirección 1:1 | El caso mayoritario |
| Remove | Se retira | Contenido obsoleto sin tráfico ni enlaces |
Las de tipo Merge son la parte más rentable y la que casi nadie trabaja. Una migración es el mejor momento para consolidar contenido que se canibaliza, porque ya vas a tocar todas las URLs igualmente. El criterio para decidir está en consolidar o diferenciar páginas que compiten.
Las de tipo Remove también dan miedo y no deberían. Migrar 40.000 URLs de las que 25.000 no reciben una visita desde hace dos años es migrar un problema. El criterio de poda está en cómo mejorar tu SEO eliminando contenido.
Sobre qué código devolver en las eliminadas: da bastante igual. John Mueller lo zanjó en 2024 diciendo que la diferencia de procesamiento entre 404 y 410 es tan mínima que no se le ocurre un caso en que prefiera uno sobre otro por motivos de SEO. Si tu sistema te deja devolver 410, hazlo y ya está. No merece una reunión.
5. Fase 2: el mapa de redirecciones
El mapa es la migración. Todo lo demás es apoyo.
Reglas que no se negocian
Una a una. Cada URL antigua va a su equivalente más cercana. Si no hay equivalente exacto, a la categoría padre. A la home solo cuando de verdad no hay nada mejor, y sabiendo que Google lo tratará como un soft 404 y no transferirá señales.
Un solo salto. La cadena A→B→C funciona para el usuario y desperdicia rastreo. En una migración se generan solas: la regla antigua sigue viva y la nueva se encadena encima. Hay que aplanarlas antes de lanzar, no después.
301, no 302. Aunque en términos de PageRank dé lo mismo (ahora vamos a eso), la 301 es la que comunica canonicalización permanente.
Sin parámetros perdidos. Comprueba que la redirección conserva los parámetros de campaña. Si tu regla los descarta, pierdes la atribución de todo lo que llegue desde newsletters y anuncios antiguos.
Cómo se configuran en cada servidor (Apache, Nginx, Vercel, WordPress) y los errores clásicos los tienes desarrollados en la guía de redirecciones 301, así que aquí no lo repito.
El mito del PageRank que se pierde en la redirección
Circula la idea de que cada 301 se come un porcentaje de autoridad. Ya no es así, y no es de 2026: Gary Illyes lo dijo en julio de 2016, con una frase de cuatro palabras que dio la vuelta al sector: “30x redirects don’t lose PageRank anymore”. Google lo ha repetido desde entonces para 301, 302, 307 y 308.
Ojo con la lectura que se hace de eso, porque los briefs de mercado suelen convertirlo en “las redirecciones no tienen riesgo”. No es lo mismo. Que no se pierda PageRank en el salto no significa que la página nueva vaya a posicionar igual, porque el ranking depende también de la relevancia del contenido de destino. Una redirección hacia una página que no responde a lo mismo que la original transfiere autoridad hacia un sitio donde no sirve de nada. El mapeo perezoso hace más daño que cualquier cadena de redirecciones.
Validar el mapa antes de que exista el sitio nuevo
Con la lista de URLs antiguas y la de destinos, comprueba en la hoja de cálculo:
- Ninguna URL de origen aparece dos veces
- Ninguna URL de destino es a su vez origen de otra regla (eso es una cadena)
- Ningún destino devuelve 404 en el entorno nuevo
- Ningún destino tiene un
canonicalapuntando a otra parte - El porcentaje de redirecciones a la home está por debajo del 5 %
- Las 100 URLs con más tráfico y las 100 con más backlinks tienen destino revisado a mano, una a una
Ese último punto es el que más veces salva un proyecto. El resto se puede automatizar; esas 200, no.
6. Fase 3: staging
Bloquear bien el entorno
La única forma segura de que no se indexe es autenticación HTTP básica, usuario y contraseña a nivel de servidor. Un noindex se puede quedar puesto el día del lanzamiento, y un Disallow en robots.txt no impide que una URL se indexe si alguien la enlaza.
Y avisa a quien haga el crawl de que necesitará las credenciales, porque Screaming Frog y compañía las admiten sin problema.
Rastrear staging y comparar contra producción
El proceso: rastreas el sitio antiguo, rastreas staging con las credenciales, y comparas. Lo que buscas son diferencias que nadie ha decidido conscientemente.
| Qué comparar | Señal de alarma |
|---|---|
| Número de URLs indexables | Una caída grande sin justificación en el mapa |
| Títulos y meta descripciones | Plantillas que se han quedado con el valor por defecto del CMS |
| H1 | Páginas sin H1 o con el logo como H1 |
| Canonicals | Cualquiera que apunte al dominio de staging |
| Meta robots | Cualquier noindex no previsto (repaso aquí) |
| Enlaces internos por página | Menos enlaces salientes que en el sitio antiguo: el menú nuevo enlaza menos |
| Profundidad de clic | Páginas que pasan de 2 a 5 saltos desde la home |
| Datos estructurados | @id y URLs que siguen apuntando al dominio antiguo o al de staging |
| hreflang | Referencias cruzadas incompletas o al dominio viejo |
| Tamaño del HTML | Plantillas que se han inflado con el framework nuevo |
El de los canonicals apuntando a staging es el error más repetido de la historia de las migraciones. Compruébalo dos veces.
Probar con varios user-agents
Esto sí es imprescindible y no depende de ninguna metodología con nombre propio: rastrea staging simulando Googlebot Smartphone, Googlebot Desktop, GPTBot y Bingbot y compara el HTML que recibe cada uno con lo que ve un navegador.
Lo que buscas es paridad. Si tu sitio nuevo monta el contenido con JavaScript en cliente, Googlebot acabará renderizándolo, pero GPTBot y compañía no ejecutan JavaScript, así que se llevan una página vacía. Migrar a un framework moderno sin renderizado en servidor es una de las formas más eficaces de desaparecer de las respuestas de IA sin perder (todavía) posiciones en Google. El detalle está en por qué ChatGPT no ve tu web en React.
Comprueba también que el sitio nuevo no bloquea a esos bots por robots.txt ni por reglas del CDN, que es algo que se configura “por seguridad” en staging y se queda puesto.
Probar las redirecciones en staging
Se puede, y hay que hacerlo. Carga las reglas en el entorno de pruebas y lanza la lista completa de URLs antiguas contra él en modo lista. Lo que tiene que salir: 301 en un solo salto y destino con código 200. Cualquier otra cosa se corrige ahora, que sale gratis.
7. Fase 4: el día del lanzamiento
El orden importa. Esta es la secuencia que uso, con el reparto de quién hace qué.
48 horas antes
- Bajar el TTL de los registros DNS a 300 segundos o menos. Esto acelera la propagación entre operadores y te permite revertir rápido si algo sale mal. No acelera el rastreo de Google, que es una confusión habitual.
- Congelar cambios de contenido en el sitio antiguo.
- Última exportación de Search Console y analítica.
- Verificar en Search Console la propiedad del dominio nuevo, con todas sus variantes.
- Preparar el
robots.txtdefinitivo y el sitemap nuevo en un fichero aparte, listos para subir.
Ventana de lanzamiento
Elige tráfico bajo, pero con gente disponible. La combinación que funciona es martes o miércoles por la mañana temprano, no viernes por la noche. Un fin de semana tiene menos tráfico y también menos desarrolladores despiertos, y el coste de tardar 12 horas en detectar un noindex global es mucho mayor que el de perder unas cuantas visitas.
Secuencia del despliegue
- Publicar el sitio nuevo.
- Quitar la autenticación básica y cualquier
noindexde staging. Comprobado a mano, en varias plantillas. - Activar las reglas de redirección.
- Sustituir el
robots.txtpor el definitivo y verificar que no queda ningúnDisallow: /. - Subir el sitemap nuevo y comprobar que responde 200 y que las URLs de dentro también.
- Verificar el certificado SSL en el dominio nuevo y en todas sus variantes.
- Comprobar que la analítica y los píxeles disparan en el dominio nuevo.
- Comprobar los formularios de verdad: enviar uno y ver si llega al CRM.
- Enviar el sitemap nuevo en Search Console y en Bing Webmaster Tools.
- Lanzar la herramienta de cambio de dirección en Search Console, si hay cambio de dominio (siguiente bloque, tiene truco).
- Ping a IndexNow con las URLs nuevas prioritarias, que en Bing acelera bastante (cómo funciona).
- Anotar la fecha y la hora en GA4 y en Looker, para que dentro de tres meses nadie tenga que preguntar cuándo fue.
Comprobación inmediata, en la primera hora
Rastrea el sitio en vivo entero, no una muestra. Y lanza la lista completa de URLs antiguas en modo lista contra producción. Lo que no puede aparecer: 404, cadenas, 302 donde debía haber 301, ni una sola URL redirigiendo al dominio de staging.
8. La herramienta de cambio de dirección, a fondo
Aquí está la novedad real de 2026 y el motivo por el que muchas migraciones bien hechas se quedan a medias.
Google actualizó su documentación en junio de 2026 para dejar claro algo que antes se interpretaba mal: en una migración de dominio hay que enviar solicitudes de cambio de dirección para todos los subdominios y para las variantes con y sin www del dominio antiguo. No una por el dominio principal y listo. Una por cada variante verificada, incluso por las que no estés usando activamente.
O sea, si migras example.com a new-example.net y tienes www.example.com, blog.example.com y en.example.com, son cuatro solicitudes independientes.
El resto de condiciones que conviene tener claras antes:
| Requisito | Detalle |
|---|---|
| Propiedad | Tienes que ser propietario verificado del sitio antiguo y del nuevo, con la misma cuenta de Google |
| Nivel | Funciona a nivel de dominio o subdominio, nunca de carpeta (example.com/tienda/ no vale) |
| Protocolo | Al enviar http:// se transfiere también https:// |
| Duración | Google aplica el efecto durante 180 días, y pasado ese plazo trata los sitios como no relacionados |
| Comprobación previa | Google valida la propiedad y prueba redirecciones de muestra antes de aceptar la solicitud |
Cuándo no usarla: al pasar de HTTP a HTTPS, al cambiar de www a no-www dentro del mismo dominio, al mover páginas sueltas y al cambiar de proveedor de hosting sin cambiar URLs.
Ese plazo de 180 días es el que da sentido al resto del calendario. Tienes seis meses de tratamiento preferente y una mediana de recuperación de diez. Por eso las redirecciones tienen que sobrevivir mucho más que la herramienta: la recomendación de Google es mantenerlas al menos un año, y de cara al usuario, indefinidamente. El almacenamiento de un fichero de reglas no cuesta nada.
Bing también tiene la suya, y casi nadie la usa
Bing Webmaster Tools tiene su propia herramienta de mudanza de sitio, y admite migraciones completas y parciales, incluidos movimientos entre subdominios y directorios. Como Bing alimenta a Copilot y a parte de las respuestas de IA, dejarlo fuera de la migración tiene un coste que hace tres años no tenía.
Un detalle de la documentación de Bing que merece la pena: recomiendan revisar los logs del servidor a diario durante al menos tres meses después de iniciar la migración. Es la recomendación oficial más agresiva que existe sobre monitorización post-migración y viene de donde menos gente mira.
9. Fase 5: las primeras 72 horas
Aquí no se optimiza nada. Se detectan catástrofes.
Cada pocas horas el primer día
- Códigos 5xx en los logs, agrupados por hora. Un servidor que se cae bajo el pico de rastreo posterior a una migración es un clásico.
- Volumen de rastreo de Googlebot en el dominio nuevo. Debe subir.
- 404 en el dominio nuevo, ordenados por frecuencia. Cada patrón repetido es una regla de redirección que falta.
- Que la home y las 20 plantillas principales devuelvan 200 y sean indexables.
# 404 más pedidos en el sitio nuevo, para encontrar agujeros del mapa
awk '$9 == 404 {print $7}' access.log | sort | uniq -c | sort -rn | head -40
En las primeras 24 horas
- Inspección de URL en Search Console sobre la home y una página de cada plantilla.
- Comprobar que el sitemap nuevo se ha leído y con cuántas URLs.
- Verificar que la analítica registra tráfico con normalidad y que el porcentaje de conversión no se ha desplomado.
- Enviar un formulario de cada tipo y comprobar que llega.
Entre las 24 y las 72 horas
- Segundo rastreo completo del sitio en vivo, comparado con el del día del lanzamiento.
- Revisar la cobertura en Search Console: “descubierta, actualmente sin indexar” empezará a crecer y es normal al principio, pero conviene saber qué significa.
- Comprobar en los logs si Googlebot sigue pidiendo el dominio antiguo, que es exactamente lo que debe pasar durante semanas.
- Contactar con los sitios que más te enlazan para que actualicen. Google lo recomienda expresamente y priorizando por visitas recibidas. Se hace una vez y no se vuelve a hacer nunca, así que hazlo ahora.
Una cosa que hay que explicar antes de que pase, porque genera pánico: el tráfico va a caer los primeros días. Siempre. Google necesita rastrear las redirecciones para transferir señales, y ese proceso no es instantáneo. Lo que importa no es la caída del día tres, sino la pendiente de la semana cuatro.
10. Fase 6: de la semana 2 al mes 6
Qué mirar cada semana
| Métrica | Qué te dice |
|---|---|
| Peticiones de Googlebot al dominio nuevo | Si sube, va bien; si se estanca, hay un problema de descubrimiento |
| Reparto del rastreo entre dominio antiguo y nuevo | El antiguo debe ir bajando, poco a poco |
| URLs indexadas por sección | Compara contra la línea base sección a sección, no en total |
| Impresiones por sección | Se recupera antes que los clics |
| 404 nuevos | Cada uno es una regla que falta |
| Core Web Vitals de campo | Tardan 28 días en consolidarse, así que el primer dato fiable llega al mes |
El diagnóstico que de verdad hace falta
Cuando algo va mal, la pregunta es qué cayó exactamente. Este cuadro resuelve la mayoría de los casos:
| Síntoma | Causa más probable | Dónde mirar |
|---|---|---|
| Caen impresiones y clics a la vez, en todo el sitio | Bloqueo de rastreo o noindex global | robots.txt, meta robots, cabeceras HTTP |
| Cae una sección concreta | Mapeo malo o pérdida de enlazado interno en esa plantilla | Mapa de redirecciones de esa sección, enlaces internos |
| Se mantienen impresiones y caen clics | Títulos y descripciones que se han perdido o degradado | Comparativa on-page contra la línea base |
| Se mantiene el tráfico y caen las conversiones | Formularios, píxeles o pasarela rotos | Prueba manual del embudo completo |
| Cae el tráfico de marca | Problema de identidad: cambio de nombre, no de SEO | Búsquedas de marca en Search Console |
| Todo estable menos las páginas nuevas | Problema de descubrimiento | Enlazado interno y sitemaps |
La fila que más dinero mueve es la cuarta, y es la que ninguna herramienta SEO detecta. Una migración puede salir perfecta en rastreo e indexación y estar perdiendo el 100 % de los leads porque el webhook al CRM apunta al dominio antiguo. Compruébalo enviando formularios de verdad, no revisando el código.
Cuándo tocar y cuándo esperar
Las primeras cuatro semanas se corrigen errores, no se optimiza. Cambiar títulos, reescribir contenido o reorganizar la arquitectura mientras Google está reprocesando el sitio entero solo consigue que no sepas qué causó qué.
A partir del mes dos, ya con datos, es cuando merece la pena mirar qué plantillas se han quedado por debajo de la línea base y trabajarlas.
11. Migración y visibilidad en buscadores de IA
Este bloque casi nadie lo cubre y va a más. Voy a ser honesto con lo que se sabe y lo que no: no hay estudios sólidos todavía sobre cómo afecta una migración a las citas en ChatGPT, Perplexity o Gemini. Lo que sí hay son mecanismos conocidos de los que se deducen precauciones razonables.
Los índices de IA se refrescan más despacio. Los modelos citan URLs que tienen en sus índices o que recuperan en el momento. Si tu URL antigua devuelve 404 en lugar de redirigir, la cita se rompe y no hay proceso equivalente a la transferencia de señales de Google.
Esos bots gastan mucho en URLs muertas. En el estudio de Vercel y MERJ, el 34,82 % de las peticiones de ChatGPT y el 34,16 % de las de Claude terminaban en 404, frente al 8,22 % de Googlebot. Un sitio recién migrado con agujeros en el mapa les da todavía más motivos para no volver.
No ejecutan JavaScript. Ya lo he dicho arriba pero conviene repetirlo aquí: si la migración cambia el renderizado, puedes conservar el ranking en Google y desaparecer de las respuestas de IA a la vez.
Precauciones que sí se pueden tomar:
- Mantén estables las URLs de los contenidos que ya te citan. Si hay una guía que aparece en respuestas de IA, esa URL no se toca aunque el resto del sitio cambie de estructura.
- Conserva el marcado de datos estructurados, actualizando los
@idal dominio nuevo. - Mantén las redirecciones más tiempo del que dice Google, porque los índices de IA tardan más en actualizarse que el de Google.
- Toma línea base antes de migrar. Ahí es donde entra AI Performance de Bing Webmaster Tools, en versión preliminar pública desde febrero de 2026, que da citas totales, páginas citadas y consultas usadas para recuperar el contenido en Copilot y en los resúmenes de IA de Bing. Es una muestra y no cubre a ChatGPT ni a Gemini, pero es lo único gratuito que da una cifra antes y después.
Si quieres el proceso completo de medición en motores generativos, está en guía GEO: cómo auditar tu marca y en la auditoría GEO.
12. Lo que no es tráfico y también se rompe
Las guías de migración hablan de URLs y de rankings. El daño más caro suele estar en otro sitio, sobre todo en B2B y en ecommerce, donde el tráfico es solo el principio.
Checklist de lo que hay que probar a mano el día del lanzamiento, con una persona haciéndolo de verdad:
- Formularios. Enviar uno de cada tipo y comprobar que llega al buzón y al CRM. Los formularios con dominio codificado en el destino fallan en silencio.
- Webhooks e integraciones. Salesforce, HubSpot, Zapier, la pasarela de pago. Cualquier integración con la URL antigua escrita a fuego deja de funcionar sin avisar.
- Píxeles y eventos de conversión. Google Ads, Meta, LinkedIn. Si el píxel no dispara, dejas de optimizar campañas y no te enteras hasta el informe de fin de mes.
- Páginas de gracias. Suelen quedarse fuera del inventario porque no están enlazadas y son las que registran la conversión.
- Contenido descargable. PDFs, guías, catálogos. Muchos tienen enlaces externos y todos se olvidan.
- Correos automáticos. Los enlaces dentro de las plantillas de email transaccional apuntan al dominio antiguo.
- Anuncios activos. Las URLs de destino de Google Ads no se redirigen solas, y en algunas cuentas una redirección rompe la validación.
- Búsqueda interna. Que funcione y que no genere URLs indexables nuevas (por qué importa).
- Login y área de clientes. Si hay zona privada, que las sesiones sobrevivan al cambio de dominio.
En ecommerce se suma el feed de Merchant Center, que apunta a las URLs antiguas y que si no se actualiza deja de servir productos. El proceso de revisión está en cómo auditar el feed de Merchant Center.
13. Aprovechar la migración para mejorar el rendimiento
Una migración es de las pocas ocasiones en las que se puede tocar la base técnica sin pedir permiso para un proyecto aparte. Desaprovecharla es un error caro, porque el siguiente momento parecido llega en cinco años.
Lo que conviene cerrar en la migración y no después:
- Rendimiento por plantilla. Mide LCP, INP y CLS en staging por tipo de página, no en la home. La home suele ser la más cuidada y la menos representativa. Tienes el detalle de cómo mejorar el LCP.
- Huella del contenido en los estáticos. Nombres de fichero con hash del contenido, para que el renderizador de Google no trabaje con versiones cacheadas antiguas.
- Tamaño del HTML. Googlebot rastrea los primeros 2 MB de un archivo de tipo admitido y descarta el resto. Si el framework nuevo mete el estado entero de la aplicación en el HTML, comprueba el peso antes de lanzar.
- Profundidad de clic. Que ninguna página de negocio quede a más de tres saltos de la home.
- Espacio de URLs rastreables. Si arrastrabas un problema de facetas y parámetros o de paginación de categorías, este es el momento de cerrarlo. Migrar el desorden es migrarlo con intereses, que es de lo que va la deuda técnica SEO.
14. Errores que matan una migración
| Error | Consecuencia |
|---|---|
| Redirigir todo a la home | Google lo trata como soft 404 y no transfiere señales de las páginas internas |
| Cadenas de redirección | Rastreo desperdiciado, latencia y transferencia más lenta de señales |
Dejar el noindex de staging | Desindexación completa en cuestión de días |
| Canonicals apuntando a staging | Google indexa una URL que no existe o directamente no indexa nada |
Robots.txt con Disallow: / | Rastreo a cero y caída total en menos de una semana |
| Inventariar solo con un crawl | Todo lo no enlazado se convierte en 404 el día del lanzamiento |
| No actualizar los enlaces internos | Dependencia permanente de las redirecciones y rastreo más lento |
| Ignorar recursos no HTML | PDFs e imágenes con enlaces externos que se pierden |
| Cambio de dirección solo para el dominio principal | Los subdominios se quedan sin consolidar (el error nuevo de 2026) |
| Quitar las redirecciones a los tres meses | Se corta la transferencia justo cuando todavía está en curso |
| Lanzar un viernes por la tarde | Se detecta el problema el lunes, con 60 horas de daño |
| Optimizar durante las primeras semanas | Imposible saber qué causó qué |
| Prometer recuperación en ocho semanas | Decisiones precipitadas a la novena semana, que es cuando se pierde de verdad |
15. De migración a política de migraciones
Los checklists tratan la migración como un acontecimiento único. En cualquier sitio mediano no lo es: hay rediseños por fases, lanzamientos por países, cambios de plantilla y reestructuraciones de categorías cada pocos meses. Todo eso son migraciones pequeñas y ninguna pasa por el proceso de arriba.
Lo que funciona es dejar por escrito una política mínima:
Qué cambios exigen revisión SEO previa. Cualquier cambio de URL, de plantilla, de navegación o de renderizado. Un cambio de color, no.
Quién firma. Una persona responsable del mapa de redirecciones y una del despliegue. Si no hay nombres, no hay proceso.
Qué se documenta siempre. El mapa de redirecciones con fecha, la línea base previa y la anotación en la analítica. Tres cosas, en el mismo sitio, para todos los cambios.
Qué se revisa después. Un rastreo comparado a las 72 horas de cualquier despliegue grande, y la revisión de logs de la semana siguiente.
Con eso, la migración deja de ser un proyecto heroico cada cinco años y pasa a ser una rutina que ya sabe hacer el equipo.
16. Checklist completo
Decisión
- Justificación de negocio escrita y coste de la pérdida estimado
- Alternativa sin cambio de URL descartada de forma consciente
- Expectativa de seis meses hasta estabilización comunicada a dirección
Inventario y línea base
- Crawl completo del sitio actual, exportado
- Exportación de 16 meses de Search Console por URL
- Exportación de tráfico y conversiones por página
- URLs extraídas de los logs de 90 días
- Listado de URLs con backlinks
- Páginas huérfanas identificadas
- Recursos no HTML inventariados: PDFs, imágenes, feeds
- Páginas de gracias, confirmaciones y contenido cerrado incluidos
- Rankings de las palabras clave prioritarias, con fecha
- Core Web Vitals por plantilla
- Todas las URLs clasificadas: keep, update, merge, redirect, remove
Mapa de redirecciones
- Mapeo 1:1 completo, con destino equivalente
- Menos del 5 % de redirecciones a la home
- Sin orígenes duplicados ni cadenas
- Top 100 de tráfico y top 100 de backlinks revisados a mano
- Parámetros de campaña conservados en las reglas
- Reglas cargadas y probadas en staging
Staging
- Autenticación básica activa
- Rastreo comparado contra el sitio antiguo
- Sin canonicals ni enlaces al dominio de staging
- Sin
noindexno previstos - Datos estructurados validados con URLs nuevas
- Rastreo con Googlebot Smartphone, Desktop, Bingbot y GPTBot
- Paridad entre el HTML servido a bots y lo que ve el navegador
- hreflang completo y recíproco, si aplica
- Enlaces internos apuntando a las URLs finales, no a redirecciones
- Core Web Vitals medidos por plantilla
Día del lanzamiento
- TTL de DNS bajado 48 horas antes
- Propiedad del dominio nuevo verificada en Search Console, todas las variantes
- Ventana entre martes y jueves, por la mañana
- Autenticación básica retirada
-
noindexde staging eliminados y comprobados - Redirecciones activas
-
robots.txtdefinitivo, sinDisallow: / - Sitemap nuevo publicado y enviado en Search Console y Bing
- SSL válido en todas las variantes
- Analítica y píxeles disparando
- Formularios probados de verdad, hasta el CRM
- Cambio de dirección enviado para cada variante y subdominio
- Herramienta de mudanza de Bing enviada
- IndexNow avisado de las URLs prioritarias
- Anotación con fecha y hora en la analítica
- Rastreo completo del sitio en vivo
- Lista completa de URLs antiguas probada contra producción
Primeras 72 horas
- Cero errores 5xx
- 404 revisados y reglas añadidas
- Rastreo de Googlebot creciendo en el dominio nuevo
- Inspección de URL en una página de cada plantilla
- Conversiones funcionando
- Sitios con más enlaces contactados
90 días
- Revisión semanal de indexación por sección contra la línea base
- Logs revisados con regularidad, a diario el primer mes si el sitio es grande
- Cambio de dirección todavía dentro de su ventana de 180 días
- Redirecciones intactas, con plan de mantenerlas más de un año
- Enlaces internos apuntando a destinos finales
- Comparativa de Core Web Vitals contra la línea base
- Informe a 90 días con la comparación completa
17. Preguntas frecuentes
¿Cuánto tráfico se pierde en una migración?
Depende del tipo. En cambio de dominio, el estudio de SALT sobre 1.052 migraciones da una mediana de 304 días hasta recuperar la línea base, con solo un 22,8 % recuperado a los 90 días. Una migración que solo cambia el CMS conservando las URLs se comporta mucho mejor. Lo que no existe es la migración sin caída inicial.
¿Cuánto tiempo hay que mantener las redirecciones?
Google recomienda mantenerlas todo lo posible, y como mínimo un año. De cara al usuario, indefinidamente. Un fichero de reglas no ocupa nada y recuperar la autoridad perdida cuesta muchísimo más.
¿Se pierde autoridad en cada redirección 301?
No. Gary Illyes lo confirmó en 2016 y Google lo ha repetido desde entonces para 301, 302, 307 y 308. Pero cuidado con la conclusión: que el salto no pierda PageRank no significa que la página nueva vaya a posicionar igual. Si el destino no responde a lo mismo que el origen, pierdes posiciones aunque la autoridad se transfiera.
¿Tengo que usar la herramienta de cambio de dirección?
Solo si cambias de dominio o de subdominio. No sirve para pasar de HTTP a HTTPS, ni para cambiar de www a no-www dentro del mismo dominio, ni para mover carpetas. Y desde junio de 2026 Google especifica que hay que enviar una solicitud por cada subdominio y por cada variante con y sin www del dominio antiguo, no solo por el principal.
¿Cuánto dura el efecto de la herramienta de cambio de dirección?
180 días desde el envío. Pasado ese plazo, Google trata los dos sitios como no relacionados. Por eso las redirecciones tienen que seguir vivas mucho después.
¿Qué día conviene lanzar?
Entre martes y jueves, por la mañana temprano. La idea de lanzar el viernes por la noche viene de buscar el mínimo de tráfico, pero el coste real de una migración rota es el tiempo hasta detectarla, no las visitas de esa madrugada.
¿Puedo redirigir a la home lo que no tenga equivalente?
Solo como último recurso y en pocos casos. Google trata esas redirecciones como soft 404 y no transfiere señales. Si una URL antigua no tiene equivalente, casi siempre es mejor mandarla a la categoría padre.
¿404 o 410 para el contenido que retiro?
Da casi igual. John Mueller dijo en 2024 que la diferencia de procesamiento es tan pequeña que no se le ocurre un caso donde prefiera uno sobre otro. Si tu sistema devuelve 410 con facilidad, úsalo; si no, un 404 hace el mismo trabajo.
¿Afecta la migración a que ChatGPT o Perplexity me citen?
Puede afectar, aunque todavía no hay estudios sólidos. Los índices de esos motores se refrescan más despacio que el de Google y esos bots no ejecutan JavaScript, así que una migración que cambie el renderizado puede dejarte fuera de sus respuestas aunque conserves posiciones. Mantén estables las URLs de los contenidos que ya te citan y conserva el marcado estructurado.
¿Sirve de algo Bing en una migración?
Sí, y más ahora. Bing tiene su propia herramienta de mudanza de sitio, admite movimientos parciales por subdominio y directorio, y su función AI Performance da una línea base de citas en Copilot desde febrero de 2026. Como Bing alimenta parte de las respuestas de IA, dejarlo fuera cuesta visibilidad que antes no existía.
¿Debo aprovechar la migración para eliminar contenido?
Sí, es el mejor momento. Migrar contenido que lleva dos años sin recibir visitas ni enlaces es arrastrar trabajo y espacio de rastreo. Clasifica antes de mapear y retira lo que no aporte, con criterio y no a bulto.
18. Qué hacer con todo esto
Si tienes una migración en el calendario, el orden de prioridad es este.
Primero, congela la línea base hoy. Exporta los 16 meses de Search Console, el tráfico por página y los rankings. Es gratis, tarda una hora y sin eso no podrás demostrar nada dentro de tres meses.
Segundo, saca las URLs de los logs. Es lo que separa un inventario bueno de uno que va a generar cientos de 404 evitables.
Tercero, revisa a mano las 200 URLs más importantes del mapa: las 100 con más tráfico y las 100 con más enlaces. El resto puede salir de un cruce automático; esas no.
Y cuarto, ajusta la expectativa temporal antes de lanzar, no después. Es la conversación más incómoda del proyecto y la que evita las decisiones precipitadas del segundo mes.
Cuándo compensa pedir ayuda
Puedes llevar la migración con tu equipo si el sitio es manejable, las URLs cambian poco y hay alguien que sepa leer un crawl comparado.
Busca apoyo externo cuando haya cambio de dominio, cuando se consoliden varios sitios en uno, cuando entre hreflang de por medio, cuando el catálogo sea grande y tenga facetas, o cuando la migración cambie también el renderizado. Son los cinco escenarios donde el coste de un error supera con mucho el de una revisión previa.
En Consultoría SEO Sevilla trabajamos las migraciones desde el diagnóstico previo: auditoría técnica para saber qué estás moviendo, auditoría de arquitectura e indexación para decidir qué se conserva y qué se consolida, y auditoría de ecommerce cuando hay catálogo y feeds de por medio. Puedes verlas todas en la página de auditorías SEO.
Si tienes fecha de migración, escríbenos aquí. El momento útil para revisarla es antes, no en la semana cuatro.
Si tienes una migración en el calendario y prefieres que alguien revise el mapa antes de tocar el DNS, escríbenos y lo miramos.
