Un sito di diverse centinaia di pagine di cui la metà non appare su Google è un problema comune. La causa frequente: il motore di ricerca semplicemente non trova queste URL. La mappa del sito XML interviene a questo livello, fornendo ai robot di scansione un elenco strutturato delle pagine da esplorare.
Ma depositare un file sitemap nella radice del sito non è sufficiente. Il modo in cui lo si costruisce, ciò che si include (e ciò che si esclude) determina direttamente la sua efficacia per l’indicizzazione e la visibilità.
Sitemap XML: ciò che Google utilizza realmente nel file
Si legge spesso che è necessario fornire la priorità, la frequenza di modifica e la data dell’ultima aggiornamento per ogni URL. In pratica, Google ignora i valori priority e changefreq. Mantenere questi campi non porta nulla per il posizionamento su questo motore.
L’unico parametro che conta realmente per Google è lastmod, a condizione che rifletta una modifica reale del contenuto. Cambiare una parola nel piè di pagina o aggiornare l’anno del copyright non costituisce una modifica significativa. Google verifica la coerenza di questa data: se viene aggiornata artificialmente ad ogni generazione della sitemap, il segnale perde ogni affidabilità.
Affinché lastmod sia utile, deve corrispondere a un aggiornamento del contenuto principale, dei dati strutturati o dei link interni della pagina. Si può ad esempio consultare il sito Flow3 per osservare come una sitemap ben strutturata organizza le sue URL con date coerenti.
Un punto spesso mal compreso: inviare un’URL in una sitemap non garantisce né la sua esplorazione né la sua indicizzazione. Google tratta il file come un segnale, non come una direttiva. Se una pagina inviata rimane assente dall’indice, il problema proviene probabilmente dalla qualità o dalla singolarità del contenuto, non dalla sitemap stessa.
Filtrare le URL della sitemap per orientare la scansione
Il riflesso comune consiste nell’includere tutte le pagine del sito nella sitemap. È un errore. Una sitemap che elenca URL in noindex, pagine di paginazione, filtri di ricerca o duplicati invia un cattivo segnale ai robot di scansione.
L’obiettivo è mantenere solo le URL canoniche, esplorabili e destinate all’indicizzazione. Ogni URL presente nel file deve soddisfare tre criteri:
- Deve restituire un codice HTTP 200 (niente reindirizzamento 301 né errore 404 o 410)
- Deve corrispondere alla versione canonica della pagina (il tag canonical punta verso se stesso)
- Non deve essere bloccata dal file robots.txt né da un tag noindex
Su un sito e-commerce o un portale con migliaia di pagine, si segmenta la sitemap in più file tematici (prodotti, categorie, articoli di blog). Questa segmentazione consente di individuare più facilmente, in Google Search Console, quale gruppo di pagine presenta problemi di indicizzazione.
Inviare e monitorare la sitemap in Search Console
Depositare il file all’indirizzo votresite.com/sitemap.xml è un primo passo. Ma senza una sottomissione esplicita tramite Google Search Console, il motore potrebbe impiegare tempo a rilevarlo. La sottomissione manuale accelera la presa in considerazione iniziale.
Una volta inviata, la Search Console mostra il numero di URL scoperte e il numero di URL effettivamente indicizzate. La differenza tra questi due numeri è il vero indicatore di prestazione della sitemap. Un ampio scarto segnala o pagine di bassa qualità, o problemi tecnici (tempo di risposta del server, contenuto duplicato, pagine troppo sottili).
Controllare regolarmente il rapporto di indicizzazione per sitemap consente di rilevare le regressioni dopo una migrazione o un rifacimento. Durante una migrazione del sito, URL mal reindirizzate possono rimanere nella vecchia sitemap, generando errori 404 in serie nel rapporto.
IndexNow e sitemap: due meccanismi complementari per Bing
La sitemap funziona in modalità passiva: si deposita un file e i motori vengono a leggerlo secondo il loro calendario. Per i siti che pubblicano o modificano contenuti frequentemente, questo ritardo può essere un freno.
Il protocollo IndexNow, supportato da Bing, consente di notificare il motore in tempo reale che un’URL è cambiata. Invece di attendere che il robot torni a esplorare la sitemap, si invia un ping immediato. È particolarmente utile per i siti di notizie, i marketplace o le directory con schede aggiornate quotidianamente.
Google non ha adottato IndexNow fino ad oggi. Per questo motore, la combinazione di sitemap XML più API di indicizzazione (per i tipi di contenuto idonei) rimane la combinazione più efficace. La strategia varia quindi a seconda dei motori mirati, e un sito che punta sia a Google che a Bing ha interesse a combinare i due approcci.
- Sitemap XML aggiornata con date lastmod affidabili per Google
- IndexNow attivato per segnalare i cambiamenti in tempo reale a Bing
- Sottomissione negli strumenti webmaster dei due motori (Search Console e Bing Webmaster Tools)
Errori frequenti che neutralizzano una sitemap
Alcuni errori tecnici rendono la sitemap inutile senza che il webmaster se ne accorga. Il più comune: un file robots.txt che blocca l’accesso alla sitemap stessa. Il file deve contenere la direttiva Sitemap: seguita dall’URL completo del file.
Un altro tranello: superare il limite di dimensione. Una sitemap unica non può contenere più di 50.000 URL né pesare più di 50 MB non compressi. Oltre, è necessario creare un file sitemap index che faccia riferimento a più sitemap figlie.
Infine, lasciare una sitemap obsoleta online dopo un rifacimento crea confusione. Le vecchie URL generano errori in Search Console, diluiscono il budget di scansione e rallentano la presa in considerazione delle nuove pagine. Dopo ogni modifica strutturale del sito, rigenerare e risottomettere la sitemap dovrebbe far parte del protocollo di distribuzione.
La sitemap rimane un file tecnico semplice da produrre. Il suo valore risiede meno nella sua creazione che nella sua manutenzione: URL pulite, date affidabili, monitoraggio regolare in Search Console. È questa rigore che trasforma un file XML passivo in un leva concreta di visibilità.
