SOP: recuperación SEO después de una migración web

Una recuperación SEO post-migración debe resolver tres señales en este orden: redirigir cada URL antigua relevante a su reemplazo final, publicar canonicals correctos y ofrecer sitemaps con URLs absolutas del dominio de producción. El sitemap facilita el descubrimiento, pero no compensa una página histórica que ahora responde 404 ni un canonical que apunta a localhost.

Este SOP explica cómo diagnosticar, corregir y verificar una migración de un CMS —por ejemplo, WordPress— a una aplicación con renderizado del lado servidor, como Nuxt. El objetivo no es prometer una recuperación inmediata, sino restaurar señales rastreables y consistentes sin romper las rutas nuevas.

Resumen operativo

1. Conserva evidencia de Google Search Console, analytics, sitemaps y backlinks.
2. Construye un inventario priorizado de URLs antiguas y destinos nuevos.
3. Implementa redirects permanentes directos, sin cadenas ni redirecciones masivas a la home.
4. Genera canonical, hreflang, Open Graph y datos estructurados desde una única URL base.
5. Publica sitemaps con URLs canónicas absolutas y registra el sitemap nuevo en Search Console.
6. Prueba respuestas HTTP, HTML renderizado y XML antes y después del despliegue.
7. Monitorea cobertura, clics y errores mientras Google vuelve a procesar el sitio.

El patrón de falla: tres problemas que se potencian

En el caso anonimizado que originó este procedimiento, el sitio perdió cerca del 85 % de su tráfico orgánico en pocas semanas. Las páginas indexadas bajaron de 76 a 34, y una URL que había acumulado más de 1,100 clics durante el último año comenzó a devolver 404.

No había una sola causa:

Problema	Señal que recibió Google	Consecuencia observable
Las URLs antiguas no tenían redirects permanentes	El contenido conocido dejó de existir	Errores 404 y pérdida de continuidad entre URLs
El canonical apuntaba a localhost	La supuesta versión preferida no era pública	Señales canónicas contradictorias o inutilizables
Los sitemaps contenían localhost y seguía registrado el sitemap anterior	Las URLs declaradas no coincidían con producción	Descubrimiento y diagnóstico más difíciles

La falta de redirects era la urgencia principal. Los otros dos errores impedían que Google interpretara con claridad el sitio nuevo. Por eso conviene tratar la recuperación como un sistema: historial de URL, identidad canónica y descubrimiento deben converger en el mismo destino.

1. Congela la evidencia antes de cambiar el sitio

No empieces con una lista de slugs recordados de memoria. Exporta y combina:

• páginas y consultas de Search Console, idealmente con clics e impresiones;
• landing pages orgánicas de analytics;
• URLs de los sitemaps antiguos;
• rutas rastreadas desde el sitio anterior o recuperadas de logs;
• backlinks relevantes;
• archivos descargables e imágenes con enlaces externos;
• las rutas actuales del sitio nuevo.

Conserva esta evidencia fuera del código y elimina datos personales o secretos antes de compartirla. Si el problema incluye que la home dejó de aparecer por su marca, complementa este procedimiento con la guía para recuperar la homepage en los resultados de Google.

Prioriza por impacto y no solo por cantidad

Clasifica primero las URLs con clics, impresiones, conversiones o backlinks. Después atiende servicios, categorías, posts, archivos estáticos y listados históricos. Una ruta con 1,100 clics merece revisión manual; una taxonomía sin tráfico puede resolverse mediante una regla documentada.

El entregable de esta etapa es una tabla con, al menos:

URL antigua	Destino final	Tipo	Prioridad	Evidencia	Estado esperado
/articulo-anterior	/articulos/guia-actual	Post	Alta	Clics y backlinks	301 → 200
/servicios/legacy/a	/servicios/a	Servicio	Alta	Impresiones	301 → 200
/recurso-retirado	Sin reemplazo	Eliminada	Baja	Sin demanda	410

2. Implementa redirects permanentes como una fuente de verdad

Google recomienda mapear las URLs antiguas a las nuevas y usar redirects permanentes del lado del servidor, normalmente 301 o 308. Cada salto debe llegar al destino final; evita cadenas como A → B → C. Consulta la documentación oficial de migraciones con cambios de URL.

Crea un solo mapa versionado y un resolvedor pequeño. Normaliza la ruta antes de buscarla:

• ignora query strings y fragmentos para el matching, salvo que formen parte real de la identidad del contenido;
• trata la barra final de forma consistente;
• cubre prefijos de idioma si existen;
• diferencia coincidencias exactas de reglas por patrón;
• impide bucles y destinos que también redirigen.

Un diseño independiente del framework puede verse así:

const permanentRedirects: Record<string, string> = {
  "/articulo-anterior": "/articulos/guia-actual",
  "/servicios/legacy/a": "/servicios/a",
};

export function resolveLegacyPath(input: string) {
  const path = normalizePath(input);
  return permanentRedirects[path] ?? null;
}

Ejecuta este resolvedor en middleware, edge o servidor antes de renderizar la aplicación. Añade pruebas para rutas exactas, barra final, prefijos de idioma, query strings y rutas actuales que no deben redirigir.

No conviertas la home en un destino universal

La relación entre URL antigua y nueva debe ser semántica. Redirigir todo lo eliminado a la home confunde a usuarios y puede producir soft 404. Si no existe un reemplazo razonable, una respuesta 404 o 410 es más honesta. La regla práctica es sencilla: redirect cuando haya continuidad; 404/410 cuando el recurso terminó sin equivalente.

Mantén los redirects al menos un año, como recomienda Google. Conservarlos por más tiempo suele seguir ayudando a visitantes y enlaces externos antiguos.

3. Usa una sola URL base para todas las señales canónicas

Un canonical con localhost es un fallo de configuración que debe bloquear el despliegue. Define una utilidad común que:

1. lea la URL pública desde la configuración del entorno;
2. valide protocolo y host;
3. rechace localhost, IPs internas o valores vacíos en producción;
4. normalice el origen sin barra final;
5. construya URLs absolutas de manera consistente.

Usa esa utilidad para:

• rel="canonical";
• enlaces hreflang y x-default;
• og:url;
• URLs de JSON-LD;
• sitemaps y robots.txt.

Cada página indexable debe declarar su URL pública preferida. Google considera redirects y rel="canonical" señales fuertes; incluir una URL en el sitemap es una señal más débil. Revisa la guía de canonicalización de URLs duplicadas.

En sitios multilenguaje, cada idioma debe tener una URL propia y referencias hreflang recíprocas. No uses el idioma del navegador para ocultar todas las variantes detrás de una misma URL.

4. Reconstruye sitemaps útiles, no decorativos

El sitemap nuevo debe incluir únicamente URLs canónicas publicables, absolutas y con el host de producción. Puede ser un solo archivo o un índice con sitemaps hijos para páginas, posts u otros tipos de contenido.

Verifica que:

• todas las URLs respondan 200 y sean indexables;
• no aparezcan localhost, entornos de preview ni rutas redirigidas;
• lastmod refleje cambios sustanciales y no se regenere falsamente en cada build;
• los alternates hreflang correspondan a páginas reales;
• robots.txt declare la ubicación del sitemap principal.

Google exige URLs completas en los sitemaps y aclara que enviarlos es una pista, no una garantía de rastreo o indexación. Consulta la guía oficial para crear y enviar un sitemap.

Qué hacer con el sitemap anterior

Durante una migración, Google recomienda enviar un sitemap de las URLs nuevas y puede ser útil mantener temporalmente otro con URLs antiguas para observar cómo se procesan los redirects. Es normal que el reporte de las URLs antiguas muestre advertencias por redirección. Una vez que la migración se haya procesado, retira el sitemap antiguo de Search Console.

Esto es más preciso que asumir que toda ruta histórica de sitemap debe seguir sirviendo XML para siempre. Lo importante es que el plan sea explícito, medible y coherente con el estado de las URLs.

5. Despliega y verifica por capas

Una revisión visual no basta. Automatiza controles que fallen cuando detecten:

• localhost o un dominio de preview en HTML, JSON-LD, robots o XML;
• canonicals relativos, duplicados o distintos de la URL esperada;
• destinos de redirect que no responden 200;
• cadenas, bucles y redirecciones internas innecesarias;
• URLs no canónicas dentro del sitemap;
• pares hreflang incompletos.

Para cada ruta prioritaria, registra este recorrido:

URL antigua → 301/308 → URL final → 200
URL final → canonical absoluto de sí misma
Sitemap → URL final, nunca URL antigua o localhost

Haz pruebas contra una build equivalente a producción y repítelas sobre el dominio público después del deploy. La variable de entorno correcta y el comportamiento real del CDN no se validan por completo en local.

6. Completa las tareas de Search Console

Después de publicar:

1. envía el sitemap nuevo;
2. inspecciona las URLs con mayor impacto y solicita indexación cuando corresponda;
3. valida la corrección de 404 después de comprobar que el redirect ya está activo;
4. monitorea indexación, clics e impresiones por grupos de URL;
5. conserva una anotación de la fecha de migración y de cada despliegue correctivo.

No interpretes cada fluctuación diaria como un incidente nuevo. Google advierte que los cambios de visibilidad son normales durante una migración y que un sitio pequeño o mediano puede tardar varias semanas en mover la mayoría de sus páginas.

Criterios de salida del SOP

La remediación puede considerarse técnicamente completa cuando:

• todas las URLs antiguas prioritarias tienen un resultado documentado;
• los redirects van directamente a destinos 200 y no forman bucles;
• canonical, hreflang, Open Graph y JSON-LD usan el dominio público correcto;
• los sitemaps contienen solo URLs absolutas, canónicas e indexables;
• no aparece localhost en ningún artefacto de producción;
• Search Console recibió el sitemap nuevo y existe un plan de monitoreo;
• el mapa de redirects y sus pruebas quedan versionados para futuras revisiones.

Preguntas frecuentes

¿Qué se debe corregir primero después de una migración SEO fallida?

Empieza por las URLs antiguas con tráfico, enlaces o conversiones y redirígelas directamente a su equivalente nuevo. Después alinea canonicals, hreflang y sitemaps con esos destinos.

¿Conviene redirigir todas las páginas eliminadas a la home?

No. Usa el reemplazo más equivalente. Si no existe uno útil, devuelve 404 o 410 para evitar una señal de soft 404.

¿Cuánto tiempo deben mantenerse los redirects?

Google recomienda al menos un año. Mantenerlos durante más tiempo suele beneficiar a usuarios y enlaces antiguos.

¿Un sitemap nuevo recupera por sí solo el tráfico perdido?

No. Facilita el descubrimiento, pero la recuperación exige redirects correctos, canonicals coherentes, contenido accesible y tiempo para que Google vuelva a rastrear el sitio.