Por qué el diff de sitemaps es clave en una migración
Las migraciones de sitio — cambio de dominio, cambio de CMS, rediseños, despliegues de idiomas, rehaceres de IA — comparten un mismo modo de fallo: URLs que existían en el sitio antiguo y no quedan redirigidas en el nuevo. Cada URL sin mapear es un 404 en el momento del despliegue, lo que significa pérdida de equity de crawl, pérdida de posiciones, pérdida de tráfico referido y, si dependes de búsqueda orgánica, pérdida de ingresos. El trabajo de la migración no consiste solo en publicar las páginas nuevas; consiste en garantizar que cada URL que importaba antes siga resolviendo a algo útil después.
El diff de sitemaps es la forma más barata y rápida de detectar la brecha. Un sitemap XML es la propia declaración del sitio sobre qué considera rastreable e indexable. Comparado a través de la frontera de la migración — sitemap antiguo vs sitemap nuevo — el diff te dice exactamente qué URLs se quedaron atrás, cuáles son nuevas y cuáles parecen renombres que necesitan 301 explícito. Herramientas de crawl como Screaming Frog o Sitebulb ofrecen señales más ricas (códigos de estado, cabeceras, conteos de enlaces internos) pero son más lentas, más caras y excesivas para un sanity check rápido el día antes del lanzamiento.
Qué te aporta la normalización de URLs
Dos sitemaps generados por sistemas distintos casi nunca coinciden en detalles cosméticos: uno emite barra final, el otro no; uno usa www., el otro no; uno ordena parámetros alfabéticamente, el otro en orden de declaración; uno escribe los hostnames en minúsculas, el otro pone el protocolo en mayúsculas. Nada de esto son diferencias reales en cómo se sirve la página — casi todos los servidores canonicalizan estos casos — pero una comparación de cadenas ingenua las trata como URLs completamente distintas.
La normalización colapsa esas variantes cosméticas en una forma canónica antes de ejecutar la comparación. Por defecto, esta herramienta pone el host en minúsculas, elimina la barra final en rutas no raíz, descarta el prefijo www., ignora http frente a https y ordena los parámetros alfabéticamente. El diff opera sobre la forma normalizada, así las URLs que solo difieren cosméticamente caen en el grupo Comunes donde deben estar. Cada normalización es un interruptor independiente: si te importa específicamente, por ejemplo, http frente a https como diferencia real, desactiva la normalización de protocolo y verás esas URLs separadas en Solo en A y Solo en B.
Detección de similitud: capturar renombres automáticamente
La parte más difícil de una auditoría de migración no son las URLs que desaparecen ni las que se añaden — son las que se renombran. Un cambio de slug de /precios-2024/ a /precios/, una reestructuración de categorías de /blog/categoria/foo/ a /articulos/foo/ o una migración de CMS que cambia /productos/widget/ por /p/widget/ parecen una URL que desaparece y otra que aparece. Sin ayuda explícita, se entierran en las columnas Solo en A y Solo en B y son fáciles de pasar por alto.
Después de calcular el diff normalizado, esta herramienta ejecuta similitud por distancia de Levenshtein sobre las URLs aún no emparejadas de ambos lados. Para cada URL no emparejada en A, busca la coincidencia más cercana en B y las empareja si la similitud supera el umbral (0.85 por defecto — es decir, las dos URLs deben coincidir aproximadamente en el 85% de los caracteres tras la normalización). El resultado es la pestaña Similares: una lista lado a lado de pares probables de renombre con el porcentaje de similitud, lista para exportar y convertir en reglas 301.
La unicidad greedy mantiene limpio el emparejamiento: una vez que una URL en B se empareja con una URL en A, se elimina del pool de candidatos. Esto significa que cada URL de A obtiene como mucho un objetivo B sugerido y viceversa — las sugerencias sirven como borrador de mapa de redirecciones en lugar de matriz ruidosa cualquiera-con-cualquiera. Sube el umbral si ves falsos positivos, bájalo si sospechas que se están perdiendo renombres reales.
Cómo leer el diff: un flujo práctico
La forma más rápida de usar la salida es un paso en cuatro etapas:
- Solo en A → comprobar cobertura de redirecciones. Cada URL aquí existe en el sitemap antiguo pero no en el nuevo. Si hay una entrada correspondiente en la pestaña Similares, planifica un 301 hacia su par en B. Si no, decide: ¿se retiró la página intencionadamente (en cuyo caso, un 410 o un 301 al sustituto temático más cercano) o quedó huérfana por accidente (en cuyo caso arregla la migración antes del lanzamiento)?
- Similares → revisar y aprobar. Cada par sugerido es un borrador de redirección. Mira el score de similitud: por encima de 0.90 suele ser un renombre con confianza alta; 0.85–0.90 merece una comprobación humana rápida; por debajo de 0.85 (si bajaste el umbral) a menudo empareja URLs no relacionadas que comparten una subcadena.
- Solo en B → detectar huérfanos y polución. Las URLs nuevas son esperables, pero vigila las URLs solo de staging que no deberían haber llegado al sitemap de producción, páginas de navegación facetada que deberían ser noindex o duplicados de un constructor de URLs descuidado. El grupo Solo en B también es donde detectas páginas que existen en el sitio nuevo pero no tienen enlace interno desde el contenido antiguo — necesitarán refuerzos editoriales.
- Comunes → revisar deriva de barra final y protocolo. Incluso con normalización, échale un vistazo a la pestaña Comunes para confirmar que las URLs que esperas en ambos lados están realmente ahí. Un grupo Comunes sorprendentemente pequeño suele ser señal de que un sitemap tiene una diferencia cosmética sistemática que tus interruptores de normalización aún no cubren.
Índices de sitemap frente a conjuntos de URLs
El protocolo sitemaps.org permite dos tipos de raíz: <urlset>, que lista URLs reales de páginas, y <sitemapindex>, que lista las URLs de otros sitemaps. Los sitios grandes que superan los límites de 50.000 URLs o 50 MB por sitemap dividen sus sitemaps en varios fragmentos y publican un índice. Si introduces un índice en el comparador, el diff no será sobre URLs reales de página — será sobre las URLs de los sitemaps hijos, que rara vez es lo que quieres.
La herramienta detecta este caso y muestra un aviso en la parte superior del panel afectado. La solución es descargar cada sitemap hijo por separado y procesarlos en pares, o fusionarlos localmente antes de comparar. Versiones futuras podrán expandir índices automáticamente; por ahora el aviso explícito previene el footgun silencioso de comparar entradas de índice en vez de URLs de página.
Dónde encaja el diff en un plan de migración más amplio
Un diff de sitemap es un paso necesario pero no suficiente. Las auditorías de migración más sólidas combinan: (a) un diff de sitemap como esta herramienta para detectar los deltas a nivel de URL; (b) un análisis de logs de servidor para detectar URLs que Google rastrea pero no están en el sitemap (suele ser la cola larga con más equity acumulada); (c) una exportación de Google Search Console de las páginas con mejor rendimiento para confirmar que ninguna URL de top de tráfico está en Solo en A sin redirección; (d) un crawl post-lanzamiento con verificación de códigos de estado para confirmar que cada redirección planificada está realmente cableada en producción. Trata el diff de sitemap como el primer 80% de la auditoría que puedes ejecutar en 30 segundos, y luego añade las técnicas más caras encima para las páginas críticas.
Privacidad: por qué importa el procesamiento local aquí
Los sitemaps incluyen rutinariamente URLs pre-lanzamiento, contenido restringido, entornos de staging, trabajo de cliente bajo NDA y crawls de competencia que preferirías no registrar en un servicio de terceros. El procesamiento del lado del navegador — todo el pipeline se ejecuta en la misma pestaña que cargó la página — significa que el XML que pegas nunca cruza una frontera de red. Puedes verificarlo en el panel Network del DevTools de tu navegador: tras cargar la página, el botón Comparar no genera ninguna petición HTTP. La misma lógica de comparación está disponible como librería open-source si necesitas ejecutarla en un pipeline de CI o un script de Node.js, pero la herramienta web es totalmente autocontenida.