Un sitemap XML non si riduce a un elenco di URL generato automaticamente da un CMS. Su un sito parigino il cui contenuto evolve al ritmo di eventi locali, aggiornamenti di servizi o notizie di quartiere, la qualità del file condiziona direttamente la velocità con cui i motori di ricerca scoprono le nuove pagine e ignorano quelle vecchie.
Affidabilità di lastmod: l’unico segnale che conta in un sitemap
Osserviamo troppo spesso sitemap in cui il tag lastmod mostra la data di generazione del file su ogni URL, senza alcun legame con la realtà editoriale. Google ha chiarito la sua posizione: sfrutta questa data solo quando è costantemente e verificabilmente esatta, cioè riflettendo una modifica significativa del contenuto principale, dei dati strutturati o dei link.
Modificare l’anno di copyright nel piè di pagina non costituisce un aggiornamento significativo. Su un sito parigino i cui orari, tariffe o pagine di eventi cambiano regolarmente, lastmod deve provenire dalla cronologia editoriale reale, non dalla data di ricostruzione del file.
Un CMS come WordPress, abbinato a un plugin SEO correttamente configurato, può datare ogni URL a partire dall’ultimo salvataggio effettivo dell’articolo. Al contrario, uno script personalizzato che rigenera il sitemap ogni notte applicando la data del giorno a tutte le voci invia un segnale confuso. I robot finiscono per ignorare completamente le date, annullando l’interesse del file per il recrawl mirato.
Analizzando il sitemap del sito Paris Astuce, si osserva una struttura che riflette questo principio: le URL sono organizzate per tipo di contenuto, con date coerenti rispetto alle pubblicazioni effettive.
Scostamenti tra sitemap, CMS e Search Console su un sito web parigino
Il confronto tra le URL del sitemap, le pagine realmente pubblicate dal CMS e quelle indicizzate in Google Search Console costituisce un audit che la maggior parte delle guide per il grande pubblico ignora. Questi scostamenti rivelano tuttavia problemi concreti.
Pagine presenti nel sitemap ma assenti dall’indice
Un sitemap è un segnale di scoperta, non una richiesta imperativa di crawl. Un’URL elencata nel file può rimanere esclusa se porta una direttiva noindex, se il suo contenuto è ritenuto troppo debole o se nessun link interno punta verso di essa. Su un sito parigino con decine di pagine di servizi locali, raccomandiamo di incrociare regolarmente il rapporto “Pagine” di Search Console con il contenuto del sitemap per individuare queste esclusioni.
Pagine indicizzate ma assenti dal sitemap
Il caso inverso è altrettanto frequente. Pagine di test, bozze rese pubbliche per errore o URL con parametri di tracciamento possono essere crawlate tramite il collegamento interno senza mai comparire nel sitemap. Un sitemap pulito contiene solo le URL canoniche da indicizzare. Qualsiasi URL che non desideri vedere apparire nei risultati di ricerca non ha nulla a che fare con questo file.
Ecco i controlli da effettuare periodicamente:
- Estrarre l’elenco completo delle URL dal sitemap e confrontarlo con l’esportazione delle pagine pubblicate del CMS (solo stato “pubblicato”, escluse bozze e pagine private)
- Verificare in Search Console che ogni URL del sitemap sia indicizzata o volontariamente esclusa da una direttiva esplicita (noindex, canonica verso un’altra pagina)
- Identificare le URL orfane indicizzate da Google ma assenti dal sitemap, che segnalano spesso pagine obsolete o percorsi tecnici non puliti
Organizzazione dei sitemap per un sito parigino multi-sezioni
Un sito web parigino che copre più tematiche (arrondissements, uscite, buoni affari, notizie) guadagna a segmentare il suo sitemap piuttosto che raggruppare tutto in un unico file. Il meccanismo di sitemap index consente di fare riferimento a più file figli, ciascuno dedicato a un tipo di contenuto.
Questa segmentazione non è solo estetica. Permette di osservare in Search Console il tasso di indicizzazione per categoria. Se le pagine “eventi” mostrano un tasso di indicizzazione nettamente inferiore rispetto alle pagine “guide di quartiere”, il problema si trova probabilmente nella freschezza o nella profondità del contenuto degli eventi, non nella configurazione tecnica.
Nominare e strutturare i file figli
Raccomandiamo una denominazione esplicita: sitemap-posts.xml, sitemap-pages.xml, sitemap-categories.xml. Questa convenzione facilita la lettura dei rapporti di Search Console e accelera il diagnosticare in caso di caduta di indicizzazione su un segmento specifico.
Ogni file figlio deve contenere solo URL che restituiscono un codice HTTP 200. Le redirezioni 301, gli errori 404 e le pagine in soft 404 inquinano il file e sprecano il budget di crawl. Su un sito il cui contenuto è legato all’attualità parigina, le pagine scadute (eventi passati, luoghi chiusi) devono essere rimosse dal sitemap non appena non sono più pertinenti.
Interazione tra robots.txt e sitemap XML
Il file robots.txt può dichiarare la posizione del sitemap tramite la direttiva Sitemap, che rimane il metodo più semplice affinché i robot lo trovino senza invio manuale. Tuttavia, un’incoerenza tra i due file crea un conflitto silenzioso.
Se robots.txt blocca un intero directory tramite Disallow e il sitemap contiene URL di quella directory, i motori ricevono un segnale contraddittorio. Il sitemap non supera mai una regola Disallow in robots.txt. L’URL sarà scoperta ma non crawlata, generando errori in Search Console senza benefici SEO.
Su un sito WordPress parigino, questo problema si verifica frequentemente con le directory di immagini, le pagine autore o le archiviazioni di tag che alcuni plugin SEO includono per impostazione predefinita nel sitemap mentre le bloccano in robots.txt. Un audit incrociato dei due file evita queste contraddizioni.
Il sitemap di un sito web parigino non è un file da generare una volta e poi dimenticare. È uno strumento di diagnosi continuo il cui valore dipende interamente dalla rigorosità con cui riflette lo stato reale del sito, URL per URL, data per data.
