lastmod — lastmod — fecha de última modificación en sitemap.xml

¿Qué es la etiqueta <lastmod>?

<lastmod> es la etiqueta del sitemap.xml que comunica a los buscadores la fecha y hora de la última modificación de cada URL. Forma parte del protocolo sitemaps.org desde 2006 y es una de las pocas etiquetas opcionales que Google sí utiliza activamente desde el cambio de política anunciado en su blog oficial de junio de 2023.

Formato obligatorio: ISO 8601

<url>
  <loc>https://smedialab.es/servicios/seo/</loc>
  <lastmod>2026-04-15T14:22:00+00:00</lastmod>
</url>

Aceptado:

• Solo fecha: 2026-04-15 (UTC implícito).
• Fecha + hora + zona: 2026-04-15T14:22:00+00:00 (preferido).
• Fecha + hora + Z: 2026-04-15T14:22:00Z (UTC).

NO aceptado: formatos americanos (04/15/2026), epoch Unix, RFC 2822 (Date HTTP).

Por qué Google la ignora si no es precisa

Si un sitemap tiene 193 URLs y las 193 declaran la misma fecha (típicamente la fecha del último deploy del sitio), Google detecta que el dato no aporta información real sobre qué página ha cambiado y deja de usarlo como señal de frescura. Es el patrón anti-señal más común en sitios estáticos generados por SSG (Astro, Hugo, Next.js sin SSR).

Google ha sido explícito al respecto:

If your <lastmod> is consistently inaccurate or matches the build time of the entire site, we will eventually start ignoring it. — Google Search Central Blog, junio 2023.

Solución: lastmod por archivo desde git

La forma correcta de generar <lastmod> es leer la fecha del último commit que modificó cada archivo fuente:

git log -1 --format=%aI -- src/content/servicios/seo.md
# → 2026-04-15T14:22:00+02:00

Esto funciona porque:

• Cada landing de servicio, ubicación o tecnología es un archivo Markdown distinto.
• El historial de Git tiene la fecha exacta del último cambio relevante.
• El comando es rápido (git log -1 lee solo la cabecera del archivo de log).

En sitios SSG, el sitemap se genera en build time. Hay que invocar git log por cada URL del sitemap. Para 200 URLs el overhead es despreciable (< 2 s en build).

Otras consideraciones

• <lastmod> no fuerza re-crawl: solo señala. Si Google considera que la página no merece más frecuencia, ignora el cambio.
• Cambios cosméticos (corregir un typo) cuentan como modificación real. Cambios en menú/footer/header NO deben contarse como modificación de cada landing (el archivo de la landing no cambió, solo cambia el HTML renderizado).
• Coherencia con <meta name="last-modified"> o cabecera HTTP Last-Modified: idealmente las tres fechas coinciden.

Cómo lo aplicamos en smedialab.es

src/pages/sitemap.xml.ts calcula <lastmod> por URL ejecutando git log -1 --format=%aI -- <ruta_archivo> por cada landing. Esto significa que las 193 URLs del sitio reflejan 7 fechas distintas correspondientes al cambio real de cada archivo fuente, no la fecha global del último build.

Es un patrón validado en logopedajessica.es y replicado aquí en abril de 2026. Para nuestros clientes de SEO implementamos el mismo patrón siempre que el stack lo permite.