Scegli l’eleggibilità prima di generare l’XML
Una sitemap XML è un elenco leggibile dalle macchine di URL e metadati opzionali. Parti da una regola di eleggibilità, non da un’esportazione del crawler: includi una pagina solo quando è destinata alla ricerca, recuperabile pubblicamente e rappresenta la versione preferita del suo contenuto. Tieni fuori gli URL dei cataloghi facetati, i risultati di ricerca interna, le varianti di campagna, le destinazioni di login e le anteprime, a meno che non siano destinazioni di ricerca pubbliche deliberate.
Pagine pubbliche e utili destinate alla ricerca con un URL preferito unico.
Redirect, errori, duplicati, pagine noindex e rotte private.
L’aiuto alla scoperta non garantisce crawling o indicizzazione.
Elenca l’URL canonico, non ogni modo per raggiungerlo
Un URL canonico è la versione che vuoi che i motori di ricerca trattino come rappresentativa tra versioni simili. L’inclusione nella sitemap è un segnale canonico debole, quindi dovrebbe rafforzare — non contraddire — redirect, tag canonical autoreferenziali e link interni. Seleziona un formato HTTPS stabile ed emetti esattamente quella versione.
Controlla http e https, www e non-www, regole sulla slash finale, maiuscole/minuscole, pagine di stampa, filtri e parametri di tracciamento. Se un URL effettua un redirect, inserisci solo la sua destinazione canonica finale. Dai a ogni pagina localizzata indipendente il proprio URL canonico; non usare la sitemap per comprimere contenuti localizzati distinti.
Scrivi lo schema e l’host completi, non un percorso relativo. Google esegue il crawl degli URL così come appaiono.
Sitemap, tag canonical, link interni e policy di redirect dovrebbero indicare la stessa pagina.
Bloccare un duplicato non stabilisce una versione preferita.
Rendi l’XML piccolo, valido e veritiero
Usa la struttura del Protocollo Sitemap: XML in UTF-8 con un urlset, lo namespace della sitemap e una loc per ogni URL. Escape i caratteri sensibili in XML nei valori degli URL. L’automazione dovrebbe serializzare gli URL piuttosto che concatenare XML a mano.
Ogni sitemap può contenere al massimo 50.000 URL ed essere grande non più di 50 MB non compressi. Questi sono limiti, non obiettivi. Divisiona prima se prodotti, articoli, localizzazioni o tipi di contenuto creano un confine operativo utile.
Usa lastmod solo per la data di variazione significativa reale della pagina. Google lo usa quando è consistente e verificabilmente accurato; un aggiornamento dell’anno di copyright non è valido. Non timbrare mai ogni URL con il tempo del generatore. Google ignora changefreq e priority, quindi omettile.
loc è obbligatorio; lastmod è opzionale e deve descrivere la pagina, non la generazione.
Gzip può ridurre la dimensione di trasferimento, ma il file decompresso deve rimanere sotto i 50 MB.
Controlla la correttezza XML, la reperibilità e il comportamento delle pagine elencate.
Usa indici per scalare senza perdere responsabilità
Un indice di sitemap elenca file sitemap. Usane uno quando il sito supera il limite di un singolo file o necessita di inventari separati. Raggruppa per ownership editoriale, prodotto o help center. Ha gli stessi limiti di 50.000 voci e 50 MB non compressi.
Mantieni i file child sul sito previsto a URL stabili. Il protocollo generalmente vincola gli URL eleggibili all’host e alla posizione della sitemap; accordi cross-site richiedono proprietà verificata.
Dividi attorno a uno scopo testabile — tipo di contenuto, vetrina, set di lingue o confine di deployment. Registra il generatore, il proprietario e la popolazione prevista.
Invia l’indice completo piuttosto che ogni child singolarmente.
lastmod dell’indice descrive il file sitemap, non le sue pagine.
Pubblica, invia e interpreta correttamente i risultati
Ospita la sitemap a un indirizzo HTTPS stabile e pubblicamente reperibile, preferibilmente vicino alla root. Aggiungi una direttiva Sitemap assoluta in robots.txt. Invia la sitemap o l’indice a Google Search Console e Bing Webmaster Tools per dettagli di elaborazione.
In Search Console, Success significa che la sitemap è stata recuperata e letta senza errori. Has errors significa che è stata letta con errori; Couldn’t fetch significa che non è stata disponibile. Risolvi problemi di delivery, autenticazione, DNS, robots, redirect o XML e reinvia.
Tratta i conteggi di pagine scoperte come input diagnostico, non come punteggio. Una pagina scoperta non è garantita essere crawled o indicizzata. Esegui campioni di URL confrontandoli con il loro URL canonico, la risposta e i report di indicizzazione.
robots.txt aiuta la scoperta; l’invio tramite strumenti espone i report di elaborazione.
Search Console elenca i file inviati via report o API, non ogni singola scoperta tramite robots.txt.
Gestisci la sitemap come infrastruttura critica per le release
La qualità della sitemap può peggiorare quando un plugin CMS cambia, una distribuzione modifica l’host canonico, regole di cache servono output obsoleti o un job massivo pubblica pagine incomplete. Inserisci i controlli della sitemap nelle operazioni di pre-release e rollback. Non sostituire silenziosamente un inventario completo con un file vuoto o malformato.
Conserva la sitemap precedente nota come buona, segnala cambiamenti inattesi nel conteggio e campiona aggiunte e rimozioni prima della pubblicazione. Quando i percorsi cambiano, coordina redirect, tag canonical, link interni e sitemap come un unico insieme di modifiche. Questa è ottimizzazione proattiva dell’uptime: proteggi la superficie pubblica reperibile prima che crawler e visitatori trovino un percorso rotto.
Sospendi la pubblicazione per output sitemap non valido, vuoto, con host errato o non canonico.
Mantieni l’artefatto precedente e la configurazione del generatore pronti per il rollback.