La migración ya salió mal: cómo recuperar el tráfico, y en qué orden

Respuesta breve

Cuando el tráfico se cae después de una migración, lo primero que hay que hacer para recuperarlo no es tocar nada: es reconstruir el inventario de URLs que existía antes y comprobar, una a una, qué responde cada una hoy. La mayoría de las caídas se explican por redirecciones que faltan, cadenas que se encadenan, canónicas que apuntan al sitio viejo o plantillas que perdieron su contenido por el camino, y todas se arreglan. Lo que no vuelve es lo que se decidió eliminar sin sustituto, así que el orden importa: primero se restituye el acceso, después se comprueba que el contenido dice lo mismo, y solo al final se plantea mejorar nada.

Puntos clave

• Sin el inventario de URLs anterior no hay diagnóstico posible: es el primer trabajo, y a veces el más difícil.
• Una redirección que existe no es una redirección correcta: hay que comprobar el destino, no el código.
• Una caída por acceso se ve en días; una por contenido tarda semanas en manifestarse y en corregirse.
• El sitio viejo, si sigue accesible, es la mejor fuente para reconstruir lo que se perdió.
• No todo lo que baja es culpa de la migración: hay que descartar una actualización del algoritmo y la estacionalidad antes de acusar.
• Lo que se eliminó a propósito y no tenía sustituto no se recupera; conviene decirlo pronto y dejar de buscarlo.

Antes de tocar nada: el inventario

Una migración cambia a la vez el CMS, las plantillas, las URLs y a menudo el servidor. Con cuatro variables movidas, cualquier hipótesis sin datos es una apuesta. El inventario es la lista de URLs que existían antes y que tenían valor: las que recibían clics, las que tenían enlaces entrantes y las que estaban indexadas.

Se reconstruye de tres fuentes, en este orden de fiabilidad: el informe de rendimiento de Search Console del periodo anterior a la migración, el sitemap del sitio antiguo si aún se conserva, y un rastreo del sitio viejo si sigue accesible en algún sitio. Si nada de eso existe, quedan las copias de seguridad y los archivos públicos de la web, que son peores pero no son nada.

El inventario no es una curiosidad: es el patrón contra el que se compara todo lo demás. Sin él se acaba arreglando lo que llama la atención en vez de lo que perdió tráfico.

El orden del diagnóstico

Las causas se revisan de abajo arriba, igual que en cualquier diagnóstico técnico, porque una capa rota hace inútil el trabajo de las de arriba.

1. ¿Responde la URL? Un 404 en una URL que recibía clics es la pérdida más cara y la más fácil de arreglar. Se comprueba el inventario completo, no una muestra.
2. ¿Redirige al sitio correcto? Una redirección que lleva a la portada en vez de a la página equivalente conserva el código 301 y pierde el motivo por el que alguien llegaba. Redirigir todo a la home es la forma más común de fingir que no se perdió nada.
3. ¿En un salto? Las cadenas de redirecciones se acumulan cuando se migra dos veces. Funcionan para el visitante y diluyen el trabajo del rastreador.
4. ¿Es indexable? Una plantilla que arrastra un noindex del entorno de pruebas puede vaciar el sitio en semanas sin que nadie vea nada raro en pantalla.
5. ¿La canónica apunta al sitio nuevo? Una canónica al dominio antiguo le dice al buscador que la versión buena es la que acabas de retirar.
6. ¿El contenido dice lo mismo? Es el último paso y el que más se salta: una página que responde 200 puede haber perdido la mitad del texto en la conversión de plantillas.

Distinguir una caída de acceso de una de contenido

Las dos se ven igual en la gráfica y se arreglan de forma distinta, así que conviene separarlas antes de trabajar.

Una caída de acceso es abrupta y afecta a bloques enteros de URLs: una sección completa, un tipo de contenido, todo lo que colgaba de una ruta. Se corresponde con el día de la migración, no con un día cualquiera. En Search Console aparece como aumento de las excluidas por error o por redirección, y las impresiones se van con los clics.

Una caída de contenido es más lenta y desigual: unas páginas mantienen posición y otras bajan varios puestos durante semanas. Las impresiones aguantan mejor que los clics al principio. Suele venir de textos recortados, encabezados perdidos, títulos reescritos por la plantilla nueva o datos estructurados que dejaron de emitirse.

Y hay una tercera posibilidad que hay que descartar antes de acusar a la migración: que coincidiera con una actualización del algoritmo o con la estacionalidad del sector. Se comprueba mirando si bajan también las páginas que no se tocaron y comparando con el mismo periodo del año anterior. Si todo baja por igual, incluida la parte del sitio que no se migró, el sospechoso es otro; ese caso se trata en la caída tras una actualización del núcleo, que no se arregla con redirecciones.

Lo que no vuelve

Conviene decirlo pronto para dejar de buscarlo. No se recupera el tráfico de las páginas que se eliminaron a propósito y no tienen sustituto razonable: redirigirlas a algo que no responde a la misma necesidad no devuelve la posición y además ensucia el sitio. Tampoco vuelve solo lo que llevaba meses cayendo antes de migrar, porque la migración no era la causa.

Y hay un coste que no se ve en ninguna gráfica: el tiempo. Aunque el arreglo sea correcto, el buscador tiene que volver a rastrear, procesar y reevaluar cada URL, y eso ocurre a su ritmo. Un sitio pequeño se reordena en semanas; uno grande, en meses.

El caso de esta web

Esta web migró de WordPress a un sitio estático en septiembre de 2026, y la parte cara fue exactamente esta: los cincuenta artículos vivían en la raíz del dominio y pasaron a colgar de /blog/. Sin una redirección por pieza, la migración habría convertido en 404 todo el contenido indexado. Está contado, con lo que no mejoró incluido, en el caso de la migración de esta web.

La lección transferible no es la receta técnica, que depende del CMS: es que la comprobación se hace sobre el sitio servido y no sobre la configuración. Un mapa de redirecciones perfecto en un fichero no dice nada hasta que se pide cada URL y se mira qué contesta.

En tres láminas

6 comprobaciones, en orden. Responde, redirige al sitio correcto, en un salto, es indexable, la canónica apunta al sitio nuevo y el contenido dice lo mismo.

Antes de tocar la configuración: 1. Reconstruir el inventario → 2. Comprobar acceso → 3. Comprobar destino → 4. Comprobar indexabilidad → 5. Comparar contenido → 6. Y solo entonces, mejorar

comprobación: $ curl -sI https://sitio/url-antigua/ / HTTP/1.1 301 / location: https://sitio/url-nueva/ / / # 200 en la URL vieja: la redirección falta / # 301 a la portada: se perdió la intención / # 301 a otra 301: cadena que hay que acortar

Errores frecuentes

• Redirigir todas las URLs perdidas a la portada. Conserva el 301 y pierde la intención de cada visita.
• Comprobar una muestra en vez del inventario. Las pérdidas se concentran justo donde nadie mira.
• Dar por buena una redirección por su código de estado sin abrir el destino.
• Retirar el sitio antiguo el mismo día. Mientras siga accesible es la mejor fuente para reconstruir lo que falta.
• Empezar por mejorar el contenido cuando la mitad de las URLs no responden.
• Atribuir a la migración una caída que empezó antes, sin comparar con las páginas que no se tocaron.

Preguntas habituales

¿Cuánto se tarda en recuperar el tráfico? Depende del tamaño del sitio y de qué se rompió. La parte de acceso —redirecciones, códigos de estado, indexabilidad— se corrige en días y el buscador la reevalúa en semanas. La de contenido tarda más porque exige que vuelva a evaluar cada página. Prometer un plazo concreto sin haber visto el inventario es inventarlo.

¿Sirve volver atrás? Casi nunca, y cada vuelta atrás es otra migración con su propio riesgo. Solo se plantea cuando el sitio nuevo no se puede arreglar en un plazo razonable y el antiguo sigue completo.

¿Hay que enviar otra vez el sitemap? Sí, con las URLs nuevas y sin las viejas, y ayuda al descubrimiento. Pero enviar un sitemap no repara nada: si las redirecciones están mal, el sitemap solo hace que se descubran antes las que están mal.

Próximo paso

Reconstruye el inventario antes de tocar una línea de configuración: exporta el informe de rendimiento del trimestre anterior a la migración y quédate con las URLs que recibieron clics. Esa lista, y no el sitemap nuevo, es la que hay que recorrer entera comprobando código de estado, destino final, indexabilidad y canónica.

Si la migración todavía no ha ocurrido, el trabajo es otro y sale mucho más barato: está en cómo migrar sin perder posiciones.

Fuentes

• Google Search Central, SEO Starter Guide — RS-005.
• Google Search Central, políticas de datos estructurados — RS-008.
• Observación propia de la migración de SEONIDAS del 03-09-2026, contada en su propio análisis — RS-001.

Servicio relacionado

Si esto es lo que te está pasando, migraciones seo es el trabajo que lo resuelve. Diagnóstico primero, prioridades después.

Ver migraciones seo