Blog · 2026-08-30

Si tu lastmod miente todos los días, Google deja de escucharte: la máquina de estados con hash de contenido

Cada reconstrucción de un sitio estático sobreescribe el lastmod con la hora de compilación, lo que equivale a mentirle a Google a diario. La solución es hashear el contenido después de quitarle el ruido y montar una máquina de estados, para que la fecha solo se mueva cuando el contenido cambió de verdad.

Abres tu sitemap.xml y los cientos de URLs tienen exactamente el mismo lastmod, todos del mismo minuto de esta madrugada, porque acaba de correr el despliegue programado. El contenido no cambió ni una palabra; lo único que cambió fue la hora de compilación. Ese sitemap le grita a Google todos los días "el sitio entero se actualizó", y después de tanto gritar, la página que sí actualizaste tampoco despierta interés. Esto no es un caso raro: es el comportamiento por defecto de la mayoría de los generadores de sitios estáticos.

El síntoma: todo el sitio con la misma marca de tiempo en lastmod

El diagnóstico se hace de un vistazo: abre el sitemap y, si cada <lastmod> tiene la misma hora y esa hora coincide justo con el último despliegue, es casi seguro que tu generador está usando la hora actual como fecha de modificación, ya sea metiendo date.today() en dateModified o dejando que el script de compilación sobreescriba el lastmod con el momento del build. Otra prueba indirecta está en Search Console: el sitemap aparece como leído y sin embargo las páginas que sí modificaste tardan una eternidad en volver a rastrearse.

Esto es peor en sitios con reconstrucción programada. Nosotros mantenemos un sitio de contenido deportivo de 402 páginas que se reconstruye 4 veces al día (las tablas de posiciones y los calendarios cambian a diario, así que reconstruir es necesario). Si usáramos la hora de compilación como lastmod, estaríamos declarando cada día que cada página "se actualizó 4 veces", cuando el cuerpo de la mayoría no movió ni un byte. Y todavía peor: la misma mentira normalmente se dice dos veces, una en el sitemap y otra en el dateModified de los datos estructurados de la página.

La postura de Google: un lastmod impreciso se trata como si no existiera

La documentación oficial de sitemaps de Google lo dice sin rodeos: el lastmod se toma en cuenta solo si es "consistente y verificablemente preciso" (consistently and verifiably accurate), y una de las formas de verificarlo es contrastarlo con la modificación real de la página. El mismo documento define qué cuenta como una actualización digna de marcarse: cambios en el contenido principal, en los datos estructurados o en los enlaces de la página. Cambiar el año del aviso de copyright no cuenta.

El lastmod sirve para que el rastreador priorice, o sea para decirle "ven a rastrear estas páginas primero y olvídate del resto". Si todo el sitio grita actualización todos los días, esa señal vale cero: Google no tiene forma de distinguir qué página cambió de verdad, y tú mismo tiraste a la basura la pista de rastreo más valiosa que tenías. Para un sitio que se reconstruye varias veces al día y quiere que sus actualizaciones se indexen rápido, eso es dispararse al pie.

La solución: una máquina de estados con hash de contenido, donde la fecha sigue al contenido

El principio cabe en una frase: el lastmod no debe venir de "cuándo se compiló" sino de "cuándo cambió el contenido". El método es mantener para cada página un archivo de estado que sobreviva entre compilaciones:

{ "/match/group-a/": {
    "hash": "3f2a…",
    "publishedAt": "2026-06-10",
    "updatedAt": "2026-08-12" } }

En cada compilación, cada página pasa por el mismo flujo:

1. Generado el HTML, se extrae el cuerpo, se normaliza y se calcula el SHA256.
2. La página no está en el archivo de estado, o sea que es nueva: publishedAt y updatedAt se escriben con la fecha de hoy.
3. El hash coincide con el anterior: no se toca nada y se conservan las fechas viejas.
4. El hash es distinto: updatedAt pasa a la fecha de hoy y se escribe de vuelta en el archivo de estado.

El lastmod del sitemap, el dateModified de los datos estructurados y la "última actualización" que se muestra en la página se leen todos del archivo de estado, así que las tres cosas comparten una sola fuente de verdad. El archivo de estado viaja con el repositorio o con el artefacto de despliegue, de modo que ninguna reconstrucción lo hace perder la memoria. El momento de escribirlo también hay que pensarlo: se guarda a disco solo cuando el despliegue se confirma exitoso, porque una compilación fallida no puede contaminar el estado. Si no, un build reventado se arrastra las fechas de todo el sitio.

Limpia antes de hashear: los scripts y el código de seguimiento no son contenido

Donde más muere este mecanismo es en calcular el hash de forma demasiado burda. Si hasheas el HTML completo, vas a descubrir que en cada compilación "cambió" todo el sitio: una nueva versión del fragmento de seguimiento, la huella de caché en el nombre del archivo de recursos (app.a1b2c3.js), un nonce aleatorio, el año que el pie de página agrega solo. Basta que una de esas cosas se mueva para que el hash de todo el sitio se renueve y la máquina de estados quede inservible. Por la misma razón, bloques como "artículos relacionados", que se eligen al azar en cada compilación, también tienen que quedar fuera del alcance del hash.

Así que antes de hashear hay que limpiar. Con un parser de HTML de verdad (no con expresiones regulares) se quitan enteros los <script>, los <style> y los comentarios, se eliminan los parámetros de seguimiento y las huellas de versión, se deja solo el texto y la estructura del área de contenido principal, se normalizan los espacios y recién ahí se calcula. Lo que acabas de quitar es exactamente lo que la definición de Google considera que "no es una actualización significativa": el límite del hash se traza siguiendo el límite de lo que la documentación llama significativo.

Fecha de publicación y fecha de actualización son dos campos, no los mezcles

El otro error común es tener un solo campo de fecha en todo el sitio. La fecha de publicación (publishedAt) se escribe una vez y no se vuelve a tocar; la fecha de actualización (updatedAt) solo se mueve cuando el hash cambió. La regla de salida cabe en una línea:

lastmod = updatedAt ?? publishedAt

En una página que nunca se modificó, el lastmod se queda honestamente en la fecha de publicación, y eso no es vergonzoso. En una página que sí se modificó, el lastmod apunta con precisión a ese día, y ahí está el valor.

La validación exige pruebas negativas, y hay que pasar las dos: correr la compilación dos veces seguidas, donde la segunda tiene que dar cero páginas modificadas; y después cambiar un párrafo de una página, donde solo esa página puede mover su lastmod. Si falla cualquiera de las dos, el ruido no está bien limpiado y tu sitemap sigue mintiendo.

Cierre

El lastmod es la línea de crédito que tienes con el rastreador, y ese crédito se acumula justamente por no moverlo sin motivo. Al atar la fecha al hash del contenido, la mentira desaparece del proceso: no depende de tu disciplina, depende del mecanismo. Si tu sitio también tiene cientos de páginas y se reconstruye a diario por calendario, pero su sitemap nunca logró que Google lo mirara en serio, esta máquina de estados es la que corre en nuestros propios sitios de contenido y con gusto la platicamos.

Este tipo de detalle lo convertimos en servicio

La honestidad del lastmod es uno de esos indicadores que nadie revisa, pero que en cuanto se revisa deja claro si el trabajo se hizo en serio. El sitemap de nuestros propios sitios se genera con una máquina de estados basada en hash de contenido: la fecha se mueve solo si hubo cambios.

• Arquitectura del sitio y SEO técnico: sitemap, canonical, robots y datos estructurados alineados de una vez
• Monitoreo de indexación: estado de indexación página por página, con envío a los cinco endpoints de IndexNow
• Producción de contenido: el lastmod solo tiene sentido si de verdad hubo una actualización

Las especificaciones están en Servicio de construcción SEO para iGaming.