Cómo monitorizar los cambios del sitemap de forma automática

Para monitorizar los cambios del sitemap, guarda una copia de su lista de URLs con una periodicidad fija y compara cada copia con la anterior. Las diferencias que merecen atención son las URLs que aparecen, las URLs que desaparecen y las fechas lastmod que cambian en bloque.

El sitemap es el único archivo en el que un CMS enumera, en texto plano, las páginas que cree que deberían existir. Cuando una migración o un cambio de plugin se lleva por delante una sección, el sitemap lo refleja ese mismo día, mientras que las posiciones pueden tardar semanas en mostrar algo. La mayoría de los equipos lo revisan en el lanzamiento y no lo vuelven a abrir.

Cómo leer los cambios del sitemap

Cada tipo de cambio tiene una explicación inofensiva habitual y un fallo que debes descartar.

Cambio	Suele ser inofensivo porque	Descarta
URLs añadidas	Se han publicado artículos o productos nuevos	Que se estén generando archivos de etiquetas, parámetros de filtro, páginas de adjuntos o URLs de staging
URLs eliminadas	Se ha borrado o fusionado contenido a propósito	Páginas despublicadas por error, puestas en noindex o perdidas en una migración
lastmod cambiado en pocas URLs	Esas páginas se han editado	Normalmente nada
lastmod cambiado en todas las URLs	Rara vez es una edición real	Un deploy o una regeneración de caché que reescribe las fechas

Las URLs eliminadas son las que más atención merecen. Google mantiene una página indexada durante un tiempo después de que salga del sitemap, así que el tráfico no te va a avisar. Las URLs añadidas pesan más en los ecommerce, donde una actualización que activa páginas de atributos o de filtros puede sumar de la noche a la mañana un lote grande de URLs sin contenido.

Los cambios masivos de lastmod son menos urgentes, pero conviene corregirlos. La documentación de Google sobre sitemaps indica que solo usa lastmod cuando el valor es preciso de forma sistemática y verificable, así que un sitemap que pone la fecha de hoy en todo le enseña a Google a ignorar ese campo. Cómo escribir bien el archivo lo explicamos en buenas prácticas de sitemap XML.

Un diff manual que puedes ejecutar hoy

Para un sitemap único y plano:

curl -s https://example.com/sitemap.xml \
  | grep -o '<loc>[^<]*' | cut -c6- | sort > hoy.txt
comm -3 ayer.txt hoy.txt

comm -3 muestra en la primera columna las URLs que solo están en el archivo de ayer y, con sangría, en la segunda las que solo están en el de hoy. Es más fácil de leer que la salida de diff.

La mayoría de los sitios reales sirven un sitemap index. Yoast sirve /sitemap_index.xml, que apunta a post-sitemap.xml, page-sitemap.xml y archivos similares. WordPress sin plugin SEO sirve /wp-sitemap.xml. El /sitemap.xml de Shopify es un índice de sitemaps hijos para productos, colecciones, páginas y blogs. Si ejecutas el comando anterior sobre cualquiera de ellos, obtienes una lista de sitemaps hijos, no de páginas. Un bucle corto lo resuelve:

curl -s https://example.com/sitemap_index.xml \
  | grep -o '<loc>[^<]*' | cut -c6- \
  | xargs -n1 curl -s \
  | grep -o '<loc>[^<]*' | cut -c6- | sort -u > hoy.txt

Dos advertencias. Los sitemaps comprimidos (.xml.gz) necesitan gunzip -c en la cadena, y un <loc> envuelto en CDATA o repartido en varias líneas se le escapa a grep, así que si vas a mantener el script a largo plazo es más seguro usar un parser XML de verdad. Si no sabes dónde está el sitemap de un sitio, la línea Sitemap: de su robots.txt suele indicarlo.

Dónde se queda corto el script

La programación es el primer punto débil. Un cron en un portátil se para cuando cierras la tapa, y un script por cada sitio de cliente es otra cosa más que nadie mantiene.

Search Console no cubre ese hueco. Su informe Sitemaps muestra el estado de cada archivo enviado ("Correcto", "Tiene errores" o "No se ha podido obtener") y un recuento de páginas descubiertas, pero no dice qué URLs han desaparecido ni envía ninguna notificación cuando ese recuento baja. Filtrar el informe Indexación de páginas por sitemap muestra el estado de indexación de las URLs que contiene un archivo, algo útil para el diagnóstico cuando ya sabes que algo va mal.

El último hueco es que una lista de URLs no dice nada de las páginas que hay detrás. /precios/ puede seguir en el sitemap después de que el mismo deploy le haya quitado el title o le haya añadido un noindex.

Monitorizar los cambios del sitemap de forma automática con Deltio

Deltio revisa a diario el sitemap de cada sitio y lo compara con la comprobación anterior. Cuando se añaden o eliminan URLs, envía una alerta por Slack y email para ese sitio con la lista de URLs afectadas, en lugar de un simple recuento. En el mismo ciclo revisa las páginas en busca de cambios de noindex, canonical, title, meta description y H1, así que un cambio en el sitemap y una regresión a nivel de página causados por la misma release llegan juntos. Se complementa con las alertas de cambios SEO y con el trabajo más amplio de monitorizar los cambios en las webs de tus clientes.

Un ciclo diario tiene un punto ciego: un sitemap que se rompe y se recupera en pocas horas puede no aparecer nunca. Para la mayoría de los sitios es un compromiso aceptable, y en un día de lanzamiento puedes ejecutar el script de arriba en paralelo. La prueba gratuita de 14 días te da dos semanas de diffs sobre el sitio de cliente que más te preocupa.