Google ha precisato la spiegazione dello stato «Scansionata, ma attualmente non indicizzata» in Search Console. Il punto operativo è scegliere quali URL richiedono una diagnosi: il totale delle esclusioni, da solo, non dice quanto il sito stia perdendo in visibilità commerciale.
La modifica è stata segnalata da Barry Schwartz il 3 novembre 2026. Il testo della guida ufficiale al report Indicizzazione delle pagine, verificato il 4 novembre, chiarisce che Google non indicizza tutte le pagine del web e che questa voce è comune. Non indica necessariamente un problema da correggere. È una precisazione documentale: non dimostra un aggiornamento dell’algoritmo e non ha una disponibilità geografica da attendere.
Che cosa descrive davvero quello stato
Google ha scansionato l’URL, ma al momento non l’ha indicizzata. La dicitura non identifica da sola la causa, non equivale a una penalizzazione e non certifica un difetto dei contenuti.
Una pagina di servizio strategica esclusa dall’indice merita un’indagine anche quando il report contiene poche URL. Migliaia di varianti senza utilità autonoma possono invece richiedere soprattutto una revisione dell’architettura. La prima decisione del consulente deve riguardare il tipo di pagina che l’azienda intende rendere trovabile.
Costruire il campione prima di modificare il sito
Il metodo proposto parte da un elenco delle URL che dovrebbero essere indicizzate. Per ciascuna vanno registrati funzione, template, canonical prevista, data dell’ultima modifica significativa e priorità commerciale. Poi si confronta questo inventario con gli esempi disponibili in Search Console.
È utile separare pagine nuove, URL precedentemente indicizzate, varianti di pagine esistenti e contenuti appena migrati. Una perdita improvvisa su un template già stabile richiede verifiche diverse da quelle necessarie per una nuova sezione. Non esiste una soglia percentuale universale oltre la quale tutte le esclusioni diventano un’emergenza.
| Gruppo | Domanda tecnica | Decisione da preparare |
|---|---|---|
| Servizi, categorie e prodotti prioritari | L’URL prevista è accessibile e presenta il contenuto corretto? | Diagnosi puntuale e responsabilità assegnata. |
| Varianti e pagine sovrapposte | Esiste una destinazione principale coerente? | Rivedere duplicazioni e segnali di canonicalizzazione. |
| Contenuti nuovi o modificati | Quale versione ha potuto vedere Google? | Confrontare cronologia del rilascio e dati diagnostici. |
| Problema esteso a sezioni diverse | C’è una modifica tecnica comune alle URL coinvolte? | Verificare infrastruttura e configurazioni condivise. |
Controllo URL: distinguere lo stato noto dal test live
La documentazione di Controllo URL distingue i dati disponibili nell’indice dal test della pagina attuale. Le due viste rispondono a domande differenti: che cosa risulta a Google e che cosa riesce a recuperare adesso.
Nel campione conviene annotare ultima scansione, esito del recupero, indicizzazione consentita e canonical dichiarata o scelta, quando disponibili. Un campo assente non va riempito con una supposizione. Il test live non può prevedere la canonical che Google sceglierà e un esito positivo non garantisce l’indicizzazione.
Se un intervento è successivo all’ultima scansione indicata, conservare entrambi i riferimenti temporali. Altrimenti si rischia di attribuire alla versione attuale un problema osservato su quella precedente. Lo stesso criterio vale per il confronto fra una URL originale e la destinazione di un redirect.
Accesso, direttive e rendering: verificare i livelli separatamente
La verifica tecnica proposta deve registrare risposta HTTP effettiva, eventuali passaggi di redirect, intestazioni, direttive robots e contenuto restituito. Un controllo sul browser del consulente è utile, ma non basta a ricostruire ciò che ha ricevuto un crawler in un altro momento.
Per i siti JavaScript, la guida Google al funzionamento della ricerca distingue scansione, rendering e indicizzazione. Controllare il codice iniziale e il contenuto renderizzato aiuta a verificare se testo principale e collegamenti sono effettivamente disponibili. La presenza di JavaScript non dimostra, da sola, la causa dell’esclusione.
Per problemi intermittenti, confrontare gli orari dei test con log e rilasci applicativi. Conservare la risposta osservata e il comportamento atteso. Una pagina che occasionalmente restituisce una schermata di errore richiede evidenze riproducibili prima di avviare una riscrittura editoriale.
Canonical e contenuti: controllare coerenza e utilità
La documentazione sulla canonicalizzazione descrive redirect, rel="canonical" e sitemap come segnali con diversa forza, non come garanzie assolute. Va verificato che puntino alla destinazione desiderata senza indicazioni contraddittorie.
Dopo i controlli tecnici, l’analisi editoriale deve rispondere a una domanda concreta: questa URL offre qualcosa che manca nella pagina principale o in altre pagine del sito? Per una categoria commerciale possono essere determinanti assortimento, informazioni di scelta e differenze rispetto a categorie vicine. Aggiungere testo standard a ogni pagina non costituisce una diagnosi.
Se due URL svolgono lo stesso compito, la decisione può riguardare il loro consolidamento. Se rispondono a esigenze diverse, occorre rendere riconoscibile tale differenza. Sono scelte da motivare sul sito esaminato, senza attribuirle automaticamente alla nuova formulazione della guida.
Come verificare il risultato dell’intervento
Per ogni modifica, il registro di lavoro dovrebbe contenere URL, evidenza iniziale, ipotesi, intervento, data e controllo successivo. Separare tre esiti: problema tecnico risolto, stato di indicizzazione cambiato, risultati della pagina migliorati. Possono verificarsi in momenti diversi.
Quando opportuno si può richiedere l’indicizzazione dopo la correzione; la richiesta non sostituisce il controllo dell’esito. Ripetere un invio senza nuove evidenze non chiarisce perché la pagina resti esclusa. Anche la semplice ricomparsa nell’indice non dimostra quale modifica sia stata decisiva se sono stati cambiati più elementi insieme.
Google indirizza verso una segnalazione di possibile bug quando, dopo una diagnosi completa, si sospetta un problema generalizzato di indicizzazione dell’intero sito. Un dossier utile dovrebbe includere campione, cronologia ed esclusione documentata delle cause locali. La priorità aziendale resta rendere trovabili le pagine che sostengono il servizio o la vendita, con interventi misurabili e una responsabilità chiara.