Un sitemap non serve a far scoprire un sito ai motori di ricerca. Serve a indicare loro cosa esplorare in priorità, e soprattutto cosa non esplorare. Questa distinzione cambia radicalmente il modo in cui si costruisce e si mantiene il file.
Sitemap XML e gestione del budget di crawl: l’angolo che le guide omettono
Su un sito di alcune decine di pagine, il sitemap XML rimane un comfort. Su un sito che supera diverse migliaia di URL, diventa un leva diretta per ridurre lo spreco di crawl. Analisi recenti dei log mostrano che una parte significativa del budget di esplorazione di Google può essere consumata da URL fuori struttura: pagine di filtri, varianti di parametri, vecchie paginazioni o pagine orfane.
Il sitemap agisce qui come un filtro dichiarativo. Elencando solo URL canonici, indicizzabili e realmente utili, segnaliamo ai robot cosa merita il loro tempo. Al contrario, un sitemap che elenca redirezioni 301, soft 404 o URL bloccate dal robots.txt spinge Googlebot a spendere il suo budget nel modo sbagliato.
Consigliamo di incrociare sistematicamente il contenuto del sitemap con i log del server. Se URL presenti nel file non vengono mai crawlati, o se Googlebot esplora massicciamente URL assenti dal sitemap, il file è disallineato dalla realtà del sito. È su il sito Tekniko che troviamo un approccio strutturato a questa coerenza tra sitemap e architettura reale.
Perché i sitemaps gonfiati danneggiano l’indicizzazione
Un sitemap contenente migliaia di URL non indicizzabili invia un segnale contraddittorio. Google interpreta il file come un elenco di pagine che il webmaster ritiene meritevoli di indicizzazione. Se la metà restituisce codici 3xx, 4xx o tag noindex, l’affidabilità del file diminuisce.
Googlebot riduce quindi la frequenza di consultazione del sitemap stesso. Le nuove URL aggiunte impiegano più tempo per essere scoperte. L’effetto è misurabile nel rapporto di copertura della Search Console: un divario crescente tra URL inviate e URL indicizzate segnala quasi sempre un problema di qualità del file, non un problema di contenuto.
Tag lastmod nel sitemap: quando la freschezza diventa una trappola
Il tag lastmod è il più mal utilizzato delle metadati del sitemap XML. La sua funzione è semplice: indicare la data dell’ultima modifica sostanziale di una pagina. In pratica, la maggior parte dei CMS lo aggiorna ad ogni salvataggio, anche per una virgola corretta o un widget modificato nella sidebar.
Google ha esplicitamente inasprito la sua posizione su questo punto. Valori lastmod aggiornati senza reale cambiamento di contenuto portano i robot a ignorare questo tag per l’intero sitemap. Il file perde quindi la sua capacità di segnalare i veri aggiornamenti, il che rallenta la reindicizzazione delle pagine realmente modificate.
Come utilizzare lastmod in modo affidabile
- Attivare l’aggiornamento di lastmod solo in caso di cambiamento di contenuto principale (testo, media, dati strutturati), mai per modifiche di template o di menu
- Confrontare le date lastmod del sitemap con le date di modifica reali nel database e correggere le discrepanze tramite uno script o un hook CMS
- Eliminare completamente lastmod se il sito non può garantire la sua affidabilità, piuttosto che lasciare date artificiali
Un sitemap senza lastmod rimane utilizzabile. Un sitemap con lastmod ingannevoli diventa controproducente.
Sitemaps specializzati: video, immagini e notizie
Il sitemap XML classico copre le pagine HTML. Per i contenuti ricchi, estensioni specifiche del protocollo sitemaps.org consentono di dichiarare metadati aggiuntivi che Google non può sempre estrarre dal solo HTML.
Il sitemap video rimane pertinente per i siti che ospitano i propri file. Permette di dichiarare titolo, descrizione, durata, URL della miniatura e URL del file video. Senza questi metadati, Google dipende esclusivamente dal markup Schema sulla pagina, che è spesso incompleto o assente.
Il sitemap immagini porta un guadagno solo quando i visual sono caricati dinamicamente (JavaScript, lazy loading condizionale) e Googlebot non li scopre tramite il rendering classico. Per un sito statico con tag img standard, l’aggiunta è superflua.
Il sitemap news riguarda esclusivamente i siti registrati in Google News. Le URL devono avere meno di due giorni. Includere articoli più vecchi non attiva una penalità, ma Google li ignora, il che diluisce la pertinenza del file.
Invio del sitemap e robots.txt: la meccanica di dichiarazione
Due metodi di dichiarazione coesistono. Il primo, storico, consiste nell’aggiungere una direttiva Sitemap: https://example.com/sitemap.xml nel file robots.txt. Il secondo passa attraverso la Search Console o Bing Webmaster Tools.
Osserviamo che la dichiarazione tramite robots.txt è spesso l’unica presente sui siti che non hanno mai configurato una Search Console. Funziona, ma non fornisce alcun feedback sul trattamento del file da parte di Google. L’invio tramite la Search Console rimane il metodo da privilegiare, poiché espone gli errori di parsing, il numero di URL scoperte e lo stato di indicizzazione.
Indice di sitemaps per siti voluminosi
Il protocollo sitemaps.org impone un limite di 50.000 URL per file e una dimensione massima non compressa. Per i siti che superano questa soglia, un indice di sitemaps punta a più file figli. La segmentazione per tipo di contenuto (articoli, categorie, prodotti) facilita la diagnosi: se un file figlio mostra un tasso di indicizzazione basso, il problema è isolato a un tipo di pagina specifico.
- Segmentare per directory o per tipo di contenuto piuttosto che per ordine alfabetico o cronologico
- Nominare i file in modo esplicito (sitemap-products.xml, sitemap-blog.xml) per semplificare l’analisi nella Search Console
- Verificare che ogni file figlio contenga solo URL pertinenti al suo ambito, senza duplicati tra i file
Un sitemap ben segmentato trasforma la Search Console in uno strumento di diagnosi per tipo di contenuto. Un sitemap monolitico di 40.000 URL affoga i segnali nella massa e complica qualsiasi intervento mirato.