Aggiungere ogni giorno un timestamp all’URL di una sitemap per convincere Google a scaricarla di nuovo può sembrare una scorciatoia intelligente. In realtà rischia di comunicare esattamente il segnale sbagliato: che l’indirizzo di una risorsa cambia continuamente. John Mueller di Google ha sconsigliato questa pratica, riportando al centro un principio della SEO tecnica che continua a essere valido anche nel 2026: quando non esiste una ragione reale per cambiare URL, la stabilità è una caratteristica positiva.

Il caso è stato analizzato da NetContentSEO nell’articolo “Don’t Cache-Bust Your Sitemap: Google Says Stable URLs Still Matter”, a partire da uno scambio pubblico ripreso anche da Search Engine Journal. La domanda riguardava un grande sito nel quale le sitemap figlie presenti in un sitemap index ricevevano quotidianamente un nuovo parametro, per esempio un Unix timestamp. L’obiettivo apparente era semplice: creare ogni giorno un URL diverso e indurre i crawler a considerare la sitemap come una nuova risorsa da recuperare.

Per Google è una cattiva idea

Search Engine Journal riporta la risposta di Mueller, che definisce l’approccio una cattiva idea perché comunica che l’URL canonico di una risorsa continua a cambiare. Il problema non riguarda soltanto il comportamento dei motori di ricerca: URL instabili complicano anche tracking, analisi dei log e monitoraggio tecnico.

Un sitemap index che oggi punta a sitemap-products.xml?v=1788440000 e domani a una variante con un timestamp differente può essere concettualmente sempre la stessa sitemap per il team SEO, ma dal punto di vista del protocollo HTTP sono URL differenti. È proprio questa differenza a rendere improprio l’uso del cache busting in questo contesto.

Il cache busting è utile, ma risolve un altro problema

La tecnica non è sbagliata in assoluto. Nel web development viene comunemente utilizzata per asset come CSS e JavaScript. Quando cambia un file e si vuole evitare che browser o cache intermedie continuino a utilizzare una versione precedente, aggiungere un identificatore di versione all’URL può forzare il recupero della nuova risorsa.

Google stesso ha spiegato nella propria documentazione sul crawling che i parametri di cache busting devono essere utilizzati con cautela: quando l’URL di una risorsa cambia, Google può doverla scaricare nuovamente anche se il contenuto sottostante non è realmente diverso. Questo consuma risorse di crawling. Applicare lo stesso meccanismo a una sitemap con l’unico obiettivo di provocare un nuovo fetch confonde quindi due esigenze differenti: aggiornare una risorsa realmente modificata e simulare artificialmente la novità di una risorsa stabile.

Per comunicare un cambiamento esiste già lastmod

Il protocollo sitemap dispone già di un meccanismo per segnalare modifiche. In un sitemap index, il campo può indicare quando una sitemap figlia è stata aggiornata; nelle sitemap delle pagine, lo stesso elemento può comunicare l’ultima modifica significativa di una URL. Non serve creare un nuovo indirizzo ogni volta che cambia il contenuto.

Il concetto fondamentale è però l’accuratezza. La documentazione di Google sulle sitemap raccomanda di includere gli URL canonici che si desidera vedere nei risultati e di fornire informazioni coerenti. Aggiornare lastmod ogni giorno su pagine che non sono cambiate realmente non rappresenta un’alternativa virtuosa al cache busting: significa semplicemente sostituire un segnale artificiale con un altro.

Una data di modifica è utile al crawler quando descrive una modifica effettiva, per esempio un aggiornamento sostanziale del contenuto principale, dei dati strutturati o di altri elementi significativi della pagina. Se il valore viene aggiornato automaticamente a ogni generazione della sitemap indipendentemente dai cambiamenti reali, perde parte del proprio valore informativo.

Una sitemap è un segnale, non un comando a Googlebot

Dietro il cache busting delle sitemap c’è spesso un’aspettativa più ampia: l’idea che, riuscendo a far recuperare il file ogni giorno, si possa obbligare Google a visitare rapidamente anche tutte le pagine elencate. Non è così. Una sitemap aiuta i motori a scoprire URL e cambiamenti, ma non costituisce un comando di crawling né garantisce l’indicizzazione.

La distinzione è particolarmente importante per siti editoriali, ecommerce e piattaforme con inventari molto grandi. Un file XML ben costruito può rendere più chiara la struttura degli URL importanti e aiutare Google a individuare contenuti nuovi o modificati. La decisione su quando e quanto effettuare il crawling resta però al motore di ricerca, che considera molti altri segnali e limiti operativi.

Di conseguenza, se una pagina importante viene scoperta o ricrawlata troppo lentamente, cambiare continuamente l’URL della sitemap tratta il sintomo anziché la causa. Occorre capire se la pagina è raggiungibile tramite link interni, se il server risponde correttamente, se esistono problemi di canonicalizzazione, se Googlebot incontra errori e se il contenuto presenta motivi sufficienti per essere rivisitato.

URL stabili rendono migliore anche il monitoraggio SEO

La stabilità offre un vantaggio operativo spesso sottovalutato. Se /sitemap.xml mantiene lo stesso indirizzo nel tempo, è molto più semplice osservare nei server log quando Googlebot lo recupera, confrontare frequenza e status code, analizzare errori e verificare il comportamento di Search Console. Con decine o centinaia di varianti parametrizzate, la stessa storia viene frammentata tra URL formalmente differenti.

Su siti grandi, una struttura prevedibile può essere molto semplice: un sitemap index stabile e sitemap figlie stabili, eventualmente organizzate per tipologia di contenuto o sezione. Quando una sitemap cambia realmente, il relativo lastmod viene aggiornato. Questo rende l’infrastruttura leggibile sia per i crawler sia per le persone che devono diagnosticarla.

I parametri URL possono moltiplicare inutilmente lo spazio di crawling

Il tema non riguarda soltanto le sitemap. Gary Illyes di Google ha più volte richiamato l’attenzione sul fatto che parametri differenti producono URL differenti anche quando il server restituisce lo stesso contenuto. In casi estremi, combinazioni incontrollate di parametri possono espandere enormemente lo spazio degli URL che un crawler potrebbe incontrare.

Non significa che ogni parametro sia dannoso. Ecommerce, applicazioni web, tracking e sistemi di filtraggio ne fanno un uso legittimo. La domanda tecnica corretta è se la variante rappresenti davvero una risorsa che deve avere un’identità distinta oppure se stia creando duplicazione senza valore. Nel caso del timestamp aggiunto ogni giorno alla stessa sitemap, il secondo scenario è particolarmente evidente.

Forzare il fetch non è una strategia di indicizzazione

Google ha già ridimensionato in passato meccanismi che venivano utilizzati per sollecitare artificialmente il recupero delle sitemap. Nel 2023 ha dismesso l’endpoint pubblico e non autenticato per il sitemap ping, spiegando che era diventato poco utile e fortemente soggetto a spam. Il messaggio di fondo è coerente con la posizione attuale: fornire informazioni accurate è più utile che generare segnali artificiali di freschezza.

Per siti che pubblicano contenuti molto sensibili al tempo esistono strumenti specifici, come le sitemap News quando applicabili, oltre a feed RSS o Atom. Search Console può essere utile in determinate situazioni per richiedere l’indicizzazione di singole pagine. Nessuno di questi strumenti, però, trasforma il crawling in un processo programmabile dal publisher a piacimento.

La SEO tecnica migliore spesso è quella meno “creativa”

Il caso raccontato da NetContentSEO contiene una lezione più generale. La SEO tecnica è piena di situazioni nelle quali un meccanismo nato per uno scopo viene riutilizzato nel tentativo di ottenere un vantaggio in un altro. A volte l’esperimento produce informazioni utili; altre volte aggiunge soltanto complessità a un protocollo che dispone già degli strumenti necessari.

Per le sitemap, la soluzione raccomandabile rimane deliberatamente poco spettacolare: URL puliti e persistenti, lastmod accurati, sitemap index comprensibili, URL canonici corretti, link interni crawlable e monitoraggio dei problemi reali. Se Googlebot non torna su una pagina con la frequenza desiderata, il compito della SEO è comprenderne il motivo, non far sembrare nuova ogni mattina la sitemap che la contiene.

Gli URL stabili, in altre parole, non sono un residuo di una SEO più semplice. Sono ancora una parte dell’infrastruttura che rende il web interpretabile, monitorabile e meno ambiguo. E quando il problema è comunicare a Google che qualcosa è realmente cambiato, il segnale migliore resta quello più elementare: cambiare ciò che è cambiato e lasciare stabile ciò che non lo è.