La pregunta pre-lanzamiento de la que depende toda migración
La mayoría de las migraciones de sitio fallan de la misma forma aburrida: una URL que rankeaba deja de resolver, nadie se da cuenta durante dos semanas y cuando se detecta la redirección perdida el equity ya se ha drenado de la página. Cada retrospectiva de migración a la que he asistido podría haber sido una viñeta de una línea — "lanzamos sin un diff completo de URLs contra el sitemap antiguo" — y la lección aterriza igual cada vez. El diff es barato. La recuperación de saltárselo no lo es.
Este artículo recorre cómo uso realmente un comparador de sitemaps el día antes, durante y después de una migración. No es teoría — es la checklist que mantengo abierta en una pestaña al lanzar un cambio de dominio, un cambio de CMS, una reestructuración de IA o un rediseño mayor. La herramienta referenciada es el Comparador de Sitemaps, que se ejecuta enteramente en tu navegador, pero el playbook funciona con cualquier diff que exponga cuatro grupos: Comunes, Solo en A, Solo en B y Similares.
Por qué los sitemaps ganan a los crawls para este trabajo específico
Un crawl completo con Screaming Frog produce un dataset más rico que un sitemap — códigos de estado, flags de indexabilidad, cabeceras de respuesta, conteos de enlaces internos, relaciones hreflang, señales de canonicalización. Para la mayoría de auditorías pre-lanzamiento, todo eso importa. Pero para la pregunta concreta de "qué URLs existían antes y no existen después", un diff de sitemap es la forma correcta de herramienta: rápido, reproducible, no requiere presupuesto de crawl y las entradas (sitemaps XML) son exactamente los artefactos que ambos lados de la migración ya publican.
El trade-off es ser honesto sobre lo que incluyen los sitemaps. Un sitemap bien mantenido declara las URLs que el sitio considera canónicas e indexables — lo que casi siempre es un conjunto más pequeño que las URLs que realmente tienen equity. Las páginas con tráfico de cola larga, los archivos profundos de artículos y las landing pages de campañas antiguas suelen ser podadas del sitemap mucho antes de dejar de recibir visitas orgánicas. El diff captura el gap sitemap-a-sitemap; un análisis de logs de servidor o una exportación de crawl stats de Search Console captura el gap sitemap-a-realidad. Ejecuta ambos. El diff es el barato primer 80%.
Paso 1: consigue ambos sitemaps limpiamente
Antes de abrir cualquier herramienta, consigue los dos archivos XML en local. Para el sitemap "antes", guarda la versión live de producción: curl https://example.com/sitemap.xml -o sitemap-antes.xml o simplemente clic derecho → Guardar como en tu navegador. Para el sitemap "después", coge el sitemap de la nueva build desde staging o pre-producción. Si la nueva build usa un índice de sitemap, guarda también todos los sitemaps hijos — los necesitarás en el paso tres.
Guárdalos con nombres sensatos — sitemap-prod-2026-05-22.xml y sitemap-staging-2026-05-22.xml — y déjalos en una carpeta junto al plan de migración. Tres semanas después cuando alguien pregunte "cómo se veía el sitemap el día del lanzamiento", tendrás la respuesta. Es el rastro de auditoría más barato posible; no te lo saltes.
Paso 2: ejecuta el primer diff con los valores por defecto
Abre el Comparador de Sitemaps, pega el sitemap antes en el panel A y el después en el panel B, deja cada opción en su valor por defecto y pulsa Comparar. La normalización por defecto (host en minúsculas, eliminar barra final, descartar www., ignorar http vs https, ordenar parámetros) colapsa todas las diferencias cosméticas en el grupo Comunes. Esto es lo que quieres en el primer pase — centrarte en URLs que realmente cambiaron, no en el ruido de la emisión inconsistente de URLs entre dos sistemas de renderizado distintos.
Lee primero la barra de estadísticas. El número titular es el tamaño del grupo Solo en A — cada URL ahí es candidata a 301. Si Solo en A es enorme (digamos, el 30% del total), algo estructural cambió: una categoría se renombró, un patrón de slug cambió, una migración de CMS cambió todas las URLs. Si Solo en A es pequeño (de un dígito), la migración es en gran medida un cambio de piel y tu mapa de redirecciones será corto. Cualquiera está bien; lo que importa es saber con qué tipo de migración estás tratando antes de empezar a mapear redirecciones.
Paso 3: trabaja la pestaña Similares — tu borrador 301
La pestaña Similares es donde la herramienta gana su sueldo. Tras la comprobación de igualdad, cada URL aún en Solo en A se empareja por similitud Levenshtein con cada URL aún en Solo en B. Los pares por encima del umbral (0.85 por defecto) salen como probables renombres con el score de similitud al lado.
Recorre la lista de arriba abajo. Cualquier cosa al 95%+ es casi seguro un renombre real — una corrección de erratas en el slug, una actualización de marca de año (/precios-2024/ → /precios/), una simplificación de ruta (/productos/widget/ → /p/widget/). Apruébalos directamente en tu mapa 301. El rango 85–95% merece una mirada rápida: normalmente renombres reales, ocasionalmente falsos positivos donde dos URLs no relacionadas comparten una subcadena. Si ves un cluster de falsos positivos, sube el umbral a 0.90 o 0.92 y recompara — el coste es perder algunos renombres sutiles, el beneficio es un borrador más limpio que puedes aprobar más rápido.
Una vez aprobados los pares, exporta la pestaña Similares a CSV. Ábrelo en Sheets, añade una columna "aprobado", marca cada fila y el resultado es la primera mitad de tu mapa 301 lista para pegar en tu config de redirecciones, en tus reglas de edge del CDN o en la tabla de redirecciones de tu CMS.
Paso 4: caza redirecciones perdidas en Solo en A
Cada URL aún en Solo en A tras el pase de Similares — es decir, que la herramienta no pudo emparejar con nada en Solo en B — necesita una decisión explícita. Hay tres resultados legítimos:
- Redirige al sustituto temático más cercano. La página antigua cubría un tema que aún existe en el nuevo sitio, solo que en una URL distinta. Mapea un 301 al nuevo hogar de ese tema. Ejemplo: una antigua página archivo
/blog/categoria/precios/redirigida a la nueva landing/precios/al eliminar la estructura de archivo del blog. - Retira la URL con un 410 Gone. La página cubría algo que el nuevo sitio ya no ofrece. Un 410 es más honesto que un 301 a la home y los crawlers la sacarán de su índice más rápido, que es lo que quieres para contenido retirado.
- Restaura la URL en el nuevo sitio. La página se retiró por accidente — quizás se coló en una revisión de contenido, quizás un script de migración del CMS pasó por alto un tipo de contenido. Si la página debería seguir existiendo, restáurala antes del lanzamiento en vez de tapar el hueco con una redirección.
Decidas lo que decidas, decídelo explícitamente. Cada URL en Solo en A que no tenga redirección, ni 410, ni equivalente restaurado será un 404 en el momento del corte. No hay una cuarta opción de "ya lo arreglaremos luego" — luego significa que Search Console ya está reclamando y las posiciones ya están cayendo.
Paso 5: audita Solo en B en busca de polución y huérfanos
Solo en B recibe menos atención que Solo en A pero merece un pase cuidadoso. Los dos modos de fallo son:
- Polución de sitemap. URLs que no deberían estar ahí — URLs solo de staging que se han filtrado al sitemap de producción, páginas de navegación facetada que deberían ser noindex, páginas duplicadas de un constructor de URLs descuidado, rutas de debug dejadas activas. Son bloqueadores de lanzamiento; arregla el sitemap antes de poner en vivo.
- Páginas huérfanas. URLs que existen en el nuevo sitio pero no reciben ningún enlace interno desde contenido que ya existía en el sitio antiguo. Serán rastreadas porque están en el sitemap, pero les costará acumular equity porque no apuntan enlaces entrantes. Planifica un pase editorial para tejerlas en el grafo de enlaces internos existente antes de que envejezcan.
Exporta la pestaña Solo en B a CSV y triagea cada fila en una de tres columnas: lanzar tal cual, arreglar el sitemap antes del lanzamiento, planificar enlaces internos post-lanzamiento. La mayoría de filas estarán en la primera columna — es normal. Las otras dos son donde se esconden los problemas.
Paso 6: sanity-check en la pestaña Comunes
El grupo Comunes es el aburrido — URLs que existen en ambos lados, no requieren redirección, se lanzan tal cual. Mira el recuento y compáralo con tu modelo mental de la migración. Si esperabas un overlap del ~90% y ves un 60%, algo va mal: o tus interruptores de normalización no cubren una diferencia cosmética sistemática (prueba alternándolos uno a uno para ver dónde caen las URLs), o hay una reestructuración más dramática de lo que creías y las columnas Solo en A / Solo en B esconden la verdad.
Un check rápido a ojo: scrollea la pestaña Comunes y verifica que tus tres o cuatro URLs más importantes están ahí — la home, la página principal de producto, la página canónica de precios, tu post de blog con más tráfico. Si alguna de esas cayó en Solo en A, para todo y averigua por qué antes de continuar.
Paso 7: combina con Search Console y logs de servidor
El diff de sitemap cubre las URLs que el propio sitio declara. No capturará URLs que no están en ninguno de los dos sitemaps pero aún reciben tráfico orgánico — las páginas de cola larga que nadie recordó añadir al sitemap cuando se publicaron hace años. Dos seguimientos baratos cierran ese hueco:
Exporta las top 1.000 URLs de Google Search Console (Rendimiento → Páginas → exportar). Pasa cada una por tu mapa de redirecciones: cualquier URL que genere clics hoy y no esté ni en el grupo Comunes ni en tu lista 301 es un riesgo oculto. Añádela explícitamente al plan de redirecciones.
Si tienes acceso a logs de servidor, grepea las rutas que Googlebot ha solicitado realmente en los últimos 90 días. Mismo ejercicio: cualquier cosa que Googlebot haya rastreado y no esté cubierta ni por tu diff de sitemap ni por tu mapa de redirecciones es candidata a añadir. Los logs de servidor capturan las URLs que Search Console no te enseñará porque están demasiado abajo en la cola larga como para entrar en el informe de top pages.
Paso 8: verifica post-lanzamiento con un crawl de códigos de estado
Tras el lanzamiento de la migración, ejecuta un crawler (Screaming Frog, Sitebulb, el crawler integrado de tu CI, o simplemente xargs -I{} curl -sIL -o /dev/null -w "%{http_code} %{url_effective}\n" {} < urls-antiguas.txt para los casos destacados) contra cada URL de tu sitemap antes. Cada URL debe devolver 200 (sigue resolviendo) o 301 → 200 (redirección a una página viva). Cualquier cosa que devuelva 404, 410-cuando-debería-ser-301 o 302-cuando-debería-ser-301 es un bug que arreglar inmediatamente.
Guarda el informe del crawl junto con los snapshots originales de sitemap del Paso 1. Tres semanas después, cuando el equipo de SEO pregunte "¿están cubiertas todas las URLs antiguas?", puedes apuntar al informe en vez de adivinar. Tres meses después, cuando empiece la siguiente migración, tienes una referencia de cómo se ve "hecho".
Variaciones: cuándo este flujo se adapta
El flujo anterior asume una migración de un solo idioma y un solo dominio. Algunas variaciones comunes:
Sitios multi-idioma: ejecuta el diff por idioma. Empareja /en/sitemap.xml contra el nuevo /en/sitemap.xml, luego /es/ contra /es/. Los diffs mezclados de idiomas producen ruido porque los pares de traducción caen en Solo en A y Solo en B aunque no hayan cambiado estructuralmente.
Cambios de dominio: los interruptores de normalización del host gestionan www vs apex, pero un cambio completo de dominio (sitioantiguo.com → sitionuevo.com) pondrá cada URL en Solo en A y Solo en B. Desactiva la comparación de host completamente escribiendo un pequeño paso de preprocesamiento que reescriba el host del panel A para coincidir con el panel B antes de pegar, o confía enteramente en la pestaña Similares — con umbrales altos emparejará URLs a través del cambio de dominio con precisión.
Índices de sitemap: la herramienta marca las entradas de índice con un aviso. Procesa cada sitemap hijo por separado, o concaténalos localmente antes de pegar si el recuento total de URLs es manejable (menos de ~50.000 URLs combinadas).
Una nota sobre privacidad
Los sitemaps que manejas en una migración son sensibles — a menudo contienen URLs de staging, contenido pre-lanzamiento, trabajo confidencial de cliente y crawls de competencia. El Comparador de Sitemaps se ejecuta enteramente en tu pestaña del navegador; nada se sube, nada se loguea, nada se persiste en un servidor. Puedes verificarlo en DevTools (panel Network → pulsa Comparar → confirma cero peticiones salientes). Para trabajo de cliente bajo NDA esto no es un nice-to-have — es la única arquitectura aceptable.
El coste de saltarse esto
He auditado migraciones que se saltaron un diff de sitemap. Cada una de ellas tenía al menos una URL significativa que dejó de resolver — normalmente una landing de categoría o un artículo tentpole que desapareció silenciosamente del nuevo sitemap. La recuperación se ve igual cada vez: un email de pánico tres semanas después del lanzamiento, una redirección añadida con prisa sin probar, una recuperación lenta de posiciones durante el siguiente trimestre. El diff en sí lleva 30 segundos con una herramienta comparadora. El coste de saltárselo se mide en pérdida de tráfico orgánico durante meses. Ejecuta el diff.