Una sitemap XML elenca gli URL di un sito per guidare i robot di esplorazione dei motori di ricerca. Il suo ruolo sembra semplice, ma la qualità di questo file influisce direttamente sulla velocità e sulla completezza dell’indicizzazione. Quali differenze di pratica separano una sitemap correttamente mantenuta da un file generato per impostazione predefinita e mai auditato?
Tag della sitemap XML: cosa sfruttano realmente i crawler
La maggior parte dei CMS genera automaticamente una sitemap, con quattro tag per URL. Non tutti hanno lo stesso peso per Google.
Vedi anche : Come creare con successo il tuo sito web professionale con Cyber Vista
| Tag | Ruolo dichiarato | Trattamento da parte di Google |
|---|---|---|
| <loc> | URL completo della pagina | Unico tag obbligatorio, utilizzato sistematicamente da Googlebot |
| <lastmod> | Data di ultima modifica | Considerato solo se la data riflette un cambiamento reale del contenuto |
| <changefreq> | Frequenza stimata di modifica | Ignorato da Google da diversi anni |
| <priority> | Priorità relativa tra le pagine del sito | Ignorato da Google |
Due tag su quattro sono quindi senza effetto sull’indicizzazione di Google. Mantenere questi tag non presenta problemi tecnici, ma solo <loc> e <lastmod> meritano un’attenzione reale.
Su la pagina principale di Essentium, si osserva una sitemap segmentata che illustra questa logica di ordinamento per tipo di contenuto, un formato che facilita la diagnosi in Google Search Console.
Da scoprire anche : Scopri come navigare facilmente grazie alla mappa del sito di Citizens News
Lastmod affidabile o lastmod decorativo: la differenza che cambia l’indicizzazione
Il tag <lastmod> è spesso frainteso. Molti siti lo aggiornano automaticamente ad ogni rigenerazione della sitemap, anche senza modifiche al contenuto della pagina. Questa pratica rende il segnale inutile.
Google tratta <lastmod> come un segnale di freschezza a condizione che la data sia onesta. Una pagina il cui testo, immagini o dati strutturati non sono cambiati non deve ricevere una nuova data.
La questione è concreta: quando Googlebot rileva date <lastmod> sistematicamente recenti senza cambiamenti reali, finisce per ignorare questo tag per l’intero sito. La sitemap perde quindi la sua capacità di segnalare gli aggiornamenti reali, quelli che giustificano un nuovo crawl veloce.
- Aggiornare <lastmod> solo dopo una modifica sostanziale del contenuto (testo rielaborato, nuovo paragrafo, media aggiunto)
- Non confondere aggiornamento tecnico (cambio di template, aggiunta di uno script) e aggiornamento di contenuto
- Auditare regolarmente la coerenza tra le date <lastmod> e le date di modifica reali delle pagine
Un sito che rispetta questa disciplina fornisce a Googlebot un segnale sfruttabile. Al contrario, un sito che aggiorna tutte le sue date ogni settimana senza motivo invia rumore.
Segmentare la propria sitemap XML per tipo di contenuto
Un file unico che elenca tutti gli URL funziona per un piccolo sito. Oltre alcune centinaia di pagine, la segmentazione per famiglia di URL diventa un leva di gestione.
Il principio consiste nel creare più file sitemap raggruppati in un indice (sitemap index): un file per le pagine statiche, uno per gli articoli del blog, uno per le schede prodotto, uno per le immagini, uno per i video. Ogni file è dichiarato in un sitemap index referenziato dal robots.txt.
L’interesse non si limita all’organizzazione. In Google Search Console, la copertura di indicizzazione può essere filtrata per sitemap inviata. Se un file dedicato alle schede prodotto mostra un tasso di indicizzazione anormalmente basso, la diagnosi è immediata: il problema si trova su questa famiglia di URL, non altrove.
Questo approccio consente anche di identificare rapidamente gli URL orfani o i contenuti che il CMS ha generato senza supervisione (pagine di tag, archivi per data, URL parametrizzate).
URL canoniche e pagine escluse: pulire la sitemap per indicizzare meglio
Una sitemap XML inquinata da URL non indicizzabili spreca il budget di crawl. Ogni URL della sitemap deve restituire uno stato 200 ed essere canonica.
Le URL da escludere sistematicamente:
- Pagine in reindirizzamento 301 o 302 (l’URL di destinazione è sufficiente)
- Pagine con un tag
noindex(contraddizione diretta con la presenza nella sitemap) - URL parametrizzate che duplicano un contenuto esistente (filtri, ordinamenti, paginazioni non canoniche)
- Pagine di basso valore generate automaticamente (archivi per data, pagine di tag vuote)
Google lo precisa nella sua documentazione: una sitemap deve contenere solo URL che il sito desidera vedere indicizzati. Includere URL bloccate o reindirizzate non impedisce l’indicizzazione delle buone pagine, ma confonde i segnali inviati ai crawler e complica il monitoraggio in Search Console.
Un audit trimestrale della sitemap, incrociato con i rapporti di copertura, consente di rilevare le incoerenze prima che si accumulino. Gli strumenti di crawl riproducono il percorso di Googlebot e segnalano le differenze tra la sitemap dichiarata e lo stato reale degli URL.
Inviare e dichiarare la sitemap XML ai motori di ricerca
Generare una sitemap pulita non è sufficiente. Deve essere dichiarata affinché i motori la trovino senza dipendere dal linking interno.
Due metodi di dichiarazione coesistono. Il primo passa attraverso il file robots.txt, dove una riga Sitemap: https://example.com/sitemap.xml indica la posizione del file a qualsiasi robot che consulta il robots.txt. Il secondo passa attraverso la sottomissione diretta in Google Search Console o Bing Webmaster Tools, il che consente inoltre di monitorare gli errori di elaborazione.
Dichiarare la sitemap nel robots.txt e in Search Console rimane la combinazione raccomandata. Il robots.txt copre tutti i motori, mentre Search Console offre un feedback dettagliato sugli URL scoperti, indicizzati o esclusi.
Dopo ogni aggiornamento importante del sito (migrazione, rifacimento della struttura, aggiunta massiccia di pagine), una nuova sottomissione in Search Console accelera la considerazione delle modifiche.
La sitemap XML non migliora il posizionamento di una pagina. Garantisce che le pagine meritevoli di essere indicizzate siano effettivamente scoperte, in un tempo ragionevole, con metadati affidabili. La differenza si gioca nella rigorosità della manutenzione, non nella semplice esistenza del file.