SEO
lastmod corretto nelle sitemap: data vera o niente
lastmod è la data dell'ultima modifica sostanziale di un URL. Google la usa solo se è coerente e verificabile: una data di deploy su tutto il file insegna a ignorarla.
In sintesi
- lastmod è la data dell'ultima modifica sostanziale di un URL, non la data dell'ultimo deploy.
- Google usa lastmod solo se è coerente e verificabile confrontandola con la pagina.
- Google ignora priority e changefreq: nel file restano solo loc, lastmod e le annotazioni hreflang.
lastmod è la data dell'ultima modifica sostanziale di un URL dentro la sitemap, e vale solo se è vera. Google la usa quando è coerente e verificabile; una data di deploy copiata su tutte le URL insegna al crawler a ignorare il campo.
Cosa significa sostanziale
La documentazione di Google sulla costruzione delle sitemap, letta il 1 novembre 2026, dice che lastmod deve riflettere la data e l'ora dell'ultimo aggiornamento significativo: un cambio al contenuto principale, ai dati strutturati o ai link è significativo, un cambio all'anno di copyright no. Lo stesso documento ricorda che Google ignora priority e changefreq, che restano nel protocollo sitemaps.org ma non nel calcolo.
La distribuzione è il test
cat > lastmod.mjs ([\s\S]*?)/g)].map((m) => m[1]);
const date = (u) => (u.match(/([^/) || [])[1];
const missing = urls.filter((u) => !date(u)).length;
const days = {};
for (const u of urls) {
const d = date(u);
if (d) days[d] = (days[d] || 0) + 1;
}
console.log(`${urls.length} url, ${missing} without lastmod`);
console.log(days);
EOF
curl -s https://ui.eneawork.it/sitemap-blog.xml > sitemap-blog.xml
node lastmod.mjs sitemap-blog.xml
Lo script divide il file in elementi <url>, conta quelli senza <lastmod> e raggruppa le date. Il risultato è diagnostico: se quasi tutte le URL condividono un giorno, il valore viene dal deploy e non dalla modifica. Nel nostro caso 578 URL su 916 hanno la stessa data, quindi il campo descrive una pubblicazione di massa, non 578 modifiche.
Le tre regole
- Una data per URL, presa da updatedAt del contenuto, non da una variabile globale.
- Formato W3C: YYYY-MM-DD oppure data e ora complete con fuso orario, per esempio 2026-11-01T23:10:00+01:00.
- Nessuna data futura: un lastmod di domani è una data impossibile da verificare e viene scartato.
- Se la data non esiste, meglio omettere l'elemento: Google documenta che un lastmod inaffidabile è peggio di un lastmod assente.
Il catalogo EneUI
La stessa regola vale per le 1.556 pagine sotto /blocks, per le 30 categorie come /blocks/category/table con 13 blocchi e per le 12.808 griglie sotto /icons. Ogni URL della sitemap ha una sola data, e i due hub senza lastmod sono una scelta, non una dimenticanza: un hub che cambia a ogni pubblicazione falserebbe la media. Verificato il 1 novembre 2026.
La limitazione
lastmod non accelera la scansione e non è una promessa: è un indizio che Google confronta con la pagina, e se non regge lo ignora. Il nostro file lo dimostra: 84 URL dichiarano una data futura, e la maggioranza condivide un giorno di deploy. Il campo è facile da sbagliare proprio perché nessun validatore XML si lamenta di una data plausibile.
Dove continuare
La differenza fra indice e file unico è in sitemap index o file unico; la generazione automatica in App Router è in sitemap e robots generati in Next.js; la sequenza per entrare nell'indice è in indicizzare un sito su Google.
Domande frequenti
Che formato deve avere lastmod?
Una data W3C: YYYY-MM-DD, oppure data e ora complete con fuso orario. Il formato accetta anche solo l'anno e il mese, ma una data completa è più utile e più facile da verificare.
Posso omettere lastmod?
Sì, e spesso conviene. Un elemento assente è valido; una data falsa no. Se il CMS non conosce la data dell'ultima modifica sostanziale, omettere è la scelta corretta.
Google usa priority e changefreq?
No. Google documenta che ignora entrambi. Restano validi per il protocollo sitemaps.org, ma non cambiano la scansione e allungano il file.
Perché la mia sitemap ha una data sola?
Perché il generatore scrive la data di build su ogni URL. Serve una data per contenuto, presa dal record che cambia, altrimenti il campo non distingue una pagina aggiornata da una ferma da mesi.
Una data futura è un errore?
Sì. Il crawler non può verificarla, quindi la scarta e perde fiducia nel campo. Nel nostro file ne abbiamo 84, misurate il 1 novembre 2026: è il tipo di errore che uno script trova in un secondo.