Una nota puede tener una fecha visible, otra en los datos estructurados y una tercera en el sitemap de noticias. Cuando esas señales no cuentan la misma historia, el problema empieza antes del buscador: el lector tampoco tiene claro cuándo se publicó la información y qué se actualizó después.
En un medio, revisar las fechas no debería limitarse a comprobar que aparezca «hoy» cerca del título. La tarea útil es definir qué representa cada campo, de dónde sale y qué acción del editor lo modifica. Esta guía propone una auditoría de ese circuito, sin cambiar fechas para simular novedad.
Google estima la fecha; no toma una única señal como verdad absoluta
La documentación sobre fechas en los resultados explica que Google combina distintas señales para estimar cuándo se publicó o se actualizó de manera significativa una página. Recomienda mostrar una fecha destacada, identificarla con claridad y mantenerla consistente con los datos estructurados equivalentes.
También indica que la fecha debe describir la página, no el evento sobre el que informa. Una nota publicada el lunes sobre una conferencia del viernes no debería presentar el viernes como su fecha de publicación. Y proporcionar una fecha correcta no garantiza que Google la muestre en el resultado.
La primera pregunta de auditoría, entonces, es sencilla: ¿la plantilla permite distinguir «publicado» de «actualizado» sin tener que interpretar el código? Si hay dos fechas, la etiqueta de cada una tiene que resolver esa diferencia para una persona.
Qué representan datePublished y dateModified
En el marcado Article de Google, datePublished corresponde al momento en que el artículo se publicó por primera vez y dateModified al de su modificación más reciente. Google recomienda incluir la zona horaria en el formato ISO 8601. Son propiedades recomendadas; la herramienta de resultados enriquecidos no necesariamente mostrará una advertencia si faltan.
Eso vuelve insuficiente una validación que sólo busque errores rojos. Un marcado puede superar una revisión de sintaxis y, aun así, tener un dato que no representa el contenido. Nuestra recomendación es contrastar el valor con el historial editorial y con lo que efectivamente ve el lector.
Como criterio de implementación, documentá qué componente genera cada campo: el CMS, el tema o un complemento. Si dos componentes publican bloques distintos, pedile a desarrollo que revise el resultado final. No empieces desactivando herramientas sin identificar cuál está produciendo la discrepancia.
Actualizar información no es refrescar una fecha
Google ya advertía en su explicación sobre fechas de artículos que una modificación sustancial puede justificar una fecha de actualización, pero que no corresponde rejuvenecer artificialmente una historia sin aportar información significativa. Tampoco recomienda crear una versión apenas retocada, borrar la anterior y redirigirla a la nueva.
Para llevar esa distinción a la redacción, proponemos una regla operativa: antes de destacar una actualización, el editor debería poder explicar qué cambió y por qué le importa al lector. Agregar una resolución oficial, incorporar una respuesta pendiente o corregir una conclusión exige un tratamiento diferente de retocar una coma.
No es una fórmula universal para decidir todos los casos. Es una manera de volver explícito el criterio del medio. Cuando la actualización cambia la interpretación de una noticia, una breve explicación visible puede ser más útil para el lector que una hora nueva sin contexto.
El sitemap de noticias tiene su propio campo de publicación
La guía de sitemaps de Google News establece que news:publication_date debe reflejar la fecha original de publicación en el sitio, no el momento en que la URL se agregó al archivo. Indica además que el sitemap de noticias incluya artículos creados en los últimos dos días.
Cuando un artículo supera esa antigüedad, se puede retirar su URL de ese sitemap o eliminar sus metadatos de noticias. Eso no significa borrar la nota del sitio. Conviene dejar clara esta diferencia en cualquier pedido a desarrollo: mantener el archivo de noticias es una operación distinta de eliminar contenido publicado.
Una auditoría que se pueda terminar
En lugar de revisar todo el archivo de una vez, empezá por una muestra que cubra los circuitos que usa tu equipo. El siguiente procedimiento es nuestra propuesta de trabajo:
- Elegí casos diferentes. Incluí una nota recién publicada, una actualización relevante, una corrección menor y una pieza antigua que siga recibiendo lectores. Agregá una nota programada para observar qué ocurre cuando finalmente se publica.
- Armá una fila por URL. Guardá la fecha visible de publicación, la de actualización si existe, los valores estructurados y el campo del sitemap de noticias cuando corresponda. Registrá también cuándo hiciste la comprobación.
- Compará instantes, no sólo números. Si un sistema muestra hora local y otro utiliza UTC, verificá la conversión antes de reportar un error. Dos textos distintos pueden representar el mismo momento.
- Reproducí una edición controlada. En un entorno de pruebas, observá qué cambia al guardar una corrección y qué cambia al publicar una actualización. No uses artículos reales como campo de experimentación sin un procedimiento editorial acordado.
- Asigná responsable y resultado esperado. Un reporte como «las fechas están mal» es difícil de resolver. Indicá qué campo difiere, qué componente lo genera y qué valor debería representar.
Si el problema aparece después de una migración o un cambio de plantilla, conservá ejemplos anteriores y posteriores. Esa evidencia ayuda a delimitar el alcance sin suponer que todos los artículos están afectados.
Qué debería quedar resuelto
Al terminar, el medio debería tener una definición compartida de publicación y actualización, un responsable de los campos técnicos y una lista pequeña de casos que pueda volver a comprobar. No hace falta convertirlo en un proyecto interminable: hace falta que el circuito sea comprensible y verificable.
La fecha es parte de la información que el medio le ofrece a su audiencia. Ordenarla sirve para que una nota antigua no parezca nueva por accidente, una actualización real sea reconocible y el equipo pueda explicar qué ocurrió sin depender de la memoria de quien la editó.
