Errori della sitemap XML che sembrano inspiegabili

Parte del mio lavoro consiste nel guardare i siti web altrui, e con essi le loro sitemap; e la scena si ripete sempre identica: il file con la sitemap XML si apre nel browser — ogni URL è lì, in bella vista — eppure Search Console la dichiara non valida, o sostiene di non poterlo recuperare. Ciò che manda spesso in confusione è quello che appare sullo schermo e quello che il parser legge, perché i due stanno leggendo documenti completamente diversi.

La regola su cui baso ogni audit: non fidarsi mai di come una sitemap appare nel browser. Un elenco di URL non è di per sé un errore — una sitemap puo' essere restituita / creata anche in formato testo. Ma nemmeno un elenco ordinato e colorato è garanzia di correttezza: l'avere un foglio di stile applicato ad un documento XML non vuole dire che tutto sia corretto. Il nocciolo della questione è che quello che il browser rappresenta sull schermo dipende dal Content-Type, ma sopratutto dipende anche dal browser che viene utilizzato (per inciso Chrome non si comporta allo stesso modo di Firefox), quindi la sua rappresentazione non è un verdetto. È il testimone meno affidabile della pagina, ed è per questo che nessuno dei controlli qui sotto si concentra sul metodo di rappresentazione.

Una sitemap valida servita come text/html anziché come XML — il browser la appiattisce in un nudo elenco di URL <loc>, e gli alternate hreflang, che vivono negli attributi, non vengono renderizzati.

Perché ciò che mostra il browser non prova nulla

Un browser decide come leggere un documento a partire dal suo Content-Type — ma il modo in cui il file viene visualizzato è un compito del browser, e i risultati sono i più disparati. Una sitemap essenziale, con soli elementi <loc>, ottiene un albero formattato in Chrome e un elenco spoglio di URL in Firefox. Aggiungi gli alternate hreflang — le righe <xhtml:link> che rendono multilingua una sitemap — e persino Chrome rinuncia all'albero e mostra la stessa sfilza di URL; la dichiarazione del namespace non fa differenza. Servi il file come text/html e in ogni browser ottieni lo stesso muro di URL. Stesso file valido, e ciò che appare dipende dal browser e da cosa contiene.

Solo quest'ultimo caso è davvero un errore. Servita come text/html, il browser smette del tutto di trattare i byte come XML e li interpreta come una pagina web: <urlset>, <url>, <loc> e <xhtml:link> diventano elementi sconosciuti, privi di regole di rendering, e sopravvive soltanto il testo che sta fra di essi. Il punto è che si arriva esattamente allo stesso elenco spoglio prodotto da una sitemap multilingua valida — quindi l'aspetto da solo non distingue un file rotto da uno sano.

Nemmeno gli alternate hreflang sono un indizio utile. Sarebbero leggibili solo in una vista ad albero, mostrati come sorgente — ma è proprio la loro presenza ad ingannare il browser e portarlo a mostrare quella distesa di URL. Una sitemap multilingua, quindi, non mostra i propri alternate in nessun browser, valida o rotta che sia: la loro assenza dallo schermo è la norma, non un sintomo.

Ciò che determina davvero se Google accetta il file è il Content-Type, non l'immagine a schermo. Servita come text/html — spesso perché un redirect o una regola di rewrite ha perso per strada l'estensione .xml — la sitemap non viene più letta come XML, ed è questo il vero errore. È il controllo del passo 2 a intercettarlo.

Quindi, prima di toccare il file, di seguito la sequenza di comandi per verificare dall'inizio alla fine cosa potrebbe essere andato storto. Ogni passo è un comando curl mirato a risolvere un problema specifico.

1. Controlla i primi byte: BOM o spazzatura iniziale

La dichiarazione <?xml deve essere il primissimo byte del file. Un Byte Order Mark (BOM) UTF-8 o uno spazio bianco è il motivo più comune per cui una sitemap altrimenti valida viene rifiutata.

curl -s https://example.com/sitemap.xml | head -c 64 | xxd

Esito atteso: l'output inizia con 3c3f 786d 6c — cioè <?xml in esadecimale.

Segnale d'allarme: efbb bf prima di <?xml — è un BOM UTF-8. Rimuovilo. Qualsiasi cosa diversa da <?xml al byte zero (per esempio 4854 5450 = HTTP, segno che stai guardando la cosa sbagliata, magari il dump di una risposta salvata in precedenza.

Ispeziona sempre l'URL live, non una copia scaricata. Un salvataggio maldestro può aggiungere byte che sul server non ci sono.

2. Verifica il Content-Type

Google ha bisogno che la sitemap sia servita come XML. Se il server invia text/html, il crawler può tentare di interpretarla come una pagina web e rifiutarla.

curl -sI https://example.com/sitemap.xml | grep -i content-type

Esito atteso: content-type: application/xml (oppure text/xml).

Segnale d'allarme: text/html. Di solito accade quando la sitemap è servita attraverso un redirect/rewrite o da un percorso senza estensione .xml. La soluzione dipende dall'hosting — imposta l'intestazione Content-Type del percorso della sitemap su application/xml; charset=utf-8.

L'intestazione che decide tutto: application/xml viene interpretata come XML, text/html come pagina web — ed è la seconda a far collassare il file.

Ecco un caso reale, senza artifici locali: interno.gov.it/sitemap.xml. Risponde 200 OK con Content-Type: text/html e restituisce una normalissima pagina web — di fatto la home page del Ministero. Perfetta per una persona; inutile per un crawler a cui era stato promesso XML e che si ritrova una pagina.

Un sito reale e autorevole: interno.gov.it/sitemap.xml serve una pagina HTML, non XML. È lo stesso tipo di disallineamento dell'elenco spoglio qui sopra — text/html dove dovrebbe esserci application/xml — solo travestito da pagina intera anziché da nudo muro di URL.

3. Verifica che l'URL risponda davvero 200

Una sitemap dietro un redirect, un soft 404 o un processo di autenticazione fallirà indipendentemente dal suo contenuto.

curl -sI https://example.com/sitemap.xml | head -n 1

Esito atteso: HTTP/2 200.

Segnale d'allarme: 301/302 (redirect — invia l'URL finale), 404 o 403.

Un sitemap.xml che risponde con una pagina 404 si carica nel browser, ma l'assenza di XML rende il file inutilizzabile per lo scopo in questione.

4. Valida l'intero file come XML

Una prima riga pulita non garantisce che il resto sia ben formato. Reindirizza la risposta al comando xmllint. Il - finale gli dice di leggere dalla pipe invece che da un file.

curl -s https://example.com/sitemap.xml | xmllint --noout -

Esito atteso: nulla. Il silenzio significa XML valido e ben formato.

Segnale d'allarme: una riga tipo -:42: parser error : ... che ti indica riga e colonna esatte. I colpevoli abituali:

• Una e commerciale non sottoposta a escape — & va scritto & dentro un URL.
• Un tag non chiuso o non corrispondente.
• Un namespace errato su <urlset>.

Vuoi leggerla formattata già che ci sei? Sostituisci --noout con --format:

curl -s https://example.com/sitemap.xml | xmllint --format -

5. Controlla cosa vede Googlebot, non cosa vede il browser

Un file richiesto dal browser potrebbe restutuire un file in cache (CDN), o saltare eventuali fasi di autenticazione (che non dovrebbero esistere, ma tant'è). Specificare uno user-agent, con uno che emula un bot ad esempio — può restituire qualcosa di completamente diverso.

curl -s -A "Googlebot" https://example.com/sitemap.xml | xmllint --noout -

Esito atteso: silenzio, come al passo 4.

Segnale d'allarme: un errore qui, quando il passo 4 era pulito, significa che il percorso per i bot differisce da quello umano — ed è quello il bug da inseguire.

Lo stesso URL, due user-agent, due risposte diverse. Quando il percorso del bot diverge da quello umano in questo modo, la sitemap che hai testato a mano non è quella che viene servita a Google.

6. Assicurati che ogni <loc> corrisponda alla proprietà verificata

GSC segnala gli URL che non appartengono esattamente alla proprietà — protocollo errato (http invece di https), host errato (www contro dominio nudo, o un dominio del tutto diverso). Si legge come "non valida", ma è un disallineamento di host, non un errore strutturale.

curl -s https://example.com/sitemap.xml | grep -oP '(?<=<loc>)[^<]+' | sed -E 's#(https?://[^/]+).*#\1#' | sort -u

Esito atteso: una sola riga, esattamente corrispondente alla tua proprietà GSC (per esempio https://www.example.com).

Segnale d'allarme: più di un host, o un host che non corrisponde alla proprietà sotto cui hai inviato la sitemap.

7. Verifica che le date lastmod siano valide

Una data malformata può invalidare il file e, da quando Google ha deprecato l'endpoint di ping delle sitemap nel 2023, un lastmod accurato è ormai il segnale principale che comunica a Google che vale la pena ri-scansionare una sitemap.

curl -s https://example.com/sitemap.xml | grep -oP '(?<=<lastmod>)[^<]+' | head

Esito atteso: date valide W3C / ISO 8601 — 2026-06-13 oppure 2026-06-13T17:37:13+00:00.

Segnale d'allarme: qualsiasi altra cosa — 13/06/2026, 13 giugno 2026, tag vuoti.

Se tutti i controlli passano

Allora il file è davvero a posto, e l'"errore" è quasi certamente uno stato obsoleto in Search Console — un residuo di quando la sitemap era effettivamente rotta. La verità scomoda: quello stato non puoi cancellarlo. Google mantiene una propria copia in cache e ri-scansiona secondo i propri tempi — non esiste un pulsante per svuotarla. Tutto ciò che puoi fare è inviare segnali e aspettare:

1. Rimuovi e re-inserisci la sitemap nel rapporto Sitemap — la spinta più forte, ma pur sempre una spinta, e la nuova lettura può richiedere giorni.
2. Assicurati di usare il lastmod. Con l'endpoint per i ping sparito nel 2023, questo è rimasto il solo segnale stabile che indica che vale la pena ri-scansionare il file.
3. Controllo URL → Richiedi indicizzazione sull'URL della sitemap, per mettere in coda una lettura del file. Un hack piu che una soluzione.

Ultima risorsa — la soluzione di ripiego sicura. Se proprio la situazione non si smuove, smetti di combattere con l'URL "avvelenato" e abbandonalo: rinomina la sitemap con un nome che Google non ha mai visto (sitemap-v2.xml), fai puntare robots.txt al nuovo nome e invia quella. Un URL nuovo non porta con sé alcuno storico di errori, quindi non c'è nulla di obsoleto da aspettare — aggiri del tutto la cache invece di attenderne la scadenza, e la vecchia sitemap prima o poi verra' eliminata da sola. È un'operazione sicura: Google indicizza gli URL dentro la sitemap, non il nome del file, quindi rinominarlo non costa nulla.

La versione in una riga

Eseguili nell'ordine; il primo che si comporta male è la causa dei tuoi mali:

curl -s   https://example.com/sitemap.xml | head -c 64 | xxd        # BOM / primi byte
curl -sI  https://example.com/sitemap.xml | grep -i content-type    # Content-Type
curl -sI  https://example.com/sitemap.xml | head -n 1               # stato 200
curl -s   https://example.com/sitemap.xml | xmllint --noout -       # validità XML
curl -s -A Googlebot https://example.com/sitemap.xml | xmllint --noout -  # prospettiva del bot

Se tutti e cinque i test passano, smetti di toccare il file — la colpa non è più nelle tue mani.