Come creare una sitemap XML corretta

Una sitemap XML è un file che elenca gli URL che vuoi far trovare ai motori di ricerca. Serve a farli scoprire, e finisce lì. Google scrive che «inviare una Sitemap è solo un suggerimento: non garantisce che Google la scaricherà o utilizzerà la Sitemap per eseguire la scansione degli URL sul sito».

Tre fatti cambiano il lavoro di tutti i giorni. Il ping HTTP delle sitemap è spento da giugno 2023 e l’endpoint risponde 404, esattamente come Google aveva annunciato. changefreq e priority non li guarda né Google né Bing, e lo dichiarano per iscritto tutti e due. lastmod conta a una condizione, che deve dire la verità, ed è la parte che sparisce quando qualcuno riassume.

Quali tag i motori leggono davvero, dove va messo il file, come si invia a Google e a Bing, come si valida e cosa non ci va dentro: l’articolo risponde a queste domande, a partire da una sitemap minima da copiare.

Cos’è una sitemap XML

Una sitemap XML è un file in formato XML che elenca gli URL di un sito, perché i motori li scoprano senza doverli raggiungere navigando. Codifica UTF-8, URL assoluti, un blocco <url> per pagina.

Quello che non fa è la parte che manda in vacca le aspettative. Non fa indicizzare: la documentazione di Google sulle sitemap scrive che il file «non garantisce che tutti gli elementi nella Sitemap vengano sottoposti a scansione e indicizzazione». E non sposta il posizionamento: nessuna pagina ufficiale di Google o di Bing le attribuisce un peso in classifica.

Il modello mentale è la lista della spesa consegnata a uno che fa la spesa di mestiere. La legge, la tiene presente, poi compra quello che gli pare. Se ci scrivi trenta volte «prosciutto» non torna con trenta prosciutti: torna con la faccia di chi ha capito che hai un problema.

Quando serve davvero

Serve se il sito è grande, se è nuovo e pochi altri siti lo linkano, o se hai video, immagini o contenuti news da far comparire nei risultati. Sono i tre casi che Google elenca sotto «Ti potrebbe servire una Sitemap se».

Puoi farne a meno a tre condizioni: circa 500 pagine o meno, un linking interno che raggiunge tutte le pagine importanti, nessun media o contenuto news da mostrare in Ricerca. Google le mette in fila senza dire se valgono insieme o una alla volta, ma leggerle come alternative è il modo più rapido per sbagliare: se te ne manca una, la sitemap ti serve.

Qui casca mezza internet. Un catalogo di 300 prodotti sta sotto le 500 pagine, ma se le schede si raggiungono solo passando da un filtro che gira in JavaScript il secondo requisito non c’è. La soglia dimensionale, da sola, non ha mai deciso niente.

Sul conteggio delle 500 c’è poi una precisazione che cambia il risultato: «Ai fini di questo calcolo vengono considerate soltanto le pagine che ritieni debbano essere presenti nei risultati di ricerca». Le varianti di un filtro e le pagine di servizio non fanno numero.

Esempio di sitemap XML da copiare

Ecco il file minimo che funziona: dichiarazione XML, urlset con il namespace del protocollo, un blocco url con dentro un loc. Tutto il resto è opzionale.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://esempio.it/</loc>
  </url>
</urlset>

Con più URL e con lastmod diventa questo. Guarda la terza voce: la & dentro l’URL è scritta &, perché il protocollo ufficiale su sitemaps.org impone che tutti i valori siano entity-escaped. Una & nuda ti fa fallire il parsing.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://esempio.it/</loc>
  </url>
  <url>
    <loc>https://esempio.it/guide/sitemap-xml/</loc>
    <lastmod>2026-08-28</lastmod>
  </url>
  <url>
    <loc>https://esempio.it/cerca/?q=pizza&amp;ordine=prezzo</loc>
    <lastmod>2026-07-14T09:30:00+02:00</lastmod>
  </url>
</urlset>

Tutti e due i file passano la validazione contro lo schema ufficiale.

L’attributo xmlns punta a http e non a https, e non è un refuso: è un identificatore che serve al parser, non un indirizzo da visitare. Se lo riscrivi in https il file smette di validare, e lo schema risponde No matching global declaration available for the validation root.

I tag della sitemap, uno per uno

Obbligatori sono tre: urlset, url e loc. Gli altri sono opzionali, e due su tre non li legge nessuno dei due motori principali.

Una regola vale per tutti e sei: ogni valore va scritto entity-escaped. & diventa &, ' diventa ', " diventa ", > diventa >, < diventa <. Sui siti con filtri e parametri è il primo errore che salta fuori, e in Search Console si presenta come «Errore di analisi», che non ti dice dove guardare.

Un vincolo meno noto: tutti gli URL di una sitemap devono stare su un solo host. www.esempio.it e store.esempio.it sono due host, quindi due file.

Questi limiti vengono dal protocollo. Cosa i motori ne facciano è un’altra faccenda, con date molto più recenti.

Quali tag contano davvero

Di sei tag, i motori ne usano due: loc e lastmod. Google dichiara di ignorare priority e changefreq, Bing ha detto la stessa cosa il 31 luglio 2025.

Le formule, per esteso. La pagina di Google sul formato, aggiornata all’8 luglio 2026: «Google ignora i valori <priority> e <changefreq>». Il post del Bing Webmaster Blog sulle sitemap, del 31 luglio 2025, esiste solo in inglese: i tag facoltativi come changefreq e priority sono ignorati da Bing e non influenzano né la scansione né il posizionamento. Le frasi di Bing, qui e più avanti, le traduco io.

Non è una novità dell’altro ieri: già nel giugno 2023 Google scriveva «Google non utilizza affatto l’elemento changefreq o priority». Nello stesso post c’è il perché: changefreq «si sovrappone anche concettualmente a lastmod», mentre priority è «un campo molto soggettivo» che, in base agli studi interni di Google, «di solito non riflette accuratamente la priorità effettiva di una pagina rispetto ad altre pagine di un sito».

Tradotto: priority misura quanto ci tieni tu, e quanto ci tieni tu non è un’informazione. Se metti 1.0 ovunque, e i generatori lo fanno, hai scritto un file in cui ogni pagina è la più importante.

lastmod: l’unico opzionale che conta

lastmod funziona solo se dice la verità. Google usa il valore «se è corretto in modo coerente e verificabile (ad esempio, confrontandolo con l’ultima modifica della pagina)»: la condizione fa parte dell’affermazione, e senza di quella l’affermazione è un’altra.

Cosa succede se gli menti lo spiegano loro nel post di Google su lastmod e ping: «se la vostra pagina è cambiata 7 anni fa, ma ci viene detto nell’elemento lastmod che è cambiata ieri, non crederemo più alla vostra indicazione della data dell’ultima modifica delle pagine». Non arriva una penalizzazione. Smettono di guardare quel campo sul tuo sito, e il segnale evapora.

Per Google la modifica è quella significativa: contenuto principale, dati strutturati, link. Un testo cambiato nella sidebar non conta.

Il difetto più diffuso nasce da lì. Un CMS che riscrive tutte le date a ogni rigenerazione ti produce un file in cui tremila pagine risultano modificate stanotte alle 3:14. Lo riconosci con un comando:

grep -oE '<lastmod>[^<]+' sitemap.xml | sed 's|<lastmod>||' | cut -c1-10 | sort | uniq -c | sort -rn | head

Se in cima esce un solo giorno con dentro quasi tutti gli URL, e quel giorno è oggi, non hai un segnale di freschezza: hai la data del build.

C’è anche un permesso che quasi nessuno riporta: lastmod puoi metterlo solo dove sei sicuro. Nello stesso post Google lo concede URL per URL, con l’esempio della home e delle categorie, la cui data il software spesso non sa calcolare. Un lastmod assente vale più di un lastmod finto.

Dove va messo il file

In root. Il motivo è tecnico: una sitemap vale solo per i discendenti della directory in cui sta, quindi messa in / copre tutto il sito.

La formula, nella stessa pagina di Google, è «a meno che non le invii tramite Search Console, una Sitemap riguarda solo i discendenti della directory parent». L’eccezione sta tutta in quella subordinata: l’invio da Search Console scavalca il vincolo.

Serve saperlo quando il rapporto Sitemap risponde «URL non consentito» e tu giuri che gli URL sono giusti. Con la sitemap a https://esempio.it/blog/sitemap.xml, https://esempio.it/ è un livello sopra e https://esempio.it/shop/ è una directory sorella: stanno fuori, e il file è formalmente corretto lo stesso. O sposti il file in root, o lo invii dal rapporto Sitemap. Io sposto il file.

Sul nome nessuno ti obbliga: sitemap.xml è convenzione, non specifica. Conta che l’URL risponda 200 e serva XML.

Come trovare la sitemap di un sito

Prima il robots.txt, sempre: se c’è una riga Sitemap:, la risposta è lì.

curl -s https://esempio.it/robots.txt | grep -i sitemap

Se non esce niente, si provano i percorsi convenzionali: /sitemap.xml, /sitemap_index.xml (il default di parecchi plugin SEO), /wp-sitemap.xml su WordPress, /sitemap.xml.gz se il file è compresso.

Se falliscono anche quelli, non hai finito le opzioni: hai finito i posti dove è ragionevole cercare. Il nome del file è libero e non esiste un percorso obbligatorio. Quando qualcuno ti dice «quel sito non ha la sitemap» perché /sitemap.xml risponde 404, ha dimostrato una cosa sola: che /sitemap.xml risponde 404.

Sitemap e robots.txt

Una riga, in qualsiasi punto del file: Sitemap: seguito dall’URL assoluto.

User-agent: *
Disallow: /wp-admin/

Sitemap: https://esempio.it/sitemap.xml
Sitemap: https://esempio.it/sitemap-news.xml
Sitemap: https://cdn-esempio.it/sitemap-immagini.xml

La specifica del robots.txt toglie di mezzo tre superstizioni. Il campo non è legato ad alcuno user-agent, quindi non serve infilarlo dentro un gruppo User-agent. Le righe possono essere molte, perché Google non pone un limite. E l’URL non deve stare per forza sullo stesso host del robots.txt: la terza riga dell’esempio qui sopra è legittima.

C’è una trappola simmetrica. Google rispetta il robots.txt anche quando va a prendere la sitemap: se una regola Disallow copre il percorso del file, il rapporto risponde «Impossibile recuperare». Succede a chi blocca /wp-content/ senza accorgersi che la sitemap ci sta dentro.

Sintassi completa, precedenza fra direttive in conflitto e token dei crawler AI stanno nella guida al robots.txt.

Come inviare la sitemap a Google

Tre modi vivi: il rapporto Sitemap di Search Console, l’API di Search Console, la riga nel robots.txt. Se pubblichi un feed Atom o RSS ce n’è un quarto, WebSub. Il ping HTTP che trovi ancora in mezza internet è spento.

La scelta dipende da una cosa: se ti serve vedere gli errori. Il rapporto Sitemap mostra quando Googlebot ha preso il file e cosa non gli è piaciuto, la riga nel robots.txt lo fa scoprire e basta. Nella pratica si fanno tutte e due.

Il ping è morto il 26 giugno 2023: lo ha annunciato Gary Illyes con sei mesi di preavviso. In cima a quel post c’è la nota «Il ritiro dell’endpoint ping delle Sitemap è stato completato», e nel corpo del post Google scriveva che le richieste all’endpoint deprecato «genereranno un errore 404». È quello che risponde:

curl -s -o /dev/null -w "%{http_code}\n" \
  "https://www.google.com/ping?sitemap=https://esempio.it/sitemap.xml"
# 404

Se un plugin sul tuo sito continua a chiamare quell’indirizzo, non devi correre a disinstallarlo. Google è esplicita: il codice esistente non causa problemi a Search, semplicemente quelle chiamate non producono più nessun effetto. Stai facendo una richiesta HTTP a vuoto quattro volte al giorno, che è brutto ma non è un danno.

Cosa mostra il rapporto Sitemap

Non mostra le sitemap che hai dichiarato soltanto nel robots.txt. La guida al rapporto Sitemap elenca «solo le Sitemap inviate utilizzando il report stesso o l’API, non quelle rilevate tramite un riferimento nel file robots.txt o altri metodi di rilevamento».

Gli stati, nell’interfaccia italiana, sono tre: Riuscita, Impossibile recuperare, La Sitemap presentava X errori. Chi traduce a orecchio scrive «Completato», che nella schermata non c’è.

Pagine rilevate conta gli URL analizzati a partire dalla sitemap, duplicati esclusi, ma non garantisce che siano scansionati o indicizzati. Per il numero vero, nel rapporto Indicizzazione delle pagine puoi filtrare per singola sitemap.

Ultima aspettativa da smontare: eliminare una sitemap la toglie dal rapporto, ma «Google non dimenticherà la Sitemap o gli URL indicati al suo interno». Chi la cancella sperando di far sparire trecento pagine sbagliate ha appena perso l’unico elenco che gli diceva quali erano.

Bing e la sitemap

Bing usa la sitemap come inventario degli URL del sito per la ricerca AI-powered, e dichiara di tornarci in genere almeno una volta al giorno. Ignora changefreq e priority come Google, tratta lastmod come segnale chiave per decidere cosa riscansionare, e considera IndexNow complementare: uno notifica il singolo cambiamento URL per URL, l’altra garantisce che nessun URL resti fuori dal giro.

Sul versante Google un documento equivalente non c’è. La pagina che documenta le funzionalità AI della Ricerca, aggiornata al 10 dicembre 2025, non contiene la parola sitemap nel corpo del testo: le uniche occorrenze stanno nel menu laterale.

È assenza di documentazione, non una posizione contraria. Sul quadro più ampio ho scritto la guida alla SEO per AI e un pezzo su come si misura la visibilità nelle AI.

Come si crea la sitemap: CMS, framework o generatore

Nel 99% dei casi non la crei tu: la genera il CMS o il framework, e il tuo lavoro è controllare cosa ci mette dentro.

Il criterio sta in una domanda: il sito cambia da solo? Se le pagine nascono da un database o da un build, la sitemap deve nascere dalla stessa sorgente. Se è un pacchetto di file HTML che tocchi a mano tre volte l’anno, un file statico regge benissimo.

Un generatore online ha senso solo nel secondo caso: ti consegna una fotografia del sito, e quella fotografia invecchia a ogni pubblicazione mentre continua a rispondere 200 e a validare perfettamente.

WordPress: sitemap nativa o plugin

WordPress la genera già da solo. L’indice sta a /wp-sitemap.xml ed esiste di default sui siti pubblici dalla versione 5.5, di luglio 2020: lo racconta l’annuncio delle sitemap native di WordPress.

Il core mette 2.000 URL per file, modificabili con il filtro wp_sitemaps_max_urls, ed espone un indice che punta alle sitemap di post, pagine, custom post type, tassonomie e utenti. Dalla 6.5, marzo 2024, aggiunge lastmod ai singoli post e alla home.

Su tassonomie e utenti quel lastmod non c’è: la dev-note dice cosa è stato aggiunto, non cosa è rimasto fuori. Sull’indice di make.wordpress.org:

curl -s -o t.xml https://make.wordpress.org/core/wp-sitemap-taxonomies-category-1.xml
xmllint --xpath "count(//*[local-name()='url'])" t.xml       # 17
xmllint --xpath "count(//*[local-name()='lastmod'])" t.xml   # 0

Stesso esito sui tag (843 URL, zero lastmod) e sugli utenti (316 URL, zero lastmod). Il file dei post, per confronto, ne ha 2.000 su 2.000.

Il plugin serve per tre cose che il core non fa: escludere singoli contenuti senza scrivere codice, gestire le estensioni per immagini, video e news, esporre lastmod su tassonomie e utenti. Se non ti serve nessuna delle tre, stai installando un plugin per la sitemap che avevi già. Se lo installi, disattiva quella nativa:

add_filter( 'wp_sitemaps_enabled', '__return_false' );

Siti generati a build e cataloghi grandi

Se il sito si compila, la sitemap si compila con lui: si genera in build dalla stessa sorgente che genera le pagine, così non può divergere.

Vale per Next.js come per Hugo, per un headless con l’API di un CMS o per venti righe di script fatte in casa. Se la generi da una query diversa, o da un file mantenuto a mano di fianco, comincia a divergere e produce solo rumore: URL che non esistono più, pagine nuove che non ci sono ancora, e nessun modo di sapere quale delle due liste ha ragione.

Su un catalogo grande si divide per tipo di contenuto: prodotti, categorie, articoli, pagine statiche, tutte sotto un indice. I filtri restano fuori, insieme ai parametri di ordinamento e alla paginazione oltre la prima: cosa debba essere indicizzabile si decide sull’architettura, non alla fine sul file XML. Ne ho scritto nel pezzo sui filtri ecommerce e la SEO, dentro la guida alla SEO per ecommerce.

Siti grandi: il file indice

Sopra i 50.000 URL o i 50 MB non compressi spezzi il file in più sitemap e ne crei un indice. Poi invii solo l’indice.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://esempio.it/sitemap-articoli-1.xml</loc>
    <lastmod>2026-08-28</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://esempio.it/sitemap-prodotti-1.xml</loc>
    <lastmod>2026-08-27</lastmod>
  </sitemap>
</sitemapindex>

L’elemento radice è sitemapindex, il figlio è sitemap e non url, e dentro ogni sitemap l’URL sta in un loc.

Le regole di Google per i file indice sono quattro. Le sitemap referenziate devono stare sullo stesso sito e nella stessa directory dell’indice o più in basso, e il vincolo dello stesso sito decade solo se attivi la cross-submission.

Un indice arriva a 50.000 tag loc, e in Search Console puoi inviarne fino a 500 per sito. Un indice non può contenerne altri: il rapporto Sitemap ha un errore dedicato, «indici Sitemap nidificati».

Il gzip è ammesso, ma il tetto dei 50 MB si misura sul file decompresso: una sitemap da 60 MB che diventa 4 MB in gzip resta una sitemap da 60 MB.

Dividerla serve anche a misurare. In Search Console leggi il rendimento di ogni singola sitemap separatamente, e il rapporto Indicizzazione ti dice quanti prodotti sono indicizzati contro quante categorie. Con un file unico da 40.000 URL quel dato non lo ricostruisci a posteriori.

Immagini, video e hreflang

Immagini, video e hreflang si dichiarano come namespace sul tag urlset, e li puoi mettere in una sitemap dedicata o dentro quella che hai già: per Google le due strade valgono uguale.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:image="http://www.google.com/schemas/sitemap-image/1.1"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://esempio.it/scarpe/</loc>
    <image:image>
      <image:loc>https://esempio.it/img/scarpe.jpg</image:loc>
    </image:image>
    <xhtml:link rel="alternate" hreflang="it" href="https://esempio.it/scarpe/"/>
    <xhtml:link rel="alternate" hreflang="en" href="https://esempio.it/en/shoes/"/>
    <xhtml:link rel="alternate" hreflang="x-default" href="https://esempio.it/scarpe/"/>
  </url>
</urlset>

I namespace vanno copiati carattere per carattere. Per i video i tag obbligatori sono video:thumbnail_loc, video:title, video:description e uno fra video:content_loc e video:player_loc.

Sull’hreflang la regola che fa raddoppiare il file è questa: ogni versione linguistica ha il suo elemento url, e ognuno deve contenere un xhtml:link per ogni variante, inclusa se stessa. Quei figli però non ti mangiano il budget dei 50.000 URL, perché la pagina di Google sulle versioni localizzate scrive che «gli elementi secondari non vengono conteggiati per il limite di URL per le Sitemap».

Come validare la sitemap

Controlla che il file risponda 200, validalo contro lo schema ufficiale, poi guarda se dentro ci sono gli URL che pensi. Tutto da riga di comando, in meno di un minuto.

Il primo controllo è banale e viene saltato sempre. Il file deve rispondere 200 e servire XML, non una pagina di cortesia del tema:

curl -sI https://esempio.it/sitemap.xml -o /dev/null -w "%{http_code} %{content_type}\n"
# 200 text/xml

Il secondo usa gli XSD ufficiali del protocollo, che sono online e rispondono 200 (sitemap.xsd pesa 4.451 byte, siteindex.xsd 2.591). Serve xmllint, che su Linux sta nel pacchetto libxml2-utils e su macOS c’è già:

curl -s -O https://www.sitemaps.org/schemas/sitemap/0.9/sitemap.xsd
curl -s -o sitemap.xml https://esempio.it/sitemap.xml
xmllint --noout --schema sitemap.xsd sitemap.xml
# sitemap.xml validates

Se stai controllando un file indice cambia lo schema, perché l’elemento radice è un altro:

curl -s -O https://www.sitemaps.org/schemas/sitemap/0.9/siteindex.xsd
xmllint --noout --schema siteindex.xsd sitemap_index.xml

Il terzo conta gli URL e li tira fuori in un file di testo:

xmllint --xpath "count(//*[local-name()='url'])" sitemap.xml
grep -oE '<loc>[^<]+' sitemap.xml | sed 's|<loc>||' > url.txt
wc -l url.txt

In giro trovi l’estrazione fatta con xmllint --xpath "//loc/text()", ma quella riga dipende dalla versione di libxml2: su alcune stampa un nodo per riga, su altre te li incolla tutti insieme. grep e sed funzionano ovunque, anche quando la sitemap è tutta su una riga sola, che è come la serve WordPress. Versione di riferimento: xmllint 2.9.14, sulla sitemap di sitemaps.org e sull’indice di make.wordpress.org.

Una cosa che ti farà spaventare a torto: se nella sitemap hai le estensioni, la validazione contro sitemap.xsd fallisce, e non è colpa tua. Lo schema usa un wildcard strict e non conosce i tag di Google, quindi su un file con image:image o xhtml:link restituisce No matching global element declaration available, but demanded by the strict wildcard. Il file è corretto, lo schema è più vecchio delle estensioni.

E soprattutto: tutto questo controlla la sintassi e nient’altro.

Quello che un validatore non vede

Un file perfettamente valido può essere completamente inutile. Lo schema non sa se quegli URL rispondono 200, se sono canonici, se sono in noindex o se il robots.txt li blocca.

Il controllo che conta si fa sulla lista di URL. Prima gli status code:

while read -r u; do
  echo -n "$u "
  curl -s -o /dev/null -w "%{http_code}\n" -I "$u"
done < url.txt

Quello che cerchi lo vedi subito: i 404 di pagine cancellate che il CMS non ha tolto dall’elenco, i 301 verso la versione con lo slash finale. Ogni riga che non è 200 è un URL che stai indicando a un motore come pagina da mostrare in Ricerca.

Poi i controlli di merito. Ogni URL elencato deve essere canonico di se stesso: se la pagina dichiara un rel=canonical verso un altro indirizzo, in sitemap ci va quell’altro. Nessuno deve avere noindex, né essere bloccato dal robots.txt.

Per il caso singolo lo strumento è Controllo URL in Search Console, che ti dice anche quale canonical ha scelto Google, e non sempre è quello che hai dichiarato. Per il confronto su tutta la lista serve un crawler, ed è l’unico controllo che qui non ti do come comando.

Gli errori del rapporto Sitemap

Gli errori ricadono in tre famiglie: non riesco a prendere il file, non riesco a leggerlo, il file dichiara URL che non gli competono.

• Impossibile recuperare. Le cause documentate sono quattro: il robots.txt blocca il percorso, l’URL risponde 404 o un altro errore HTTP, il server non ha risposto, oppure c’è un’azione manuale non risolta. Si parte sempre dal robots.txt, la causa più stupida e la più comune.
• Errore di analisi. Quasi sempre una & non escapata dentro un URL con parametri.
• Spazio dei nomi non corretto. Il namespace è scritto male. Fra le cause Google elenca anche le virgolette curve che ci infila un word processor.
• URL non consentito. La sitemap contiene URL a un livello più alto o su un dominio diverso rispetto al file.
• Manca (o include) il prefisso www. La sitemap sta su esempio.it e dentro elenca URL su www.esempio.it, o viceversa. Sono due host, e vale anche se mescoli http e https.
• Sitemap vuota, Errore dimensioni file, Errore di compressione. Il file non contiene URL, supera i 50 MB decompresso, o il gzip è malformato.

Cosa non mettere in sitemap

In sitemap ci va quello che vuoi vedere nei risultati di ricerca, nella sua forma canonica. Tutto il resto contraddice gli altri segnali che stai mandando.

Da lì discende la lista, e il motivo è sempre lo stesso. Fuori le pagine in noindex. Fuori gli URL non canonici, perché ci va la destinazione del rel=canonical. Fuori i redirect: di un 301 metti in elenco l’indirizzo di arrivo. Fuori i 4xx e i 5xx. Fuori la paginazione oltre la prima, la ricerca interna, i carrelli, il login, i parametri di ordinamento e le combinazioni di facet.

Il punto è la coerenza fra quattro cose che il motore legge insieme: sitemap, rel=canonical, robots.txt e meta robots. Un URL in sitemap con noindex in pagina è una contraddizione che hai dichiarato tu, con le tue mani, in due file che il crawler apre entrambi. Il motore non si blocca: sceglie, e non è detto che scelga come volevi.

Ultima, la più antipatica: la sitemap non è un archivio. Se una pagina non c’è più, va tolta dall’elenco.

Domande frequenti