Molto spesso mi sono scontrato con siti Web che, nel momento della progettazione, avevano dato poca importanza alla Sitemap XML. In taluni casi, quelle poche volte che mi sono ritrovato a ottimizzare siti su WordPress, la sitemap viene generata attraverso qualche plugin e poco ci si interessa di cosa ci finisce dentro (generare le sitemap con plugin va benissimo, l’importante è avere il controllo delle stesse); in altri casi, soprattutto quando il sito è custom, la sitemap manca proprio oppure presenta vari errori.
Quando arriva la richiesta di sviluppare la sitemap, il programmatore tipo tira fuori la lista delle URL con i parametri fondamentali, quindi, in buona sostanza, solo con la lista di “loc“, e presenta la lista di URL presenti sul sito. In tale condizione la sitemap è come non averla, tanto vale non sprecare nemmeno quel po’ di tempo.
Premessa: all’interno dell’articolo ci saranno dei concetti che sono stati fortemente semplificati per poter essere adatti alla lettura di tutti. Ovviamente le logiche con cui lavora lo spider di Google sono molto più complesse di come vengono qui esposte. Ai fini dell’articolo, comunque, l’importante non è comprendere i concetti tecnici approfonditamente, ma spiegare per quale ragione è importante fare determinate scelte e perché è importante ottimizzare le sitemap del sito.
A cosa serve la Sitemap XML per un sito Web?
Partiamo quindi dalla domanda principale: perché diavolo bisogna sviluppare, e dare in pasto ai motori di ricerca, una sitemap XML? La risposta è abbastanza semplice: in modo tale che lo spider del motore di ricerca conosca più velocemente tutte le URL del sito.
Questa risposta però apre vari interrogativi e obiezioni; l’obiezione tipo è “Google conosce già le URL del sito”. Vero… ma Google per scoprire le URL dovrà gioco forza andare a spiderizzare tutte le pagine del sito, facendo il refresh di URL che non hanno cambiato il contenuto. In un mondo di risorse infinite questo non sarebbe un problema, ma Google ha risorse finite e cerca di ottimizzarle al massimo per evitare sprechi. Obbligandolo quindi a scansionare (ogni x tempo) tutte le URL del sito, quindi, porterà il motore di ricerca a non essere così felice e quindi il peso del sito Web ne subirà le conseguenze.
Allora come fare per evitare che Google debba scansionare tutto il sito Web continuamente alla ricerca di nuove pagine? Semplice: attraverso la sitemap.
Come costruire una sitemap XML perfetta per il SEO?
Quindi, posto che vogliamo far fare a Google solo il lavoro necessario, così che sia ben contento di analizzare il nostro sito, la domanda è “come fare a costruire una sitemap perfetta per il SEO?“.
Per dare risposta a questa domanda ci viene in aiuto l’ente che ha creato lo standard delle sitemap, cioè Schema.org attraverso il ramo sitemaps.org (standard adottato da Google, Inc., Yahoo Inc. e Microsoft Corporation), come si può leggere dai Terms and Conditions del sito stesso.
Secondo sitemaps.org, quindi, per creare una sitemap bisogna necessariamente:
- Iniziare con il tag <urlset> e terminare con </urlset>
- All’interno di <urlset> specificare il namespace (protocollo standard)
- Per ogni pagina che vogliamo segnalare includere un tag genitore <url>
- All’interno di ogni tag <url> aggiungere un child <loc>
Queste sono le indicazioni perché una sitemap sia valida, si tratta del minimo indispensabile ma, come abbiamo già visto, semplicemente creando una sitemap del genere non avremo risolto il vero scopo che i motori di ricerca hanno cercato di seguire creando tale standard.
I valori opzionali ma fortemente consigliati per una sitemap XML
Oltre ai tag suddetti, quindi, è molto importante inserire altri 2/3 indicazioni che rendono la sitemap veramente adatta allo scopo. Vediamo quali sono:
- lastmod: si tratta del parametro più importante e deve indicare la data (e possibilmente l’ora, ma basta anche solo la data) di quando l’URL è realmente cambiata (o di quando è stata creata); benché si tratti di un parametro opzionale, una sitemap senza lastmod ha poco senso di vita.
- priority: in termini di importanza è il secondo parametro e indica una preferenza di priorità. In caso di omissione tutte le URL avranno priorità 0.5, qualora lo volessimo indicare dovremo usare valori tra 0.0 e 1.0
- changefreq: tra i parametri opzionali è probabilmente quello meno importante, indica approssimativamente ogni quanto cambia la pagina e i valori accettati sono:
- always
- hourly
- daily
- weekly
- monthly
- yearly
- never
LastMod
Partiamo quindi con il parametro più importante, cioè LastMod e introduciamo il concetto di crawl budget.
Crawl Budget
Ogni sito Web riceve da Google un budget di crawling, cioè una quota di risorse per scansionare le pagine. Diciamo, per esempio, che un sito ha un migliaio di pagine indicizzate, le quali cambiano spesso e pesano ognuna 50KB (tra pagina stessa e risorse); in base ai link in ingresso, all’argomento e a un’altra infinità di variabili, Google può decidere di assegnare, a tale sito, un ammontare totale mensile di risorse (per esempio e per semplificare di molto): 10 minuti di scansione; 20MB di banda.
Significa che di base, con il peso medio di 50KB lo spider di Google guarderà al massimo 400 pagine e queste, sommate, dovranno stare nei 10 minuti, con il risultato di assegnare, mediamente, a ogni pagina un tempo medio di 1,5 secondi (600 secondi mensili, diviso le 400 pagine).
Se il peso delle pagine scende a 40KB medio, le pagine diventeranno 500; qualora una pagina risponde molto più velocemente, arriva un “bonus” con la scansione di qualche pagina in più.
Questa è una semplificazione molto estrema (non calcolate sul vostro sito perché non ha molto senso), ma ci è utile per comprendere come Google non avrà tempo/risorse per guardare le nostre 1.000 pagine ogni mese. E se queste pagine cambiano 4 volte al mese, avremo 4.000 URL da refreshare, contro un budget di 400 pagine.
Come vediamo quindi dal Crawl Budget, Google ogni x tempo (nell’esempio semplificato abbiamo preso un mese di riferimento) assegna delle risorse e scansiona un numero X di nostre pagine Web. Se non indichiamo il LastMod Google non avrà idea di quale pagina è stata aggiornata, con il risultato che sicuramente vedrà le nuove, ma probabilmente sprecherà risorse a guardare pagine che non hanno cambiato una virgola, senza aggiornare pagine che in realtà sono cambiate.
LastMod, quindi, è un parametro fondamentale per ottimizzare il crawl budget ed evitare che lo spider perda tempo su pagine che sono immobili da mesi.
Priority
Proseguendo nel nostro esempio, quindi, diciamo per esempio che il nostro sito ha un totale di 4.000 pagine aggiornate e Google ci dà un budget per sole 400. Posto che con il LastMod abbiamo evitato di far sprecare risorse su pagine ferme, come facciamo a indicare quali pagine deve necessariamente controllare e quali può lasciare per un secondo momento?
Ci viene in aiuto priority, con il quale indichiamo quali pagine sono per noi più importanti. Anche qui, semplificando, diciamo di avere:
- 100 pagine aggiornate con priority 0.9
- 300 pagine aggiornate con priority 0.8
- 500 pagine aggiornate con priority 0.7
- e così via
Ecco, la risposta è già tutta qui in questo elenco: Google, a fronte di 400 pagine di budget, guarderà (semplificando anche qui di molto) prima le pagine da 0.9, dopo quelle da 0.8 e tralascerà quelle meno importanti.
ChangeFreq
Finiamo con l’ultimo parametro, cioè quello meno importante tra tutti, cioè il ChangeFreq, continuando con il nostro esempio, andiamo a concentrarci un po’ più nel dettaglio. Quindi, una pagina (/paginaX) ha:
- LastMod a 15 giorni fa
- Priority: 0.9
- ChangeFreq: monthly
Quindi, potenzialmente, due settimane fa lo spider ha già guardato quella pagina (/paginaX) e non è ancora passato il mese di frequenza che abbiamo indicato. Inoltre, tra le 500 pagine con priority 0.7 ne ha una (/paginaY) con:
- LastMod a 12 giorni fa
- priority: 0.7
- changefreq: weekly
In tal caso, considerando che Google assegna sempre un po’ di budget per guardare vecchie pagine, quale delle due sceglierà? Certamente la seconda (/paginaY), perché è pur vero che la priority è più bassa e la pagina è stata vista più di recente, ma il ritmo di frequenza che abbiamo indicato sulla seconda (weekly) è già superato dall’ultima modifica, mentre per la prima ancora siamo nei 30 giorni di frequenza indicata; quindi Google “sprecherà” un po’ di risorse per fare un aggiornamento di una pagina che, altrimenti, rischia di non guardare mai più. Magari domani (o tra qualche giorno) guarderà la prima (/paginaX).
Struttura di una Sitemap XML
A questo punto non ci rimane che indicare uno snippet di una sitemap che, in questo caso, ha un paio di URL indicate (se vi serve un SEO dovete usare la seconda URL).
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://www.seot.it/</loc>
<lastmod>2022-01-28</lastmod>
<changefreq>weekly</changefreq>
<priority>0.9</priority>
</url>
<url>
<loc>https://www.seot.it/contatti/</loc>
<lastmod>2022-01-25</lastmod>
<changefreq>yearly</changefreq>
<priority>0.5</priority>
</url>
</urlset>Ricordiamo inoltre che in ogni sitemap possono confluire un massimo di 50 mila URL.
Sitemap Index per un sito complesso
E se il nostro sito supera le 50 mila URL di limite per una sitemap? In tal caso possiamo creare 2, 3, 4, infinite sitemap e inserirle in una sitemap index.
Una sitemap index altro non è che una sitemap di sitemap. Immaginiamo per esempio un sito editoriale, molto grande, che pubblica ogni giorno centinaia di nuove URL, in tal caso il limite dei 50 mila URL per sitemap rischia di essere raggiunto velocemente.
In tal caso si può creare, per esempio, una sitemap index che contiene una sitemap per ogni mese da quando il quotidiano esiste. Quindi avremo, per esempio: /sitemap/index.xml che a sua volta contiene:
- /sitemap/2020/01.xml
- /sitemap/2020/02.xml
- ecc
In un mese si producono più di 50 mila URL? Chi ci impedisce di farla settimanale? Altrimenti si andrà a riempimento: tutte le news con id tra 0 e 50 mila andranno nella prima, da 50 mila a 100 mila nella seconda, e così via.
Conclusioni
Per concludere l’articolo, possiamo dire che (almeno) una sitemap dovrebbe essere presente in ogni sito; tale sitemap dovrebbe avere tutti i parametri correttamente impostati, senza provare a fare i “furbetti” poiché, qualora la sitemap non fosse aderente alla realtà, Google potrà decidere di ignorarla e noi avremo perso tempo, lavoro e un’opportunità.
Bisogna strutturare bene le sitemap, senza esagerare con le sitemap index poiché anche le sitemap vanno a incidere sulle risorse assegnate da Google. Quindi da evitare assolutamente di fare 50 mila sitemap, ognuna con una sola URL reale.
Infine le sitemap (o la sitemap index) devono essere indicate su Google Search Console, nell’apposita sezione e, se non contengono informazioni riservate (per esempio la lista di pagine dei clienti), anche inserite nel file robots.txt con la seguente indicazione:
Sitemap: https://www.seot.it/sitemap_index.xml