Sitemaps, fechas y señales de frescura para los índices generativos.

La frescura es un criterio de selección, no un extra

Los motores generativos muestran a menudo la fecha de sus fuentes, y sus subconsultas incluyen con frecuencia un año o la mención «reciente». En cualquier pregunta cuya respuesta cambia con el tiempo, un precio, una normativa, una versión, una comparativa, una página fechada hace tres años parte con una desventaja que ninguna calidad redaccional compensa, porque el motor busca precisamente la fuente que refleja el estado actual. A la inversa, en una pregunta de definición o de método, la antigüedad pesa poco, y una página estable y bien corroborada sigue siendo citada durante años.

La frescura no es, por tanto, una quinta condición que se sumaría a las cuatro condiciones de una citación; es un componente de la primera y de la segunda. Una página cuya fecha es ilegible o contradictoria está peor identificada, y un pasaje que afirma una cifra sin fecharla es menos citable. Los motores generativos no han documentado ninguna ponderación de la fecha en su selección; lo que se observa en las respuestas basta, no obstante, para establecer que la leen, la muestran y la prefieren reciente cuando la pregunta lo exige.

De ahí se derivan una regla y una trampa. La regla: la fecha que usted emite debe ser exacta e idéntica en todos los lugares donde aparece. La trampa: refrescar una fecha sin cambiar el contenido. Un motor que relee una página y no encuentra nada nuevo aprende a no creer en sus fechas, y esa pérdida de confianza se extiende a todo el sitio. Google lo dice explícitamente para el lastmod de los sitemaps, que solo utiliza si comprueba con regularidad que es exacto; no hay ninguna razón para suponer que los demás índices sean más indulgentes.

El sitemap XML: lo que los motores leen realmente

El protocolo sitemaps.org define cuatro elementos por URL: loc, lastmod, changefreq y priority. Solo cuentan los dos primeros. Google documenta que ignora changefreq y priority, y que utiliza lastmod a condición de que sea constante y verificablemente exacto; Bing también se apoya en lastmod para decidir qué volver a rastrear. Un archivo no debe superar las cincuenta mil URL ni los cincuenta megabytes sin comprimir; más allá de ese límite, un índice de sitemaps reparte las entradas en varios archivos.

Para los motores generativos, el sitemap cuenta de dos maneras. Directamente para AI Overviews, AI Mode y Copilot, que se basan en los índices de Google y de Bing. Indirectamente para los demás: OpenAI, Anthropic y Perplexity no han documentado cómo sus robots de indexación descubren las URL, pero nada indica que hayan inventado un mecanismo distinto de los enlaces y los sitemaps, y nuestros logs muestran a estos robots leyendo páginas recientes poco después de su incorporación al sitemap. El archivo siguiente ilustra una entrada correcta: URL canónica con código 200, fecha al segundo, zona horaria explícita.

<!-- Una entrada por URL canónica; lastmod = última modificación real del contenido principal -->
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.exemple.fr/guides/tva-batiment</loc>
    <lastmod>2026-05-11T09:20:00+02:00</lastmod>
  </url>
  <url>
    <loc>https://www.exemple.fr/guides/fiscal-2026</loc>
    <lastmod>2026-01-15T08:00:00+01:00</lastmod>
  </url>
</urlset>

Un lastmod sincero: la regla que rige todo lo demás

Un lastmod es sincero cuando corresponde a la última modificación del contenido principal de la página, tal como la percibiría un lector. No corresponde ni a la fecha de generación del sitemap, ni a la del último despliegue del sitio, ni a la de un cambio de plantilla, de menú o de bloque lateral. Esta definición tan simple la incumple la mayoría de los sitios que auditamos, casi siempre sin intención: es el sistema de gestión de contenidos el que, en cada publicación, reescribe la fecha de todas las páginas.

Los errores son de un número limitado, y cada uno se detecta en pocos minutos comparando dos versiones del sitemap tomadas con una semana de diferencia.

• Todas las URL llevan la misma fecha, la de la última generación del archivo: la señal es nula, y Google deja de fiarse de ella.
• La fecha cambia en cada despliegue, aunque el contenido sea idéntico: mismo efecto, más difícil de detectar.
• Un comentario, una reseña de cliente o un bloque de «artículos relacionados» actualiza la fecha de la página que lo aloja.
• La zona horaria se omite o es errónea, y la fecha aparece en el futuro para un robot que trabaja en UTC.
• El sitemap lista URL redirigidas o con error, con fechas recientes que invitan al robot a releerlas.

La corrección consiste en distinguir, en el sistema de gestión de contenidos, la fecha de modificación del contenido principal de los demás eventos, y emitir únicamente la primera. Cuando el sistema no lo permite, funciona una regla sencilla: actualizar el lastmod solo con motivo de una intervención editorial explícita y registrada, y dejar todas las demás fechas sin cambios. Una fecha antigua pero verdadera vale más que una fecha reciente que el robot aprende a ignorar.

Las fechas visibles, y su coherencia entre cuatro ubicaciones

Un motor generativo lee la fecha en cuatro lugares, y no los jerarquiza como usted. El primero es el texto visible de la página, el que un modelo de lenguaje procesa como cualquier otro pasaje: una línea «Actualizado el 11 de mayo de 2026» bajo el título es la fecha que citará. El segundo es el marcado Article o BlogPosting, con datePublished y dateModified. El tercero es el lastmod del sitemap. El cuarto es la cabecera HTTP Last-Modified, que el robot recibe incluso antes de leer la página. Google recomienda mostrar una fecha clara, utilizar los datos estructurados y evitar cualquier contradicción entre ambos; el artículo sobre las fechas de publicación y de actualización detalla estas recomendaciones y las incoherencias que desacreditan una página.

Las contradicciones más frecuentes se deben a la plantilla: una fecha visible introducida por el redactor, un dateModified calculado por el sistema en cada guardado, un lastmod generado por una extensión de terceros, un Last-Modified que refleja la hora de almacenamiento en caché. Cuatro orígenes, cuatro fechas, y un motor que no retiene ninguna. La solución técnica no es complicada: una única fuente de verdad en el sistema de gestión de contenidos, y las cuatro ubicaciones alimentadas desde ella.

Flujos de actualización: sitemap, feed RSS, IndexNow

Emitir una fecha exacta no basta; además, los índices tienen que enterarse de que una página ha cambiado sin esperar a su próxima visita. Existen tres canales, y no los leen los mismos motores. El sitemap y los feeds RSS o Atom están documentados por Google, que acepta estos últimos como sitemaps de pleno derecho, y por Bing. IndexNow, una iniciativa lanzada por Microsoft y adoptada por varios motores, permite notificar una URL modificada con una simple petición; Google no participa en ella, que sepamos, y además abandonó en 2023 su antiguo punto de conexión de «ping» de sitemap. En cuanto a los robots de indexación de los motores generativos, ningún editor ha documentado un canal de notificación.

Tabla: desplácese horizontalmente.

Un flujo de actualización solo tiene valor si es selectivo. Un feed que anuncia cien modificaciones al día porque el sistema regenera todas las páginas se ignora tan rápido como un sitemap con fechas uniformes. La disciplina es la misma que en el capítulo anterior: una notificación por modificación real, y nada más.

Qué contenidos refrescar en primer lugar

No todo merece ser refrescado, y refrescar sin motivo cuesta caro en credibilidad. La prioridad se lee cruzando dos ejes: el peso de la página en su cuota de citación, medida sobre su panel de preguntas, y la sensibilidad de su tema al paso del tiempo. Las páginas citadas en preguntas con componente temporal, y cuya fecha mostrada supera los doce meses, van en cabeza. Después vienen las páginas cuya citación ha retrocedido en favor de una fuente competidora más reciente, algo que el panel revela en pocas semanas.

Las categorías de contenido que requieren una revisión regular son siempre las mismas: tarifas, páginas normativas y fiscales, comparativas y páginas de «el mejor X», fichas de compatibilidad o de versiones, cifras de mercado, calendarios. Para cada una, la actualización debe afectar al propio pasaje citable, la cifra, la condición, la fecha de referencia, y no a un párrafo de introducción. El artículo dedicado a la actualización de un contenido antiguo describe el protocolo página por página; el calendario siguiente marca el ritmo.

Lo que la frescura no sustituye

Una página reciente pero vaga no se cita más que una página antigua y vaga. La fecha abre la puerta en las preguntas donde cuenta; no exime ni de un pasaje que responda en cuarenta a ochenta palabras, ni de una entidad identificada, ni de una corroboración externa. Vemos con regularidad sitios que fechan escrupulosamente páginas que nadie cita, y otros, rara vez actualizados, que dominan su tema porque son precisos y se recogen en otros lugares.

El punto de atención definitivo se refiere a la velocidad de propagación. Entre una modificación y su incorporación a una respuesta generativa transcurre el tiempo de un nuevo rastreo, y después el de una actualización del índice, y ningún editor documenta ese plazo. Se mide en su propio sitio, cotejando la fecha de modificación con la siguiente visita del robot en los logs, como explica el artículo sobre la velocidad y el presupuesto de rastreo de los robots de IA. Un sitio que responde rápido, con URL limpias y fechas fiables, se relee antes; ahí es donde la frescura se gana de verdad.

Qué recordar