Indicizzazione Google: scansione, sitemap, robots e canonical

L’indicizzazione è il processo con cui un motore di ricerca analizza una pagina e, se la ritiene idonea, la aggiunge al proprio indice. Senza questo passaggio l’URL non può comparire nei risultati organici. Essere indicizzati, però, non significa ottenere una buona posizione: la pagina deve poi essere selezionata e ordinata rispetto a una specifica ricerca.

Per lavorare sul posizionamento SEO bisogna distinguere scoperta, scansione, rendering, indicizzazione e ranking. Quando queste fasi vengono confuse, si rischia di correggere il title di una pagina che Google non può raggiungere oppure di attribuire alla sitemap un problema che dipende dalla qualità o dalla duplicazione del contenuto.

Scansione, indicizzazione e posizionamento: che differenza c’è

Scoperta

Il motore viene a conoscenza di un URL attraverso collegamenti, sitemap, redirect e altre fonti già note. Un URL isolato, privo di link interni e non presente in una sitemap, è più difficile da scoprire e interpretare nel contesto del sito.

Scansione

Un crawler è un programma automatico che visita gli URL, scarica risorse e segue i collegamenti consentiti. Googlebot è il crawler utilizzato da Google per la ricerca. Non naviga come una persona: richiede pagine e file, legge risposte del server e registra i link che possono portare a nuove risorse.

Rendering

Se la pagina usa JavaScript, il motore può dover eseguire il codice per ottenere contenuto, link e metadati generati nel browser. Il rendering richiede risorse aggiuntive e può avvenire dopo il primo download HTML. Un contenuto essenziale disponibile soltanto dopo interazioni o errori di script può non essere visto correttamente.

Indicizzazione

Il sistema analizza contenuto, segnali, duplicati e versione canonica. Può decidere di conservare la pagina nell’indice, scegliere un URL alternativo come canonico oppure non indicizzarla. La scansione è quindi necessaria in molti casi, ma non garantisce l’indicizzazione.

Posizionamento

Quando un utente esegue una ricerca, il motore seleziona dall’indice i risultati ritenuti più pertinenti e utili. Una pagina può essere indicizzata e non comparire per le query monitorate, oppure apparire molto lontano dalle prime posizioni. Questo è un problema di visibilità, non necessariamente di indicizzazione.

I requisiti di base per indicizzare una pagina

Per essere candidata all’indice, una pagina deve essere raggiungibile, restituire una risposta appropriata, non bloccare l’accesso necessario e non contenere direttive che ne chiedono l’esclusione. Deve inoltre offrire contenuto sufficiente e non essere interpretata come duplicato di un altro URL.

• L’URL restituisce normalmente codice HTTP 200.
• Il crawler può accedere alla pagina e alle risorse necessarie.
• Non è presente una direttiva noindex.
• La canonical non indica per errore un’altra pagina.
• Il contenuto principale è disponibile anche al motore di ricerca.
• Esistono link interni che rendono la pagina parte dell’architettura.
• La sitemap, se presente, include l’URL canonico corretto.
• La pagina non è una copia debole, vuota o generata da un errore.

Questi requisiti rendono possibile l’indicizzazione, ma non obbligano il motore a includere l’URL. La decisione dipende anche dalla qualità della risorsa, dalla duplicazione e dal valore che aggiunge all’indice.

Come i crawler scoprono gli URL

I crawler scoprono le pagine soprattutto seguendo link presenti in risorse già conosciute. Per questo navigazione, breadcrumb, categorie, pagine hub e link contestuali hanno una funzione tecnica oltre che editoriale. Un collegamento HTML standard, con una destinazione reale nell’attributo href, è più affidabile di un elemento che simula un link solo tramite script.

La architettura SEO del sito dovrebbe consentire di raggiungere le pagine importanti attraverso percorsi logici. La sitemap completa questo sistema, ma non sostituisce i link interni: un URL presente soltanto nel file XML rimane debole e privo di contesto.

Robots.txt: controllare la scansione, non l’indicizzazione

Il file robots.txt si trova nella radice del dominio e comunica ai crawler quali percorsi non dovrebbero essere richiesti. Le regole si applicano agli user-agent indicati e devono essere scritte con attenzione: un carattere o un percorso errato può bloccare intere sezioni.

Bloccare un URL in robots.txt non equivale a rimuoverlo dall’indice. Se il motore conosce l’indirizzo tramite link esterni o altre fonti, può conservarne l’URL senza poter leggere il contenuto. Inoltre, se la pagina è bloccata, il crawler non può vedere un eventuale noindex presente nell’HTML.

Il robots.txt è adatto a gestire la scansione di aree non utili, filtri o risorse ripetitive; non protegge informazioni riservate. Per contenuti privati servono autenticazione e controlli di accesso. Prima di bloccare CSS o JavaScript, bisogna verificare che non siano necessari per interpretare la pagina.

Meta robots e noindex

La direttiva noindex, inserita in un meta tag oppure in un’intestazione HTTP, chiede di non includere la risorsa nell’indice. Può essere appropriata per pagine interne prive di valore nella ricerca, risultati di ricerca del sito, aree temporanee o contenuti che devono rimanere accessibili agli utenti ma non comparire su Google.

Affinché la direttiva venga rilevata, il crawler deve poter accedere alla pagina. La combinazione “blocco nel robots.txt più noindex” è quindi contraddittoria: il blocco può impedire la lettura del noindex. Dopo l’aggiunta, l’URL può restare visibile per un periodo finché non viene nuovamente elaborato.

Sitemap XML: che cosa fa davvero

Una sitemap XML elenca gli URL canonici che il sito desidera rendere disponibili ai motori di ricerca. È particolarmente utile per siti grandi, nuovi, con pagine difficili da raggiungere o contenuti aggiornati frequentemente. Nei CMS come WordPress viene normalmente generata in modo automatico dal core o da un plugin SEO.

La sitemap facilita la scoperta, ma non garantisce scansione, indicizzazione né ranking. Deve contenere URL assoluti, preferibilmente in stato 200, indicizzabili e canonici. Non dovrebbero comparire redirect, errori, pagine noindex, duplicati o versioni con parametri non desiderate.

• Mantieni soltanto URL che vuoi effettivamente indicizzare.
• Usa la stessa versione canonica adottata nei link interni.
• Aggiorna il campo di modifica solo quando il contenuto cambia in modo significativo.
• Dividi file molto grandi e usa un indice di sitemap quando necessario.
• Dichiara la sitemap nel robots.txt e inviala tramite Search Console.
• Controlla periodicamente differenze tra URL inviati e indicizzati.

Il limite tecnico comunemente adottato è 50.000 URL o 50 MB non compressi per singolo file; oltre questa soglia si utilizzano più sitemap raccolte in un indice. Per la maggior parte dei siti aziendali il problema non è il limite, ma la pulizia dell’elenco.

Canonical: scegliere la versione principale

Pagine uguali o molto simili possono essere raggiunte attraverso URL differenti: parametri, versioni di stampa, protocolli, sottodomini, slash finali o percorsi duplicati. L’elemento rel="canonical" indica la versione preferita, ma viene interpretato come un segnale e non come un ordine assoluto.

I segnali dovrebbero essere coerenti: link interni, sitemap, redirect e canonical devono convergere sullo stesso URL canonico. Una canonical verso una pagina non equivalente può essere ignorata. Per una risorsa spostata definitivamente, un redirect è in genere più adatto della sola canonical.

La canonical autoreferenziale, cioè rivolta alla pagina stessa, aiuta a dichiarare la versione prevista. Nei siti multilingua o ecommerce occorre prestare particolare attenzione a varianti, filtri, paginazioni e combinazioni tra canonical e riferimenti linguistici.

Redirect e codici di stato HTTP

Il codice 200 segnala una risposta disponibile; 301 e 308 indicano uno spostamento permanente; 302 e 307 uno spostamento temporaneo; 404 significa che la risorsa non è stata trovata; 410 che è stata rimossa intenzionalmente; gli errori 5xx segnalano problemi del server.

Catene e loop di redirect rallentano il percorso e possono creare segnali incoerenti. Quando un URL cambia, i link interni devono puntare direttamente alla nuova destinazione. La guida ai redirect in WordPress spiega quando usarli e come evitare gli errori più comuni.

Una soft 404 si verifica quando una pagina restituisce 200 ma comunica che il contenuto non esiste, oppure offre una risposta vuota o irrilevante. Il motore può trattarla come un errore anche se il server dichiara il contrario. È quindi importante che pagine rimosse e risultati vuoti restituiscano stati coerenti.

JavaScript e rendering

Un’applicazione può caricare contenuto, link e metadati tramite JavaScript. I motori moderni sono in grado di eseguire molto codice, ma rendering ed elaborazione possono essere differiti e gli errori restano possibili. Le informazioni essenziali dovrebbero essere disponibili nell’HTML iniziale o attraverso una soluzione di rendering affidabile.

Occorre verificare che title, meta robots, canonical, contenuto principale e link siano presenti nella versione elaborata dal crawler. I link che richiedono un clic, uno scroll o un evento non sempre vengono scoperti. Anche API bloccate, timeout e risorse negate dal robots.txt possono produrre una pagina incompleta.

Indicizzazione su WordPress

WordPress offre l’opzione “Scoraggia i motori di ricerca dall’effettuare l’indicizzazione di questo sito”. In produzione deve essere disattivata, salvo esigenze precise. Plugin SEO e template possono inoltre applicare noindex, canonical e sitemap a tipi di contenuto, archivi e tassonomie.

Dopo migrazioni, restyling o passaggi da staging a produzione è necessario controllare impostazioni di lettura, visibilità dei contenuti, permalink, redirect e canonical. La guida su come fare SEO su WordPress raccoglie le verifiche di base da integrare con un audit tecnico.

Come diagnosticare una pagina non indicizzata

Il controllo deve partire dall’URL esatto e procedere per esclusione. Search Console può mostrare se la pagina è nota, l’ultima scansione, il codice rilevato, la canonical dichiarata e quella scelta dal motore, nonché eventuali blocchi o direttive. Il rapporto non va letto come una lista di errori: alcune esclusioni sono intenzionali e corrette.

1. Verifica la risposta HTTP e l’URL finale dopo eventuali redirect.
2. Controlla robots.txt, meta robots e intestazioni X-Robots-Tag.
3. Confronta canonical dichiarata, link interni e sitemap.
4. Esamina HTML iniziale e contenuto renderizzato.
5. Accertati che la pagina non sia orfana e riceva link pertinenti.
6. Confronta il contenuto con pagine simili o duplicate.
7. Valuta utilità, completezza e ruolo dell’URL nel sito.
8. Dopo la correzione, attendi una nuova elaborazione e monitora il rapporto.

“Scansionata, ma non indicizzata”

Il motore ha visitato la pagina ma non l’ha inclusa nell’indice. Le cause possono riguardare duplicazione, contenuto debole, soft 404, qualità complessiva o priorità di elaborazione. Non esiste una singola correzione: bisogna valutare se l’URL merita di esistere e se offre qualcosa di distinto.

“Rilevata, ma non indicizzata”

L’URL è conosciuto, ma la scansione non è ancora avvenuta o è stata rinviata. Collegamenti interni, qualità dell’architettura, capacità del server e numero di URL generati possono incidere. Richiedere ripetutamente l’indicizzazione non sostituisce la soluzione della causa.

“Pagina duplicata” o canonical diversa

Google ha scelto un’altra versione come principale. Se la scelta è corretta, non serve intervenire. Se è errata, confronta contenuto, redirect, canonical, sitemap e link interni: segnali contrastanti rendono più difficile identificare la versione preferita.

Crawl budget: quando è davvero un problema

Il crawl budget descrive in modo semplificato la quantità di risorse che un motore può e vuole dedicare alla scansione di un sito. Per molti siti piccoli o medi non è il primo limite. Diventa rilevante soprattutto con grandi quantità di URL, filtri e parametri, contenuti duplicati, pagine generate automaticamente o infrastrutture lente.

Ottimizzare il crawl budget non significa bloccare indiscriminatamente. Occorre ridurre spazi infiniti, correggere link verso errori e redirect, migliorare prestazioni del server, consolidare duplicati e far emergere le pagine importanti. I Core Web Vitals misurano aspetti dell’esperienza utente, mentre la capacità di risposta del server e la stabilità tecnica influenzano anche la scansione: sono temi collegati, ma non equivalenti.

Strumenti per controllare scansione e indicizzazione

La diagnosi migliora quando si combinano tre punti di vista: ciò che Google dichiara di avere elaborato, ciò che un crawler riesce a simulare e ciò che i log del server dimostrano essere realmente accaduto. Nessun singolo strumento copre tutte e tre le prospettive.

Google Search Console: lo strumento centrale

Controllo URL di Google Search Console mostra la versione presente nell’indice, l’ultima scansione, eventuali ostacoli, la canonical dichiarata e quella scelta da Google. Il test live verifica se la versione attuale sembra accessibile e renderizzabile, ma non può prevedere quale canonical verrà scelta né garantire l’indicizzazione.

Il rapporto Indicizzazione delle pagine offre la vista aggregata degli URL conosciuti e delle ragioni di esclusione; “non indicizzata” non significa automaticamente “errore”. Il rapporto Sitemap permette di confrontare URL inviati e risultati per insiemi omogenei. Statistiche di scansione mostra richieste, risposte, tipi di file e andamento dell’attività di Googlebot a livello di proprietà.

Crawler: Semrush Site Audit e Screaming Frog

Semrush Site Audit individua status code, problemi di robots.txt, canonical, profondità, link interni e differenze tra crawl e sitemap. Screaming Frog SEO Spider offre controlli più granulari e può confrontare HTML iniziale e rendering JavaScript. Entrambi simulano una scansione: spiegano che cosa potrebbe incontrare un bot con quelle impostazioni, non quali URL Googlebot abbia realmente visitato.

Log del server: la prova delle richieste reali

Semrush Log File Analyzer, Screaming Frog Log File Analyser e strumenti equivalenti lavorano sui log del server. Mostrano quali URL sono stati richiesti, con quale frequenza, da quale user-agent e con quale risposta. Prima dell’analisi è importante verificare i bot tramite gli indirizzi IP e normalizzare parametri e varianti degli URL.

Chrome DevTools per sorgente, DOM e rete

DevTools consente di confrontare sorgente e DOM, osservare richieste di rete, errori JavaScript e risorse bloccate. È una verifica complementare: dimostra che cosa accade nel browser usato per il test, non sostituisce la versione renderizzata mostrata dal Controllo URL né i log di Googlebot.

Una diagnosi in quattro passaggi

1. Usa Search Console per classificare il problema e distinguere dati dell’indice e test live.
2. Esegui un crawl per trovare pattern su status, direttive, canonical, link e sitemap.
3. Confronta HTML e rendering quando contenuti o collegamenti dipendono da JavaScript.
4. Per siti grandi o problemi persistenti, verifica nei log dove Googlebot spende davvero le richieste.

Tre indicazioni dalla pratica di SEO tecnici e sviluppatori

Sono osservazioni operative da mettere alla prova sul sito. Non sostituiscono la documentazione ufficiale e non trasformano ogni esclusione in un problema da correggere.

Aleyda Solís: “scansionata, ma non indicizzata” non è sempre un guasto tecnico

Aleyda Solís richiama l’attenzione sul passaggio successivo ai controlli tecnici: se status, robots, rendering e canonical sono corretti, bisogna verificare se la pagina è distinta, utile e meritevole di essere conservata nell’indice. Richiedere nuovamente l’indicizzazione senza cambiare la causa raramente modifica il risultato.

Brodie Clark: segmentare il rapporto per sitemap

Per siti grandi, Brodie Clark usa le sitemap come segmenti di analisi. Se prodotti, categorie e contenuti sono divisi in file coerenti, nel rapporto Pagine di Search Console è possibile confrontare indicizzati, esclusi e motivazioni per ogni gruppo. Una sitemap che mescola URL casuali perde gran parte di questo valore diagnostico.

Barry Adams: mettere nell’HTML ciò che è essenziale

Barry Adams raccomanda un approccio HTML-first: contenuto principale, canonical, hreflang, navigazione, link interni e dati strutturati non dovrebbero dipendere dal JavaScript client-side quando possono essere restituiti nell’HTML iniziale. Google può eseguire JavaScript, ma il rendering aggiunge complessità, ritardi e nuovi punti di errore.

Errori frequenti nell’indicizzazione

• Usare robots.txt per tentare di rimuovere una pagina dall’indice.
• Lasciare il noindex dello staging dopo la pubblicazione.
• Includere nella sitemap redirect, errori, duplicati e URL noindex.
• Dichiarare una canonical verso una pagina che non è equivalente.
• Creare pagine orfane presenti soltanto nella sitemap.
• Affidare contenuto e link essenziali a JavaScript non verificato.
• Restituire 200 per pagine inesistenti o vuote.
• Generare moltissimi URL tramite filtri, calendari e parametri.
• Richiedere nuove scansioni senza correggere il problema sottostante.
• Confondere indicizzazione con buone posizioni per una keyword.

Checklist dopo la pubblicazione di una pagina

1. Apri l’URL e verifica che restituisca 200 e mostri il contenuto corretto.
2. Controlla title, meta robots e canonical nel codice e nel rendering.
3. Collega la pagina da risorse pertinenti e dalla struttura del cluster.
4. Assicurati che la sitemap contenga l’URL canonico.
5. Verifica che robots.txt non blocchi pagina o risorse essenziali.
6. Controlla l’URL in Search Console e registra lo stato iniziale.
7. Monitora log, copertura, query e canonical nel tempo.
8. Aggiorna o consolida la pagina se non offre un valore distinto.

Domande frequenti sull’indicizzazione Google

Quanto tempo serve per indicizzare un sito?

Non esiste un tempo garantito. Una pagina può essere scoperta rapidamente oppure richiedere giorni o settimane. Collegamenti interni, reputazione, frequenza di aggiornamento, qualità e salute tecnica influenzano il processo.

Inviare una sitemap fa indicizzare tutte le pagine?

No. La sitemap aiuta la scoperta e comunica gli URL preferiti, ma il motore decide quali scansionare e indicizzare. Un numero elevato di URL esclusi richiede un’analisi delle cause, non invii ripetuti.

Una pagina noindex può essere scansionata?

Sì. Normalmente deve essere scansionata affinché il motore legga la direttiva. Per ridurre o impedire l’accesso servono controlli diversi; per proteggere informazioni riservate occorre l’autenticazione.

Il file robots.txt è obbligatorio?

No, ma è utile quando occorre gestire l’accesso dei crawler e indicare la sitemap. Un file assente equivale, in pratica, a non fornire restrizioni tramite quel meccanismo.

Come faccio a sapere se una pagina è indicizzata?

Il controllo URL di Search Console è lo strumento principale per il proprio sito. L’operatore di ricerca site: può offrire un’indicazione, ma non è un inventario completo né uno strumento diagnostico affidabile.

Dalla diagnosi alla priorità corretta

Un problema di indicizzazione raramente si risolve con un solo pulsante. Bisogna capire in quale fase si interrompe il percorso: scoperta, scansione, rendering, scelta canonica o valutazione della pagina. Soltanto dopo ha senso scegliere l’intervento e misurarne l’effetto.

Se il sito presenta esclusioni anomale, molte pagine duplicate o segnali contraddittori, un’analisi SEO e audit tecnico-strategico permette di separare i problemi reali dalle esclusioni corrette e definire un ordine di intervento sostenibile.