Strategia sitemap per un sito con molte pagine: split, index, lastmod

Alla fine avrai un sitemap che regge oltre 50.000 URL, dice ai motori quali pagine sono davvero cambiate e fa scansionare i post nuovi in poche ore invece che in settimane. È la configurazione che usiamo sui siti di contenuti che pubblicano quasi ogni giorno e puntano a superare i mille articoli.

Un sitemap è un file che elenca gli URL di un sito e, se vuoi, quando ognuno è cambiato l'ultima volta. Su un sito piccolo conta poco: Google trova cinquanta pagine ben collegate anche senza aiuto. Su un sito grande il sitemap smette di essere un dettaglio e diventa la mappa con cui i crawler decidono cosa scaricare e ogni quanto. Se è sbagliato, i post freschi restano invisibili per settimane mentre il crawler rilegge pagine che non si sono mosse.

Cosa serve prima di iniziare

• L'elenco di ogni URL canonico e indicizzabile del sito, generato dal database e non tenuto a mano.
• Una data di ultima modifica affidabile per ogni URL, che rifletta un cambiamento reale di contenuto, non ogni scrittura sul database.
• Accesso a Google Search Console e Bing Webmaster Tools per inviare e monitorare.
• Un framework che genera XML a runtime o in build. Gli esempi qui usano Next.js, ma le regole valgono ovunque.

Passo 1: conosci i due limiti duri

Google ferma un singolo file sitemap a 50.000 URL o 50MB non compressi, quale dei due arriva prima (Google Search Central). Puoi comprimere il file in gzip per risparmiare banda, ma il tetto dei 50MB si misura sul non compresso. Superi uno dei due limiti e Google scarta il file.

Il sitemap index risolve il problema. È un file che elenca altri sitemap invece di URL, e può referenziarne fino a 50.000. In teoria sono 2,5 miliardi di URL in un solo index. Nessun blog ci arriva. Il punto è più stretto: appena superi i 50.000 URL, smetti di pubblicare un file solo e inizi a pubblicare un index che punta a più frammenti.

Passo 2: dividi per tipo di contenuto, non per numero a caso

La divisione ingenua è per conteggio: 50.000 URL a file, tagliati in ordine di pubblicazione. Funziona, ma butta via un segnale di diagnosi. Meglio dividere per tipo di contenuto. Gli articoli in un sitemap, le pagine di categoria in un altro, le pagine statiche in un terzo. Ogni frammento resta sotto il limite e Google Search Console riporta la copertura per singolo sitemap. Quando l'indicizzazione cala, vedi quale tipo di contenuto è colpito invece di fissare un unico numero per tutto il sito. Segmentare per tipo è la pratica standard proprio per questo (Google Search Central).

Se un singolo tipo supera comunque i 50.000 URL, dividi quel tipo per numero: blog-1.xml, blog-2.xml e così via, tutti elencati nell'index.

Passo 3: metti solo gli URL che vuoi indicizzati

Un sitemap è l'elenco dei tuoi URL migliori, non di ogni URL che risponde. Includi una pagina solo se restituisce 200, non è marcata noindex, non è bloccata dal robots.txt ed è canonica di sé stessa. Non elencare mai redirect, 404, varianti con parametri o pagine che si canonicalizzano altrove. Mescolare URL non indicizzabili in un sitemap manda un segnale contraddittorio: chiedi a Google di indicizzare una pagina che gli hai già detto di ignorare. Su un sito grande queste contraddizioni si sommano e corrodono la fiducia nell'intero file.

Su un sito multilingua, dichiara ogni variante di lingua con gli alternate hreflang dentro la voce del sitemap, invece di pubblicare tre volte lo stesso URL. Così le relazioni tra le lingue restano esplicite e il conteggio degli URL resta onesto.

Passo 4: tieni onesto il lastmod, e togli il resto

Esistono tre tag opzionali: lastmod, changefreq e priority. Uno solo si merita il posto. Google ignora del tutto priority e changefreq (Google Search Central), e aggiungono byte a un file che stai cercando di tenere piccolo. Toglili.

lastmod è un'altra cosa. È l'unico attributo del sitemap che i motori moderni usano davvero, e Google lo legge solo quando è accurato in modo costante. John Mueller è stato netto: falsificare la data non aiuta il ranking, e quando Google decide che il tuo lastmod è inaffidabile smette del tutto di fidarsi del tag (Search Engine Journal). La maggior parte dei siti lo tiene così male che Google lo sconta di default.

La regola è semplice. Imposta lastmod sulla data di un cambiamento reale del contenuto, e su nient'altro. Non toccarlo a ogni scrittura sul database, a ogni migrazione di metadati, a ogni deploy. Se il CMS aggiorna una riga per motivi che il lettore non vede mai, quel movimento non deve spostare lastmod. Noi lo ancoriamo allo stesso segnale che mostriamo al lettore come data di aggiornamento, così la freschezza vista dalla macchina e quella vista dalla persona restano allineate. Ne parliamo meglio nell'articolo sulla freschezza dei contenuti e la regola dei 90 giorni.

Passo 5: notifica al cambiamento, perché il ping è morto

Inviare un sitemap una volta dice ai motori dove vive. Non gli dice il momento in cui un post nuovo va online. La vecchia spinta, l'endpoint di ping del sitemap, non c'è più. Google ha rimosso la sua API di ping nel 2023 e Bing ha deprecato la propria nel 2022 (Ctrl blog).

Il sostituto è IndexNow, un protocollo che avvisa i motori partecipanti nell'istante in cui un URL viene aggiunto, cambiato o rimosso. Lo usano Bing, Yandex, Naver e Seznam. Google lo ha testato e, a metà 2026, ancora non lo usa. Bing riferisce che il 22% degli URL cliccati nei suoi risultati arriva ormai da invii IndexNow. La linea ufficiale non è o-l'uno-o-l'altro: tieni il sitemap come inventario completo e aggiungi IndexNow per le notifiche istantanee di cambiamento (IndexNow.org). Per Google, un sitemap fresco e accurato più un buon lavoro di link interni resta la via della scoperta.

Passo 6: generalo in modo dinamico con Next.js

L'XML tenuto a mano marcisce il giorno in cui qualcuno si dimentica di aggiornarlo. Genera il sitemap dagli stessi dati che rendono le pagine. Nell'App Router di Next.js, generateSitemaps restituisce un array di id, e Next serve ogni frammento su /sitemap/[id].xml (documentazione Next.js). Conta il totale dei post, dividi per una dimensione di blocco sotto i 50.000 e mappa ogni id a un intervallo del database. Metti in cache la query per 24 ore, così un sito che pubblica ogni giorno non ricostruisce l'intera mappa a ogni passaggio del crawler.

Come verificare che funzioni

1. Invia l'URL dell'index in Google Search Console e Bing Webmaster Tools, non i frammenti figli. Google scopre i figli tramite l'index.
2. Apri il report Sitemap qualche giorno dopo. Ogni frammento dovrebbe risultare in stato di successo, con un numero di URL trovati vicino a quello che ti aspetti.
3. Controlla a campione un sitemap figlio nel browser. Deve restituire XML valido, elencare solo URL canonici in 200 e portare date lastmod che corrispondono a modifiche reali.
4. Passa lo strumento di controllo URL su un post appena pubblicato. Se Google lo ha trovato tramite il sitemap, il report lo dice.

Errori frequenti e come risolverli

• Sitemap figli nella cartella sbagliata. Un sitemap elencato in un index deve stare nella stessa cartella o più in basso (Google Search Central). Un index nella root non può referenziare un figlio in una cartella sorella. Tienili al livello dell'index o sotto.
• lastmod che non sta mai fermo. Se ogni deploy tocca ogni data, Google impara che il tag è rumore e lo ignora. Ancora il lastmod solo al cambiamento di contenuto.
• Inviare ogni frammento a mano. Aggiungere ogni sitemap figlio separatamente intasa il report e non porta nulla. Invia solo l'index.
• Pagine noindex dentro il sitemap. La contraddizione più comune. Filtra l'elenco in fase di generazione, così una pagina non può essere insieme elencata e soppressa.
• Trattare il sitemap come un ordine di scansione. È un suggerimento, non un comando. Aiuta la scoperta, non forza l'indicizzazione. Pagine povere o duplicate non si posizionano solo perché stanno in un sitemap.

Per andare oltre

Il sitemap è un pezzo del livello di scoperta. Abbinalo alla disciplina di freschezza della nostra guida sulla regola dei 90 giorni, alle regole di accesso dei crawler in Cloudflare e i crawler AI, e al resto delle basi pre-lancio nella nostra checklist di SEO tecnica. Se i motori AI fanno parte del tuo piano di traffico, llms.txt descrive il file che fa per i modelli linguistici quello che il sitemap fa per i crawler.