Crawled currently not indexed: come se ne esce

«Pagina scansionata, ma attualmente non indicizzata» (nel pannello inglese si chiama crawled currently not indexed) significa che Googlebot ha scaricato quella pagina, l’ha letta e per adesso ha deciso di tenerla fuori dall’indice. La documentazione non dichiara il motivo, non dà nessun tempo, e aggiunge una riga che quasi nessuno segue: «non è necessario inviare di nuovo l’URL per la scansione».

Una risposta certa su come se ne esce non esiste, e non è una scusa. Nei 1.732 post del blog Search Central dal 2005 a oggi la stringa «currently not indexed» non compare mai, e Google non ha mai dichiarato una soglia né un percorso di recupero. Quello che si può fare è tenere separate tre cose: cosa Google ha scritto e detto, con le date; cosa il settore gli attribuisce senza una fonte; cosa misuri da solo sul tuo sito.

In fondo al pezzo hai in mano l’export dello stato reale di tutti i tuoi URL, non i mille che il pannello ti fa vedere, e un triage in cinque mosse: quali salvare, quali lasciare dove stanno.

Cosa dice la documentazione, ed è pochissimo

La definizione ufficiale dice tre cose e finisce lì. Testuale, dalla guida al rapporto Indicizzazione delle pagine: «La pagina è stata sottoposta a scansione da Google, ma non indicizzata. In futuro la pagina potrebbe essere indicizzata o meno, ma non è necessario inviare di nuovo l’URL per la scansione».

L’abbiamo letta. Non l’abbiamo messa in indice. Il futuro è aperto. Tutto qui, e da queste due righe è nata una letteratura da seimila parole a pezzo.

Quello che quella pagina non dice conta più di quello che dice. Non lo chiama errore: sta nella tabella «Perché le pagine non sono indicizzate», insieme ai motivi legittimi come il noindex e i duplicati. Non dà nessun tempo, né minimo né massimo. La parola «qualità», nel testo completo della versione italiana, non compare mai. Il collegamento fra qualità e indicizzazione esiste davvero, ma sta scritto altrove, e lo dice anche Mueller a voce: ci arriviamo con le date.

Resta l’ultima frase, quella sul reinvio: la più disattesa di tutte. Google dice che rimandare l’URL non serve. Il settore si divide in tre posizioni opposte, in quattro lingue.

Il quadro generale, come Google scopre le pagine, le scansiona, le rende e le indicizza, sta nella guida su come funziona l’indicizzazione. Questo pezzo lavora su un solo stato.

Crawled currently not indexed e gli altri tre stati che vengono confusi

Buona parte di quello che chiami «crawled not indexed» non lo è. Nel rapporto convivono quattro etichette: quattro momenti diversi nella vita di un URL, con soluzioni diverse. Due non richiedono nemmeno di aprire il tuo testo.

Vanno lette carattere per carattere: sono le stringhe che trovi nel pannello e quelle che l’API ti restituisce.

«Rilevata» ha una sua definizione, e dice una cosa precisa: «La pagina è stata rilevata da Google, ma non è stata ancora sottoposta a scansione. In genere questo significa che Google ha cercato di eseguire la scansione dell’URL, ma l’operazione sembrava sovraccaricare il sito, quindi ha dovuto riprogrammare la scansione». Sovraccaricare il sito. Non «i tuoi contenuti sono deboli»: il server che non ce la fa. È anche l’unico dei quattro che la guida al crawl budget nomina fra i suoi casi, e su «Pagina scansionata» quella guida tace del tutto.

«L’URL è sconosciuto a Google» sta nella guida al Controllo URL, non nel rapporto: «Significa che Google non l’ha mai rilevato in passato». Se ti esce questa, il problema è a monte di tutto il resto: nessuno gli ha mai detto che quella pagina esiste.

Fuori tabella, la confusione che costa di più. Se nell’export il campo googleCanonical contiene un altro tuo URL, non sei in questo stato: sei dentro un problema di canonicalizzazione, e si risolve guardando quale URL Google sceglie come canonico. Il quarto stato ha una pagina sua: se ti escono URL con noindex a sorpresa, leggi l’istruzione noindex e poi chiediti chi te l’ha messa, che nove volte su dieci è un plugin.

Cinque cause tecniche da escludere prima di parlare di qualità

Prima di aprire il file dei testi, escludi cinque cause tecniche. Producono lo stesso identico stato senza che nessuno abbia giudicato la qualità di niente, e la prima non compare in nessuna delle venti pagine che ho aperto sul tema fra italiane e inglesi.

1. Il limite di 2 MB di HTML. Gary Illyes, nel post sul limite di 2 MB del 31 marzo 2026: «Any bytes that exist after that 2MB threshold are entirely ignored. They aren’t fetched, they aren’t rendered, and they aren’t indexed». Il taglio cade sul sorgente che il server consegna, non sulla pagina renderizzata, e nel conteggio entrano anche le intestazioni HTTP di richiesta. Un template che si porta dietro mezzo catalogo dentro un JSON inline arriva alla soglia molto prima di quanto sembri. Si pesa il sorgente grezzo: DevTools mostra il DOM già renderizzato, che è un’altra pagina. Nello stesso post Google scrive che «for the vast majority of the web, a 2MB HTML payload is massive, and you will never hit this limit»: è un controllo da due minuti proprio perché quasi sempre lo escludi, e quando invece lo trovi hai finito lì.

2. WAF, rate limiting, geoblocking. Un firewall applicativo che scambia una raffica di richieste da IP Googlebot legittimi per un attacco e le blocca. Lo descrive Google stessa, in Search Off the Record 112. Splitt: «sometimes we’ve seen CDNs, for example, or hosting providers, they have some kind of bot protection, and maybe they turn it on when there’s a lot of crawling happening. And depending on how this bot protection is set up, it can happen that suddenly your CDN or your website host serves 404 or 410 or 403 or something». E poche righe prima: «this is something that you do see in the page indexing report as well». La delimitazione onesta è questa: Google descrive il meccanismo e i codici sbagliati che il CDN restituisce, non lo lega a questo stato in particolare. Il rimedio, la whitelist a livello di server, e la soglia indicativa intorno alle mille pagine vengono invece da chi ci mette le mani: Max Valle, 16 agosto 2026, e un hoster tedesco che non posso nominare, il che significa che la soglia va presa come ordine di grandezza e non come numero. Si controlla così: Google pubblica in JSON gli intervalli IP dei suoi crawler, li scarichi, li incroci con i log del server e conti quante volte hai risposto 403 o 429 a qualcuno che era davvero Googlebot.

3. Rendering JS incompleto. Il caso da manuale è un Disallow: /*?* nel robots.txt che affama CSS e JavaScript per sbaglio, perché quei file hanno un parametro di versione nell’URL. Google renderizza una pagina spoglia e giudica quella: tu vedi l’articolo, lui vede un titolo e tre righe di boilerplate. Si controlla sull’HTML renderizzato del test dal vivo, mai sul sorgente.

4. Il canonico scelto da Google. Nel Controllo URL: se il canonico scelto è vuoto, quella pagina in indice non ci è mai entrata. Se è un altro tuo URL, Google l’ha accorpata a un’altra tua pagina, ed è un problema diverso con una soluzione diversa.

5. Il campo che in inglese si chiama «Source». «Website» vuol dire causa lato tuo, su cui puoi agire. «Google systems» vuol dire causa lato loro, su cui non puoi. Mezzo secondo di lettura, e sai se stai per passare un weekend a riscrivere pagine per niente. È il più veloce dei cinque, e nelle nove pagine italiane del campione non lo guarda nessuno. Come perno diagnostico non compare nemmeno in nessuna delle undici pagine inglesi che ho aperto; l’unico che ci parte è un SEO giapponese.

L’ordine non me lo sono inventato. Nella stessa trascrizione, del 16 luglio 2026, Mueller pone due condizioni insieme, non una: «[…] when you recognize a bigger pattern like this, like Google is not indexing a lot of your pages and there’s no technical reason, you almost need to take a step back and think about the quality overall». Se la seconda condizione non è soddisfatta, il discorso sulla qualità non si apre nemmeno.

Il pannello ti mostra mille URL, e poi c’è l’API

Il pannello non ti fa vedere il tuo problema, e lo scrive per esteso: «Tieni presente che l’elenco degli URL di esempio nel report è limitato a 1000 elementi e non è garantito che siano mostrati tutti gli URL con un determinato stato, anche se sono meno di 1000». Mettiamo duemila URL in quello stato: l’interfaccia te ne mostra al massimo mille, scelti da lei. Qualunque conclusione tiri da quella lista è un sondaggio su un campione che non hai scelto tu.

Da qui in poi si lavora sull’export, e l’export lo fa la URL Inspection API.

Due numeri prima di partire, perché cambiano il piano. La pagina dei limiti fissa la quota a 2.000 richieste al giorno e 600 al minuto, per sito. Duemila al giorno vuol dire un catalogo da 40.000 URL controllato in venti giorni, e al ventesimo il catalogo si è già mosso sotto i piedi.

Il collo di bottiglia si allarga, e non è un trucco da forum: il limite è per proprietà verificata, non per dominio. L’osservazione è di Juan González Villa, la conferma pubblica arriva da Daniel Waisberg, che in Google ci lavora. Verifichi https://esempio.it/blog/ e https://esempio.it/prodotti/ come proprietà separate e la quota si moltiplica per quante ne verifichi.

Il setup sono quattro passi: progetto su Google Cloud, Search Console API abilitata, service account con la sua chiave JSON scaricata, e il passaggio dove si blocca praticamente chiunque. L’indirizzo email del service account va aggiunto come utente della proprietà in Search Console. Se lo salti, le credenziali sono perfette e l’API ti risponde 403 lo stesso.

Un’avvertenza, prima dello script. Se hai passato l’ultima settimana a cliccare «Richiedi indicizzazione» su cinquanta URL, hai già contaminato la colonna dell’ultima scansione: l’export ti dirà che quelle pagine sono state visitate ieri, ed è vero, ma sei stato tu. Prima di misurare, smetti di toccare.

Lo script Python che interroga la URL Inspection API

Due blocchi di Python. Il primo interroga la URL Inspection API e scrive un CSV, il secondo lo conta.

# pip install google-api-python-client google-auth
import csv, time
from google.oauth2 import service_account
from googleapiclient.discovery import build
from googleapiclient.errors import HttpError

SITE   = "sc-domain:esempio.it"      # oppure "https://esempio.it/" con lo slash finale
KEY    = "service-account.json"
SCOPES = ["https://www.googleapis.com/auth/webmasters.readonly"]

CAMPI = ["verdict", "coverageState", "lastCrawlTime", "robotsTxtState",
         "indexingState", "pageFetchState", "userCanonical",
         "googleCanonical", "crawledAs"]

creds = service_account.Credentials.from_service_account_file(KEY, scopes=SCOPES)
api   = build("searchconsole", "v1", credentials=creds, cache_discovery=False)

def ispeziona(url, tentativi=5):
    body = {"inspectionUrl": url, "siteUrl": SITE, "languageCode": "it"}
    for n in range(tentativi):
        try:
            r = api.urlInspection().index().inspect(body=body).execute()
            return r["inspectionResult"]["indexStatusResult"]
        except HttpError as e:
            if e.resp.status in (429, 500, 503):
                time.sleep(5 * 2 ** n)       # 5, 10, 20, 40, 80 secondi
                continue
            raise
    return {"coverageState": "NON CONTROLLATO: quota o errore server"}

with open("urls.txt", encoding="utf-8") as f:
    urls = [r.strip() for r in f if r.strip()]

with open("stato.csv", "w", newline="", encoding="utf-8") as out:
    w = csv.writer(out)
    w.writerow(["url"] + CAMPI)
    for u in urls:
        r = ispeziona(u)
        w.writerow([u] + [r.get(c, "") for c in CAMPI])
        time.sleep(0.12)                     # ~500 al minuto, sotto il tetto di 600

Quattro note, e sono quelle che ti risparmiano il primo giro a vuoto.

• sc-domain: per le proprietà di dominio, URL completo con lo slash finale per quelle a prefisso. Sbagliare qui produce un 403 che sembra un problema di permessi e non lo è.
• Il valore NON CONTROLLATO resta dentro il CSV. Un URL che non sei riuscito a controllare non è un URL senza problemi, ed è la differenza fra un conteggio e una favola: al giro dopo lo ricontrolli.
• urls.txt si costruisce dalla sitemap, non dall’esportazione del rapporto, che è limitata al campione di prima. Se la sitemap è incompleta lo sarà anche la misura: come si costruisce la sitemap.
• L’API restituisce lo stato indicizzato, cioè quello che Google ha già in archivio, non un test dal vivo.

Poi c’è il punto tecnico che divide uno script che regge da uno che si rompe in silenzio fra sei mesi. Nel riferimento dei campi, verdict è un enum stabile: PASS, NEUTRAL, FAIL, e il nostro stato è NEUTRAL. coverageState invece è testo libero localizzato: con languageCode: 'it' arrivano le etichette italiane, in inglese ne arrivano altre, e se Google rinomina un’etichetta il tuo if smette di funzionare senza dire niente a nessuno. Per questo si raggruppa per coverageState invece di confrontarlo con una stringa scritta a mano.

Il conteggio:

import csv
from collections import Counter

righe = list(csv.DictReader(open("stato.csv", encoding="utf-8")))
for stato, n in Counter(r["coverageState"] for r in righe).most_common():
    print(f"{n:6}  {stato}")

Questo output è il momento in cui vedi la forma vera del tuo problema. Quasi mai somiglia a quella che avevi in testa.

Leggere il CSV: il triage in cinque mosse per capire cosa si risolve e cosa no

Il CSV si legge in cinque passaggi, in quest’ordine, e i primi due di solito tolgono di mezzo metà delle righe.

Zero, la data. Prendi il giorno in cui il numero è schizzato e mettilo accanto alla dashboard degli aggiornamenti di Google, che pubblica nome, data d’inizio e durata esatta di ogni update: il December 2025 core update è durato 18 giorni e 2 ore, il May 2026 core update 11 giorni e 21 ore. Serve a escludere: una coincidenza di date chiude un’ipotesi, non ne apre una. La differenza è tutta lì: nei post di Google sui core update l’indicizzazione non viene mai nominata, quindi «è colpa del core update», con le fonti Google in mano, non sta in piedi. Se il crollo cade in una settimana in cui non si muoveva niente, hai chiuso un’ipotesi in trenta secondi.

Uno, raggruppa per coverageState. Quanto di quello che chiamavi «scansionata non indicizzata» è in realtà noindex, canonicalizzazione o «Rilevata»? Queste righe escono adesso e vanno su tre binari diversi.

Due, googleCanonical vuoto contro valorizzato. Vuoto significa che quella pagina in indice non è mai entrata. Valorizzato con un altro tuo URL significa che Google l’ha accorpata, e stai leggendo il rapporto sbagliato per il tuo problema.

Tre, ordina per lastCrawlTime. Una pagina scansionata tre giorni fa e una scansionata a marzo raccontano due storie diverse, anche se nel rapporto stanno sulla stessa riga.

Quattro, cerca il pattern nell’URL prima di cercarlo nel testo. Se l’ottanta per cento delle righe contiene ?filtro=, /tag/ o /page/2/, non hai un problema di qualità: hai una navigazione che genera URL, e Google sta facendo esattamente il suo mestiere. È il senso della frase di Martin Splitt nella stessa trascrizione, «look at it as a detection tool for changes or patterns in the site». Un rilevatore di cambiamenti, non un inventario da sistemare.

È la pagina o è il sito? Le fonti si contraddicono

A chi glielo chiede in modo secco, Google risponde «Sometimes». Alla lettera: in Search Off the Record 112 Splitt chiede se questo stato sia «often or only sometimes a sign of a quality issue», e Mueller risponde «Sometimes». Non «sì». E la frase dopo, invece di attenuare, va nella direzione opposta: «So it’s definitely the case if our systems are seriously worried about the quality of a website, that they will reduce the number of pages that they index […] And then you’ll see things like “crawled not indexed” or “discovered not indexed”». Il collegamento c’è, ed è Google a dirlo nella stessa battuta. Quello che non c’è è l’automatismo: «Sometimes» resta la risposta alla domanda «often or only sometimes».

La vulgata, italiana e inglese, dice un’altra cosa: che sia un giudizio di qualità sul sito intero. Quella frase non è inventata. È vera a metà, per un motivo molto concreto: viene da una citazione tagliata a metà.

Le fonti, affiancate e datate, ognuna con la sua portata.

• 8 giugno 2019. Mueller, riportato in tedesco da Christian Kunz: «nicht indexierte URLs [fließen] aber überhaupt nicht in die Qualitätsbewertung der Website ein», gli URL non indicizzati non entrano affatto nella valutazione qualitativa del sito. La traduzione è mia, e la catena conta: è una frase di un Googler riportata da un terzo, e non ha il peso di un documento Google.
• 28 giugno 2021. Mueller, su Twitter: «It’s not an issue with “that page”, it’s more site-wide». È la mezza citazione su cui poggia mezza letteratura del settore.
• 1 luglio 2021, lo stesso thread su Twitter, tre giorni dopo: «It’s not meant to highlight low quality content issues». E poco oltre: «I wouldn’t over-index on quality». Delle venti pagine del campione, questa seconda metà non la cita nessuna.
• 20 settembre 2022. Mueller: «There is no percentage». Peccato che in un office hours precedente avesse dato l’esempio «200 pagine, ne indicizziamo 180», che è una percentuale. Google è fonte primaria della propria smentita.
• 28 settembre 2023. Mueller: «A page can be of high quality and still not be indexed, it’s not guaranteed». Questa riga, da sola, taglia le gambe a metà dei rimedi in circolazione.
• Maggio 2024. Illyes alla SERP Conf, in una trascrizione di Search Engine Journal, quindi non una fonte primaria anche se le parole sono sue: «if the number of these URLs is very high that could hint at general quality issues». Fin qui la citano tutti. Quella dopo, nelle stesse venti pagine, non la cita nessuna: «in the vast majority of cases it’s a technical thing».
• 16 luglio 2026. SOTR 112, la condizione doppia già vista: pattern ampio e nessuna causa tecnica.

In fila, queste fonti non si contraddicono su tutto. Si contraddicono su quanto in là si può spingere l’affermazione, che è precisamente il punto dove la letteratura scivola.

La formulazione più utile di tutte non è di Mueller: è di Splitt, che gira la domanda dalla parte dell’indice. «There’s so much other stuff that is just as good. So why would we add it to the index?». E poi: «what’s the value of this version of it being in the index?». Non «la tua pagina fa schifo», ma «di questa roba qui l’indice ha già quindici copie, la sedicesima che ci aggiunge?». È una domanda a cui puoi rispondere. «Migliora la qualità» non lo è.

Sull’AI la clausola che il settore dimentica la mette Mueller, nella stessa battuta della condizione doppia: il giudizio non è dell’algoritmo, è di chi legge. «people look at this AI-generated site and they’re like, “Well, I can tell this is AI generated. There’s nothing unique or valuable that is available here for me”. That’s not to say that all AI-generated content is bad».

Due dati per sgonfiare l’ansia, dalla stessa trascrizione. Splitt: «there’s no such thing as a ratio between indexed and non-indexed pages. I mean there is, but like it doesn’t matter. I’ve seen so many healthy websites that have like a million non-indexed pages and like half a million that are in the index and they are doing perfectly fine». E Mueller, parlando della documentazione per sviluppatori di Google: «I think it’s something like 5% of the pages are indexed». Il cinque per cento. Loro.

Una nota sulle assenze, con il campione attaccato: senza campione un’assenza non vale niente. Nei 1.732 post del blog Search Central dal 2005 a oggi, enumerati e grepati, la stringa «currently not indexed» non compare mai. Google non ha mai scritto un post su questo stato, non ha mai dichiarato una soglia percentuale, non ha mai pubblicato una tempistica di recupero.

Il collegamento fra qualità e indicizzazione però esiste, e va detto dove sta davvero, perché non sta dove lo cercano tutti. Sta in come funziona la Ricerca Google, che scrive «L’indicizzazione non è garantita» ed elenca fra i motivi «La qualità dei contenuti della pagina è bassa». Non sta invece nella guida «Creare contenuti utili e affidabili», che è quella che tutti linkano su questo tema e che parla di ranking, non di indicizzazione.

Reinviare l’URL: tre risposte opposte in quattro lingue

La documentazione dice che non serve, e il settore si divide in tre.

La terza posizione è la più articolata, e nelle undici pagine inglesi non compare. Uruñuela la costruisce leggendo un paper di Google sui segnali rumorosi: se chiedi l’indicizzazione di una pagina che poi non viene indicizzata, hai mandato un segnale sbagliato, e ripeterlo insegna al sistema a fidarsi meno di quel segnale quando arriva da te. È un ragionamento, non una misurazione, e va tenuto per quello che è.

Con la documentazione in mano, in piedi restano la seconda e la terza. La prima riga della definizione ufficiale è già chiara da sola: «non è necessario inviare di nuovo l’URL per la scansione».

Se poi non ti convince nessuna delle tre, resta comunque un motivo pratico per smettere: ogni reinvio manuale sporca lastCrawlTime nell’export. Ti stai togliendo con le tue mani la colonna con cui misuri il problema.

Cosa funziona davvero: un caso solo, e non dice cosa ha funzionato

Di casi documentati con numeri veri, prima e dopo, e una fonte datata, ne esiste uno. E la fonte più linkata sul tema, un articolo di Moz del 2020, chiude con «a significant decrease» e zero cifre.

Araujo su Search Engine Land, 12 maggio 2026, su fatti del gennaio 2023: URL in questo stato da 513.369 a circa 220.000 in dodici settimane, meno 57%. Soft 404 da circa 120.000 a meno di 20.000. Pagine indicizzate in Germania da circa 150.000 a 370.748. Il limite: dominio anonimizzato e almeno cinque variabili cambiate insieme. Dimostra che si può uscire. Non dice cosa abbia funzionato.

Il secondo caso che il settore gli affianca, quello a variabile singola che finisce in ricaduta, qui non entra: circola senza data, e senza data non è una fonte, è un aneddoto. Uno.

Poi c’è il numero che vale l’articolo. Lo studio di IndexCheckr misura la cosa giusta, cioè pagine già non indicizzate sottoposte a strumenti di indicizzazione: su 33.930 pagine, indicizzate dopo la submission 9.965, cioè 29,37%. Rimaste fuori, 70,63%. I due limiti stanno accanto al numero e non in nota. Primo, la pagina non dichiara la metodologia dello studio, né come sia composto il campione né come sia stata verificata l’indicizzazione: non si sa se i sedici milioni di pagine dello studio generale siano il parco clienti dello strumento, nel qual caso il campione è auto-selezionato verso chi ha già un problema di indicizzazione. Secondo, chi pubblica vende monitoraggio dell’indicizzazione. Il contro-argomento onesto è che vende monitoraggio e non indicizzazione, quindi non ha interesse a far sembrare inefficaci gli indexer, ed è l’unico numero pubblico che misuri il caso giusto.

Il non recupero, invece, è documentatissimo. Novanta pagine e zero indicizzate dopo interventi su tecnica e contenuto. Ventisei backlink e tre pagine su 160. Centomila pagine crollate a seimila, con la sitemap risottomessa che risponde «Success». E il caso che demolisce il consiglio più ripetuto del settore: una pagina con 175 link interni da 340 pagine diverse che non rientra «no matter what I change».

Sette thread della community di Google e due di Reddit. Recuperi credibili con una tempistica dichiarata: uno su nove, e cade sopra un core update, quindi nemmeno quello è isolabile. In quattro casi su sette l’autore non replica più.

Il dato migliore è francese, e cambia se cambi la definizione

Le due cifre sono «quattro volte» e «più 45%», e vanno lette insieme: stesso gruppo di ricerca, due definizioni diverse di «indicizzata».

Olivier Duffez e Fabien Faceries, con My Ranking Metrics. Settembre 2021, circa 3.000 siti: le pagine con QualityRisk pari a 0 hanno quattro volte più probabilità di essere indicizzate rispetto a quelle con QualityRisk sopra 20. Nel 2023, su centinaia di siti, con una definizione diversa di «indicizzata» (apparsa almeno una volta in SERP negli ultimi dodici mesi): più 45%.

Da 4× a +45% cambiando cosa vuol dire «indicizzata». È il miglior dato quantitativo che ho trovato sul legame fra qualità e indicizzazione, ed è anche la miglior dimostrazione che qui una percentuale senza la sua definizione non vale niente. Quando qualcuno ti dà un numero su questo stato, la prima domanda è sempre la stessa: che cosa chiami «indicizzata»?

Duffez lascia anche una formula, che in inglese non ho trovato da nessuna parte e si calcola in due minuti:

errore = (ESPLORATE + RILEVATE) / (ESPLORATE + RILEVATE + INDICIZZATE)

La metà operativa è il filtro, e senza quella la formula mente. In Search Console devi passare da «tutte le pagine note» a «tutte le pagine inviate». Altrimenti al denominatore finisce tutta la spazzatura che il sito genera da solo, e il numero che ottieni misura la tua navigazione a faccette, non il tuo problema.

Cosa non fare

Sei mosse che il settore consiglia e che qui non trovi, ognuna con il suo motivo.

Non potare a caso. Le parole di Google su questo sono insolitamente nette. Nella guida sui contenuti utili: «Are you adding a lot of new content or removing a lot of older content primarily because you believe it will help your search rankings[…] (No, it won’t)». Danny Sullivan, agosto 2023: «Are you deleting content because you believe Google doesn’t like “old” content? That’s not a thing!». Mueller: «Just deleting things blindly doesn’t improve your SEO». I 404 e i 410 Google li consiglia per l’efficienza di scansione, che è un’altra faccenda. E c’è una condizione che di solito cade per strada: Sullivan lo dice per chi ha un sito enorme («if you have a massive site», e allora «we’re better able to crawl other content»). Sui siti normali quel beneficio non è mai stato promesso. Uno studio controllato sull’efficacia della potatura contro questo stato non l’ho trovato.

Non comprare strumenti di indicizzazione. Il 70,63% di poco fa sta tutto qui. Degli otto vendor che ho aperto, le promesse vanno dall’80 al 99,4%, e la discrepanza si spiega: testano backlink freschi su siti di terzi, non pagine tue che Google ha già visitato e valutato. Due su otto ammettono di vendere una visita di Googlebot e non l’ingresso nell’indice, e sono gli unici onesti del gruppo.

Non cliccare «Convalida correzione» aspettandoti che risolva. Mueller in SOTR 112, quando la decisione è dell’indice: «it’s not something that you necessarily fix yourself». E Splitt cita Hillel, del team di Search Console: «Oh, I wish people would not look at it as a list of things to fix».

Non cambiare dominio. Nei thread pubblici è la mossa di chi ha rinunciato, raccontata come soluzione.

Non trattare il rapporto come un punteggio. Splitt lo dice così: «Don’t think that the ratio between indexed and non-indexed is some sort of like quality measure or some sort of score that you need to look at». Non nega che il rapporto esista, nega che significhi qualcosa, e lo conferma il cinque per cento che Google dichiara su sé stessa.

Non attribuirlo al crawl budget senza aver letto quale stato la guida nomina. Ne nomina uno, ed è «Rilevata». C’è pure una ragione logica prima che documentale: se la pagina è stata scansionata, il budget di scansione l’hai già speso.

Quando lo stato è normale e va lasciato lì

Google scrive nero su bianco che non devi aspettartelo: «non dovresti aspettarti che vengano indicizzati tutti gli URL del tuo sito, ma soltanto le pagine canoniche».

In quello stato ci stanno benissimo filtri e faccette, paginazione, archivi tag, varianti di prodotto, risultati della ricerca interna. Per queste la soluzione non è indicizzarle: è deciderne il destino, cioè noindex, blocco in robots.txt o niente, ma consapevolmente.

Due appoggi. Il cinque per cento della documentazione per sviluppatori di Google, dichiarato da Mueller. E il 15 dicembre 2019, raccontato da un SEO giapponese, quando Google riclassificò in massa pagine da questo stato a indicizzate: lo stato si svuotò per un cambio di contabilità, non perché i siti fossero migliorati nella notte. Se quel numero può scendere per una modifica interna a Google, non è il termometro della salute del tuo sito.

Un’euristica, non una regola, e viene dalla stessa fonte giapponese: il rapporto elenca gli URL in ordine di importanza, quindi se quelli in cima sono ignorabili, di norma lo sono anche quelli sotto.

La checklist

Nell’ordine in cui si fanno.

• Prendi la data del crollo e confrontala con la dashboard degli aggiornamenti: la data serve a chiudere ipotesi, non ad aprirne.
• Pesa l’HTML sorgente di un campione di pagine e verifica che stia sotto i 2 MB.
• Controlla nei log che il sito non stia rispondendo 403 o 429 a IP legittimi di Googlebot.
• Guarda l’HTML renderizzato dal test dal vivo.
• Leggi il campo «Source»: se dice «Google systems», la causa è loro.
• Esporta tutti i tuoi URL con l’API.
• Raggruppa per coverageState e togli dal mucchio noindex, canonicalizzazione e «Rilevata».
• Separa googleCanonical vuoto da valorizzato.
• Cerca il pattern nell’URL prima che nel testo.
• Decidi quali URL non devono essere indicizzati e chiudi la partita.
• Solo sul resto, e solo se il pattern è ampio e non c’è nessuna causa tecnica, si guarda la qualità.
• Rimisura fra trenta giorni con lo stesso script, e confronta i due CSV.

Domande frequenti