Lingue

Sitemap XML

Cos'è una sitemap XML, la sua anatomia, i tag ignorati (priority/changefreq), lastmod accurato, i limiti di 50 000/50MB, hreflang nelle sitemap e come inviarne una.

Prima pubblicazione: 22 giu 2026 · Ultimo aggiornamento: 3 ago 2026 · Advanced
Lingue
AIScritto daAI v2
1 segnale di evidenza in questa pagina

Una sitemap XML è un file UTF-8 che elenca gli URL canonici e indicizzabili che vuoi che i motori di ricerca conoscano — ciascuno in un blocco <url> con un <loc> obbligatorio e un <lastmod> opzionale. Aiuta i motori a scoprire gli URL ma non garantisce l'indicizzazione; il suo vero valore è la diagnostica inviati-vs-indicizzati in Search Console. Google ignora <priority> e <changefreq>, e usa <lastmod> solo quando è verificabilmente accurato (aggiornamenti significativi, non un generico 'oggi'). Una sitemap ha un limite di 50 000 URL o 50MB non compressi — oltre si dividono i file e si fa riferimento a essi da un indice di sitemap. Includi solo URL canonici, indicizzabili e con stato 200; escludere un URL dalla sitemap non equivale a noindexarlo. Le sitemap sono anche il posto più semplice per gestire hreflang su larga scala. Fai riferimento ad essa in robots.txt e inviala in Search Console e Bing Webmaster Tools.

TL;DR — Una sitemap XML è un file UTF-8 di URL <loc> canonici e indicizzabili, ciascuno con un <lastmod> opzionale. Aiuta la scoperta, non l’indicizzazione — il vantaggio è il segnale inviati-vs-indicizzati in Search Console. Google ignora <priority> e <changefreq> e usa <lastmod> solo quando è verificabilmente accurato (aggiornamenti significativi, mai un “oggi” generico). Un file ha un limite di 50 000 URL o 50MB non compressi — oltre, dividi e usa un indice di sitemap. Includi solo URL 200, canonici e indicizzabili; escludere un URL non è la stessa cosa che non indicizzarlo. XML non è l’unico formato accettato (RSS/Atom/txt funzionano anche), e le sitemap sono il posto più facile per gestire hreflang su larga scala — anche se queste annotazioni diventano attive con un ritardo, non istantaneamente. Riferiscilo in robots.txt e invialo in Search Console + Bing Webmaster Tools.

Evidence for this claim The XML sitemap protocol lists canonical URL locations and optional metadata, with limits of 50,000 URLs and 50 MB uncompressed per sitemap. Scope: Sitemaps protocol and current Google-supported limits. Confidence: high · Verified: Sitemaps XML format Evidence for this claim Google treats sitemaps as discovery hints rather than guarantees and supports submission through Search Console or robots.txt references. Scope: Current Google sitemap behavior and submission methods. Confidence: high · Verified: Google Search Central: Build and submit a sitemap

Cos’è realmente una sitemap XML

Una sitemap XML è un file, scritto secondo il protocollo sitemaps.org 0.9, che elenca le URL del tuo sito che vuoi far conoscere ai motori di ricerca. La definizione di Google: “Una sitemap è un file in cui fornisci informazioni sulle pagine, i video e altri file del tuo sito, e le relazioni tra di essi.” È un aiuto alla scoperta e un diagnostico della copertura — esplicitamente non una garanzia: “Una sitemap aiuta i motori di ricerca a scoprire le URL del tuo sito, ma non garantisce che tutti gli elementi nella tua sitemap vengano indicizzati e scansionati.”

Questa impostazione è importante, perché è qui che molti sforzi vengono sprecati. La sitemap non è una leva di ranking e non è un comando di indicizzazione. Ecco un esempio minimo annotato:

<?xml version="1.0" encoding="UTF-8"?>            <!-- XML declaration; UTF-8 -->
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">  <!-- root + namespace -->
  <url>                                           <!-- one entry per page -->
    <loc>https://www.example.com/foo.html</loc>   <!-- required: absolute URL -->
    <lastmod>2026-06-04</lastmod>                 <!-- optional: last significant change -->
  </url>
</urlset>

Anatomia

  • La dichiarazione XML — <?xml version="1.0" encoding="UTF-8"?>. Google è inequivocabile: “Il file sitemap deve essere codificato in UTF-8.” Se la codifica è errata, i caratteri speciali si rompono.
  • <urlset> + namespace — l’elemento radice, con xmlns="http://www.sitemaps.org/schemas/sitemap/0.9". Il namespace è ciò che dice al parser che si tratta di una sitemap; un namespace errato o mancante è un errore comune in Search Console.
  • <url> — un blocco per pagina.
  • <loc> — obbligatorio. “Usa URL assolute e complete nelle tue sitemap” — non percorsi relativi, e sotto i ~2 048 caratteri. Tutti i valori devono essere escapati come entità: & diventa &amp;, ' diventa &apos;, " diventa &quot;, > diventa &gt;, e un minore letterale diventa &lt;.
  • <lastmod> — opzionale; la data in cui la pagina è cambiata significativamente (maggiori dettagli sulla regola di onestà sotto).
Evidence for this claim Each loc must be a fully qualified absolute URL and XML special characters must be entity escaped. Scope: XML/HTTP sitemap generation, hosting and submission Confidence: high · Verified: Build and submit a sitemap

La verità sui tag ignorati

Questo è l’aspetto più obsoleto nella maggior parte dei tutorial sulle sitemap. Due tag legacy — <priority> e <changefreq> — sono ignorati da Google. Gary Illyes ha definito priority “essenzialmente un sacco di rumore,” e John Mueller ha detto che priority e change frequency “non giocano più un ruolo così importante con le sitemap.” Bing ha confermato lo stesso: changefreq e priority non influenzano più la sua scansione o il ranking. Puoi lasciarli (non fanno danni) o rimuoverli — semplicemente non fanno nulla.

<lastmod> è diverso — non metterlo insieme ai tag ignorati. Google usa <lastmod>, ma solo quando si fida, e quella fiducia è più o meno binaria: o Google crede alle tue date o no. La regola è che la data dovrebbe riflettere un cambiamento significativo — “un aggiornamento al contenuto principale, ai dati strutturati o ai link sulla pagina è generalmente considerato significativo, mentre un aggiornamento alla data di copyright non lo è.” Il modo di fallire che vedo costantemente è marcare ogni URL con la data di oggi a ogni build. Questo è controproducente: Mueller l’ha definito “semplicemente pigro,” notando che è banale per i motori riconoscerlo e rende solo più difficile per loro individuare pagine realmente aggiornate. Mentisci abbastanza spesso e, secondo Google, “alla fine non ti crederemo più.” Bing si affida ancora di più a <lastmod> come segnale di freschezza di quanto faccia Google — quindi una data accurata ti aiuta su entrambi i motori, e una falsa ti danneggia su entrambi.

Posizionamento, denominazione, codifica e compressione

  • Posizionamento/nome. Non esiste un nome file obbligatorio, ma /sitemap.xml alla radice è la convenzione. Di default, una sitemap influisce solo sugli URL al di sotto del proprio percorso, quindi tienila abbastanza in alto da coprire tutto ciò che elenca. L’unica eccezione: puoi ospitare una sitemap per un sito diverso se hai verificato la proprietà di quel sito e il suo robots.txt punta alla posizione effettiva della sitemap — Google chiama questo cross-submission, ed è il meccanismo dietro un sitemap index che aggrega sitemap ospitate altrove.
  • Codifica. UTF-8, sempre.
  • Compressione. Puoi comprimere una sitemap con gzip (servirla come .xml.gz), il che vale la pena su file di grandi dimensioni. Sfumatura importante: il limite di 50MB è misurato non compresso — gzip risparmia banda, non margine rispetto al limite di dimensione.

Limiti → dividi + sitemap index

Una singola sitemap è limitata a 50 000 URL o 50MB non compressi, a seconda di quale arriva prima. Google lo afferma direttamente: “All formats limit a single sitemap to 50MB (uncompressed) or 50,000 URLs.” Quando superi uno dei due limiti, dividi l’elenco in più file sitemap e fai riferimento a tutti da un sitemap index — una sitemap di sitemap. Questo è un argomento correlato a sé; la versione breve è che invii l’indice, e un indice può puntare a un massimo di 50 000 sitemap figlie, quindi non esaurirai mai la capacità.

Quali URL includere — e “escludere ≠ noindex”

Includi solo URL che sono indicizzabili, canonici e restituiscono 200. Ciò significa niente reindirizzamenti 3xx, niente duplicati non canonici, niente pagine noindex, niente URL bloccati da robots. Una sitemap pulita del tuo set indicizzabile esatto è ciò che rende significativo il confronto tra inviati e indicizzati in Search Console — se la inquini con spazzatura, hai buttato via la diagnostica.

Ora il punto meccanico che la gente sbaglia: escludere un URL dalla tua sitemap non lo deindicizza. La sitemap è un annuncio, non un cancello. Rimuovere la voce di un URL smette solo di pubblicizzare quella pagina; se Google già la conosce (tramite link, cronologia o un’altra fonte) rimane nell’indice. Gli unici meccanismi che rimuovono effettivamente una pagina sono una direttiva noindex (con crawling consentito così Google può vederla), un 404/410, o lo strumento di rimozione. Quindi “toglilo dalla sitemap” non è mai la risposta giusta a “come faccio a deindicizzare questo.”

Formati di file sitemap accettati

XML non è l’unico formato che Google accetta — vale la pena saperlo per non pensare di essere bloccati a scrivere XML a mano. Google chiama XML “the most versatile of the sitemap formats,” ma legge anche:

  • Feed RSS 2,0 / Atom — utili perché molti CMS ne pubblicano già uno; contengono solo URL di pagine.
  • mRSS — un feed RSS per media, usato per i video.
  • Testo semplice (.txt) — letteralmente un URL per riga, solo URL di pagine web, UTF-8.

XML è comunque il default giusto perché è l’unico formato che supporta le estensioni (metadati lastmod, annotazioni per immagini, video e hreflang). Gli altri sono solo URL.

hreflang nelle sitemap

Se gestisci un sito multilingue o multiregionale, la sitemap è di solito il posto più facile per gestire hreflang — mantieni l’intero cluster linguistico in un unico file invece di iniettare tag di ritorno in ogni template di pagina. (È uno dei tre posti validi in cui hreflang può vivere; <head> e le intestazioni HTTP sono gli altri.)

Come è implementato. Ogni <url> riceve figli xhtml:link rel="alternate", uno per versione lingua/regione, e dichiari il namespace xmlns:xhtml="http://www.w3.org/1999/xhtml" su <urlset>:

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://www.example.com/english/page.html</loc>
    <xhtml:link rel="alternate" hreflang="en" href="https://www.example.com/english/page.html"/>
    <xhtml:link rel="alternate" hreflang="de" href="https://www.example.de/deutsch/page.html"/>
    <xhtml:link rel="alternate" hreflang="x-default" href="https://www.example.com/english/page.html"/>
  </url>
  <!-- each alternate URL repeats the FULL set, including itself (return tags) -->
</urlset>

La regola del tag di ritorno. Questa è la parte che mette nei guai. Ogni elemento <url> deve elencare ogni versione alternativa della pagina — inclusa se stessa. Google: “Each <url> element must have a child element <xhtml:link rel="alternate" hreflang="[supported_language-code]"> that lists every alternate version of the page, including itself.” E deve essere bidirezionale: “If page X links to page Y, page Y must link back to page X. If this is not the case for all pages that use hreflang annotations, those annotations may be ignored or not interpreted correctly.” Aggiungi una voce x-default per il fallback della lingua non corrispondente. Un singolo tag di ritorno rotto o mancante può invalidare l’intero set.

Il limite conta solo gli URL <loc>. Un sollievo per i grandi siti internazionali: il limite di 50 000 URL conta solo gli URL delle pagine <loc>, non le alternative hreflang. Quindi una sitemap con 50 000 pagine, ciascuna con dieci alternative linguistiche, rientra ancora — sono gli URL di posizione che contano, non gli URL alternativi.

Quando va effettivamente in produzione — giorni di budget, non minuti. Ecco l’aspettativa da impostare, ed è un meccanismo piuttosto che una frase citabile. Google analizza l’hreflang della tua sitemap quando ri-fetches la sitemap, ma le annotazioni prendono effetto solo quando tutti gli URL nel set sono stati (ri)scansionati e i tag di ritorno riconciliati tra loro. Ciò significa che c’è un ritardo reale tra la pubblicazione dell’hreflang e il rispetto delle alternative, e un URL lento da ri-scansionare o rotto nel set può bloccare il resto. Non aspettarti che si attivi nel momento in cui invii — pianifica che si stabilizzi nell’arco di giorni.

Riferiscilo e invialo

  • robots.txt — aggiungi una riga Sitemap: con l’URL assoluto completo. Questo consente anche ai motori di scoprirlo automaticamente.
  • Google Search Console — il report Sitemaps (o l’API Search Console) è il metodo di invio principale; è anche dove leggi la diagnostica inviato-vs-indicizzato.
  • Bing Webmaster Tools — invia anche lì; Bing lo recupera rapidamente e lo ricontrolla regolarmente.

Una nota di automazione da come la penso: una sitemap dovrebbe essere generata automaticamente dalle pagine che hai effettivamente, così rimane aggiornata. Una sitemap costruita a mano marcisce nel momento in cui il tuo sito cambia. I fratelli di questa pagina — la panoramica delle sitemap, l’indice delle sitemap per i grandi siti, e le estensioni sitemap immagini e sitemap video — coprono il resto della famiglia, e l’argomento più ampio della scoperta collega le sitemap agli altri modi in cui i motori trovano i tuoi URL.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.