Frescura: fechar, revisar, demostrar. Lo que los motores y las IA esperan de un contenido al día

Un lector que hace una pregunta a un asistente en 2026 quiere una respuesta válida en 2026. Los motores, tanto los clásicos como los generativos, lo saben y tienen en cuenta la fecha de un contenido, sobre todo en los temas donde los hechos cambian: normativa, precios, versiones, cifras de mercado. Muchos editores han sacado de ahí una mala costumbre, la de cambiar la fecha de un artículo sin cambiar una sola línea. Es una práctica detectable y contraproducente. Esto es lo que los motores leen realmente, cómo lo comprueban y cómo organiza sus actualizaciones un medio que publica mucho.

Lo que Google lee, y dónde

Google documenta, en su página sobre los datos estructurados Article, dos propiedades procedentes de schema.org: datePublished y dateModified. La segunda debe indicar la fecha de la última modificación sustancial del contenido, y Google pide, en sus directrices sobre las fechas, que se corresponda con la fecha visible en la página. El sitemap transporta una tercera señal, lastmod, que Google usa para decidir qué recarga de forma prioritaria, siempre que sea fiable, como explica la página sobre la construcción de un sitemap.

El punto importante es la coherencia. Google compara lo que dicen los datos estructurados, la fecha mostrada, el lastmod del sitemap y, si existen, las cabeceras HTTP de última modificación. Cuando esas fuentes se contradicen, deja de confiar en ellas y se repliega sobre su propia observación: ¿ha visto cambiar el contenido entre dos pasadas? Un sitio cuyo sitemap anuncia cada día una modificación de todas las páginas, sin que ninguna cambie, le enseña a Google que su lastmod no significa nada. Documentamos este caso en «Un sitemap con fechas idénticas no sirve de nada».

Lo que los motores generativos hacen con las fechas

Un motor generativo que responde con fuentes busca pasajes pertinentes y luego los pondera. En una pregunta cuya respuesta depende del tiempo, favorece los pasajes fechados recientemente, y lee la fecha allí donde esté disponible: en los datos estructurados, en el texto, a veces en la URL. Google indica en su página sobre las funciones de IA en la búsqueda que sus respuestas generadas se apoyan en las mismas señales que la búsqueda clásica, sin marcado particular; la frescura es una de ellas.

Hay una consecuencia que los editores subestiman: un motor generativo puede citar el pasaje que contiene su propia fecha. «Desde el 2 de agosto de 2026, el artículo 50 se aplica» es un pasaje fechable y citable. «Recientemente, la normativa ha cambiado» no lo es, y envejece mal. Escribir las fechas en el texto, con todas sus letras, es una práctica de frescura tanto como de citabilidad, en la línea que describíamos en «Primero la respuesta, después el matiz».

Por qué la señal falsa cuesta más de lo que aporta

Volver a fechar un artículo sin modificarlo produce tres efectos, todos negativos.

1. La pérdida de confianza en las señales. El motor observa que la fecha cambia y que el contenido no. El riesgo es que aprenda que las fechas de ese sitio son ruido y deje de tenerlas en cuenta, incluso para las actualizaciones reales. Ningún motor documenta ese comportamiento: es una deducción, no una medición. Por lo demás, los dos efectos se suceden en el tiempo en vez de coexistir. El motor recarga primero fiándose de las fechas anunciadas, y es la constatación repetida de un contenido inalterado la que luego lo lleva a desconfiar de ellas.
2. El derroche del presupuesto de rastreo. Cada página anunciada como modificada se recarga. En un medio de quinientos artículos, anunciar cada día quinientas modificaciones ficticias es pedir quinientas recargas para nada, en detrimento de las páginas realmente nuevas.
3. El riesgo de contradicción. Un artículo «actualizado en septiembre de 2026» que cita una tarifa de 2024 o una versión de software abandonada queda desacreditado al instante ante un lector atento, y un motor generativo muestra de buen grado la fecha que encuentra en el pasaje que cita.

La documentación de los evaluadores de calidad de Google dedica varias páginas a la noción de contenido al día, y distingue de forma explícita los temas donde la fecha cuenta de aquellos donde no cuenta. Una guía sobre la colocación de una cubierta no necesita reescribirse cada mes; una página sobre las ayudas a la rehabilitación, sí.

A qué se parece una revisión de verdad

Una revisión que justifica una nueva fecha de modificación cambia algo que un lector podría notar: una cifra sustituida por una más reciente, una sección añadida sobre un hecho nuevo, una recomendación retirada porque ya no se sostiene, una fuente sustituida por otra actualizada. Corregir una errata, cambiar una imagen o reformular un título no es una revisión, y no debe modificar dateModified.

La regla es fácil de mantener con diez artículos e imposible de mantener de memoria con quinientos. Ahí es donde cuenta la organización.

Organizar la revisión a escala

Un medio que publica varios contenidos por semana acumula en un año unos centenares de artículos, parte de los cuales contiene hechos perecederos. Su revisión sigue siendo viable sin movilizar a un equipo a tiempo completo, a condición de dotarla de herramientas.

La base de referencia. Si los hechos, las cifras y las posiciones vienen de una base común en lugar de cada artículo, actualizar un hecho en la base permite localizar todos los artículos que lo usan. Cambia una tarifa: se sabe qué artículos la citan. Se aplaza un plazo normativo: se sabe qué artículos lo anunciaban. Sin base de referencia, esa búsqueda se hace a mano, y no se hace.

El marcado de los hechos perecederos. En la redacción, cada afirmación fechada o cifrada se identifica como tal, con su fuente y su fecha de validez presunta. Una revisión mensual lista las afirmaciones cuya validez ha vencido, y el editor decide, para cada una, verificarla, corregirla o retirarla. Es un trabajo de unas horas al mes, y recae sobre los pasajes que los motores más releen.

La medición. Los logs dicen qué páginas releen los robots tras una modificación, y Search Console dice cuáles pierden impresiones. Una página que se descuelga en una consulta cuya respuesta ha cambiado es candidata a revisión antes incluso de que la base de referencia la señale. Hemos descrito esa lectura en «Leer un access log en 30 minutos».

Señalar la modificación, sin abusar

Una vez hecha la revisión, queda darla a conocer. Tres canales, que se usan juntos y solo para las revisiones de verdad: la actualización de dateModified en los datos estructurados y de la fecha visible en la página; la actualización del lastmod de esa URL, y solo de esa, en el sitemap; y, en los motores que lo admiten, un aviso directo mediante IndexNow, que informa a Bing y a los motores asociados de que una URL ha cambiado, sin esperar a su próxima pasada.

El servidor añade una última señal, a menudo olvidada: las cabeceras Last-Modified y ETag, y el respeto de las peticiones condicionales. Un robot que pregunta «¿ha cambiado esta página desde mi última visita?» y recibe una respuesta honesta, sí o no, deja de recargar a ciegas y concentra sus pasadas en lo que realmente se mueve.

La frescura es un activo, no un ajuste

Un medio cuyas fechas son fiables es un medio que los motores releen cuando lo pide, y al que citan con la fecha correcta. Un medio que lo vuelve a fechar todo no gana nada a corto plazo y pierde, a medio plazo, lo único que cuenta: la confianza de los motores en sus señales. La diferencia entre ambos se juega en la organización: una base de referencia común, una revisión periódica de los hechos perecederos, una medición de lo que los robots releen. Es una de las razones por las que pensamos que un medio corporativo se construye sobre una base de referencia antes que sobre artículos.