Sitemap XML: un lastmod idéntico en todas las URL vuelve inútil el sitemap

Un sitemap XML dice a los motores qué URL existen y cuáles han cambiado. La primera función la cumplen casi todos los CMS. La segunda la fallan buena parte de ellos, y de forma invisible: el fichero es válido, Search Console lo lee sin error, y sin embargo ya no aporta ninguna información sobre lo que se ha movido. La causa está en un solo campo, lastmod, y en la manera de rellenarlo.

Lo que Google hace realmente con lastmod

La posición de Google está escrita negro sobre blanco en su documentación sobre la construcción de un sitemap: el valor de lastmod se utiliza «si es coherente y verificable», por ejemplo comparándolo con la última modificación real de la página. Google añade que los campos priority y changefreq se ignoran. De los tres campos opcionales del formato, solo uno cuenta, y solo si dice la verdad.

Desde el punto de vista del motor, el cálculo es el siguiente. Un robot dispone de un presupuesto de rastreo limitado por sitio. Cuando relee un sitemap, compara las fechas anunciadas con las que ha memorizado. Una URL cuya fecha ha avanzado merece una nueva visita; una URL cuya fecha no se ha movido puede esperar. Si todas las fechas avanzan a la vez en cada lectura, el motor ya no puede distinguir una página realmente actualizada de una página intacta. Acaba por no fiarse del campo y vuelve a sus propias heurísticas, por lo general más lentas.

El defecto típico: la fecha del build

Muchos generadores de sitios estáticos, y un buen número de CMS, escriben en lastmod la fecha en que se regeneró el sitio. En un sitio publicado a diario, todas las URL llevan entonces la fecha del día, incluidos artículos de hace tres años que nadie ha tocado. El sitemap anuncia de forma permanente que todo ha cambiado.

Comprobamos este defecto en varios sitios en producción durante el verano de 2026, sobre más de trescientas URL en total: en todos los casos, un único valor de lastmod para el conjunto del sitemap, igual a la hora del último build. Ninguno de esos sitios enviaba además una cabecera HTTP Last-Modified ni un ETag en sus páginas, y ninguno respondía a las peticiones condicionales de los robots. El motor no tenía, pues, forma alguna de saber qué recargar.

Diagnóstico en tres comprobaciones

La comprobación lleva unos minutos, con un simple terminal.

1. Contar los valores distintos de lastmod. Recuperar el sitemap, extraer las etiquetas lastmod y contar los valores únicos. Un sitemap sano en un sitio de varios cientos de páginas tiene decenas. Un solo valor, o un puñado fechados todos el mismo día, delata el defecto.
2. Comparar lastmod con la página. Tomar una URL antigua del sitemap, abrir la página y comparar la fecha de modificación que aparece en el artículo, o en sus datos estructurados, con el valor de lastmod. Una diferencia de varios meses confirma que lastmod no describe la página.
3. Probar las cabeceras HTTP. Pedir una página con una petición HEAD y mirar si el servidor devuelve Last-Modified o ETag. Después repetir la misma petición con If-Modified-Since en la fecha recibida. Un servidor que responde 304 Not Modified sabe decir que una página no ha cambiado; un servidor que devuelve 200 cada vez obliga al robot a descargarlo todo de nuevo.

Estas tres pruebas no requieren ninguna herramienta de pago. Forman parte de las comprobaciones que recomendamos antes de cualquier discusión sobre la indexación de un medio.

Por qué es más grave para un medio que para un sitio corporativo

Un sitio corporativo de veinte páginas se vuelve a rastrear entero pase lo que pase. Un medio que publica varios artículos por semana y corrige otros vive de una señal de frescura fiable: es ella la que hace subir un artículo actualizado, y la que evita al robot gastar su presupuesto en páginas congeladas. Cuando la señal se rompe, aparecen dos síntomas al cabo de unas semanas:

• Los artículos nuevos tardan más en indexarse, porque quedan ahogados en un sitemap donde todo parece nuevo.
• Las correcciones de artículos antiguos no se tienen en cuenta, porque nada distingue una página corregida de una página que un build ha regenerado sin más.

En un medio que apunta además a los motores generativos, el problema se paga una segunda vez: los robots de las IA de búsqueda, que se apoyan en los mismos sitemaps, lo heredan. Un contenido revisado para corregir una cifra se sigue sirviendo en su versión antigua durante semanas.

El criterio de corrección

Corregir el defecto es hacer que lastmod lleve la fecha de la última modificación editorial de cada página, y nada más. En concreto:

El criterio de aceptación es el mismo que el del diagnóstico: tras la corrección, el número de valores distintos de lastmod debe reflejar la historia real del medio, y dos builds sucesivos sin modificación editorial deben producir dos sitemaps idénticos. Si el sitemap cambia cuando no se ha escrito nada, la corrección no está hecha.

El caso particular del medio en subdirectorio

Cuando un medio está alojado bajo una ruta del sitio principal, por ejemplo un blog servido en /blog/ desde otra plataforma, se añade una segunda dificultad: el fichero robots.txt que declara el sitemap solo se lee en la raíz del host. Un robots.txt colocado en el subdirectorio nunca se consulta, y las líneas Sitemap que contiene no existen para los motores, como recuerda la documentación de Google sobre robots.txt. Hay que declarar entonces el sitemap del medio en el robots.txt del sitio principal, o enviarlo directamente en Search Console. Google retiró en 2023 la posibilidad de «hacer ping» a un sitemap mediante una simple petición HTTP: sin declaración explícita, un medio en subruta no tiene ningún canal de descubrimiento.

Estos dos defectos, lastmod uniforme y sitemap no descubierto, se corrigen de una vez por todas en la herramienta de publicación. Es el tipo de detalle que un CMS pensado para un medio debe resolver por construcción, porque ningún equipo editorial lo va a comprobar a mano en cada publicación. Sobre las demás señales de frescura, la fecha de revisión mostrada y los datos estructurados, remitimos a nuestro artículo «Frescura: fechar los contenidos, revisarlos y demostrarlo a los motores».