Bloccato da robots.txt (stato GSC)

TL;DR — “Bloccato da robots.txt” in Search Console significa che Google ha trovato la pagina ma non l’ha letta, perché il tuo file robots.txt dice ai crawler di restare fuori. Di solito è intenzionale e va bene: è il risultato normale di un blocco, non un errore. È un problema solo se hai bloccato una pagina che volevi davvero vedere su Google.

Che cosa significa questo stato

Apri il rapporto Indicizzazione delle pagine in Google Search Console e fai clic sulla voce “Blocked by robots.txt,” (traduzione) «Bloccato da robots.txt,» (“Bloccato da robots.txt”): vedrai l’elenco degli URL che Google ha scelto di non indicizzare. Il motivo è semplice: Google ha trovato quegli URL, ma il file robots.txt del sito dice ai crawler che non possono recuperarli. Evidence for this claim Google reports Blocked by robots.txt when crawling is disallowed and warns that this does not guarantee the URL cannot be indexed by other means. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report L’etichetta segnala il blocco del crawl; non garantisce che l’URL non possa mai essere indicizzato tramite altri segnali.

La prima cosa che dico è: non farti prendere dal panico. Questo stato è di solito intenzionale. Se tu (o il CMS o un plugin) hai bloccato qualcosa deliberatamente — risultati di ricerca interni, URL di navigazione faccettata, un percorso di staging, URL di carrello e checkout — vederlo qui è esattamente ciò che dovrebbe accadere. Google sta confermando che il blocco ha funzionato, non sta segnalando un errore.

L’idea da tenere a mente

robots.txt controlla il crawl, non l’indicizzazione. Sono due cose diverse. Bloccare una pagina in robots.txt impedisce a Google di leggerla; Evidence for this claim Google says robots.txt manages crawler access and is not a mechanism for keeping a page out of Google. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: robots.txt introduction non la cancella da Google e non è un modo per rimuoverla dalla Ricerca. Ho provato personalmente l’esperimento “che cosa succede quando blocchi una pagina”: ne parlo nella scheda Advanced, ma il punto essenziale è: un blocco ferma il crawl, punto.

È un problema?

Fai un solo controllo: volevi bloccare questi URL?

• Sì, intenzionalmente → lascia tutto com’è. Funziona come previsto.
• No, quella pagina dovrebbe essere su Google → questo è l’unico caso da correggere. Trova la regola del tuo robots.txt che intercetta l’URL e rimuovila o allentala, poi richiedi l’indicizzazione.

Potresti vedere anche uno stato correlato ma diverso: “Indicizzato nonostante il blocco da robots.txt”. Quello è un avviso, non un’esclusione: significa che Google ha indicizzato comunque un URL bloccato (di solito perché altre pagine lo collegano). Stessa causa, esito opposto. Se stai osservando quello, è trattato in un articolo separato.

Un’altra cosa che robots.txt non può fare è mantenere qualcosa privato. È una richiesta, non un controllo degli accessi: i bot corretti lo rispettano, ma nulla li obbliga e nulla impedisce all’URL di comparire altrove (un link, uno screenshot o uno scraper che ignora completamente robots.txt). Se una pagina contiene informazioni sensibili, proteggila con accesso o password, non con un disallow.

L’errore da evitare

Molte persone provano a rimuovere una pagina da Google bloccandola in robots.txt, a volte aggiungendo anche un tag noindex per sicurezza. Non funziona e si ritorce contro di loro. Se Google non può sottoporre la pagina a crawl, non può mai vedere il noindex, quindi la pagina può restare su Google. Per togliere davvero una pagina dalla Ricerca devi fare l’opposto: lasciare che Google esegua il crawl e aggiungere noindex.

Vuoi la versione completa — come trovare la regola di blocco esatta, perché la combinazione noindex + disallow è in conflitto e che cosa ha mostrato il mio esperimento — passa alla scheda Advanced.

TL;DR — “Bloccato da robots.txt” è un’esclusione di Indicizzazione delle pagine: Google ha scoperto l’URL ma non l’ha sottoposto a crawl perché robots.txt lo vieta, quindi in questo stato non è indicizzato. È normalmente intenzionale e innocuo: robots.txt governa il crawl, non l’indicizzazione, quindi un disallow non è mai uno strumento per deindicizzare. Non confonderlo con l’avviso “Indicizzato nonostante il blocco da robots.txt” (Google ha indicizzato comunque un URL bloccato, di solito tramite link in ingresso). L’errore classico è associare disallow e noindex: Google non può sottoporre a crawl la pagina, quindi non vede il noindex e la pagina può restare indicizzata. Per rimuovere una pagina, consenti il crawl e servi noindex. Tratta questo stato come un bug solo quando hai bloccato un URL che volevi davvero indicizzare.

Che cosa segnala davvero lo stato

Nel rapporto Indicizzazione delle pagine di Search Console, “Bloccato da robots.txt” è uno stato escluso, non un errore e non un avviso. La formulazione di Google è chiara: la pagina “was blocked by your site’s robots.txt file,” (traduzione) «è stato bloccato dal file robots.txt del tuo sito,» (è stata bloccata dal file robots.txt del sito) e Google aggiunge la precisazione importante che questo “does not guarantee that the page won’t be indexed through some other means.” (traduzione) «non garantisce che la pagina non venga indicizzata in altro modo.» Evidence for this claim Google reports Blocked by robots.txt when crawling is disallowed and warns that this does not guarantee the URL cannot be indexed by other means. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report In una riga c’è tutto l’argomento: prosegui qui sotto.

Meccanicamente: Googlebot sa che l’URL esiste (l’ha trovato tramite un link, una sitemap o la cronologia), prova a rispettare le tue regole, incontra un Disallow corrispondente e si ferma. Senza fetch non c’è contenuto da indicizzare, quindi l’URL resta in questo gruppo escluso. È il risultato previsto di un disallow: la maggior parte degli URL qui dovrebbe trovarsi qui.

Il crawl non è l’indicizzazione: perché un disallow non deindicizza

Google documenta robots.txt come controllo dell’accesso al crawl, non come meccanismo affidabile di rimozione. Evidence for this claim Google says robots.txt manages crawler access and is not a mechanism for keeping a page out of Google. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: robots.txt introduction

Questo è il punto portante dell’intero stato. robots.txt è un controllo del crawl. Google dice esplicitamente che “non è un meccanismo per tenere una pagina web fuori da Google”. Bloccare un URL impedisce il fetch, ma non rimuove l’URL dall’indice e non è uno strumento di deindicizzazione.

Come ho scritto nel mio articolo Ahrefs sullo stato gemello: «crawling e indicizzazione sono due cose diverse.» Una pagina bloccata può comunque finire nell’indice se altre pagine la collegano: Google non può vedere il contenuto e non può vedere neppure il noindex che hai provato ad aggiungere. Da qui nasce l’errore più comune di chi arriva a questo rapporto.

”Bloccato da robots.txt” vs “Indicizzato nonostante il blocco da robots.txt”

Questi due stati vengono continuamente confusi, ma hanno la stessa causa e risultati opposti:

Se stai guardando la versione di avviso — un URL bloccato che è stato comunque indicizzato, mostrato come URL nudo senza descrizione — si tratta del caso “indicizzato nonostante il blocco” ed è trattato nell’articolo dedicato. Questo articolo riguarda l’esclusione semplice: bloccato e non indicizzato.

Per gli URL di servizio, “indicizzato comunque” spesso non è motivo di preoccupazione. John Mueller, rispondendo a un proprietario di sito i cui URL WooCommerce ?add-to-cart= apparivano come indicizzati nonostante il blocco, ha detto che non serve indicizzare quegli URL, che bloccarli con robots.txt va bene e che, anche se vengono “indicizzati” mentre sono bloccati, è improbabile che compaiano davvero nella Ricerca a meno che qualcuno esegua una query molto specifica su quegli URL, cosa che gli utenti reali non fanno.

Il conflitto noindex + disallow (la correzione n. 1 che si ritorce contro)

Ecco la trappola. Qualcuno vuole far sparire una pagina, quindi la mette in Disallow in robots.txt e aggiunge anche un tag meta noindex: cintura e bretelle. Non funziona, perché le due istruzioni si contraddicono.

Google enuncia direttamente la regola: “For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file, and it has to be otherwise accessible to the crawler.” (traduzione) «Perché la regola noindex sia efficace, la pagina o risorsa non deve essere bloccata da un file robots.txt e deve essere altrimenti accessibile al crawler.» Se la pagina è vietata, Google non la sottopone mai a crawl, non vede il noindex e la pagina può restare indicizzata. Come ho scritto nel mio articolo su “Indicizzato nonostante il blocco da robots.txt”: se Google non può eseguire il crawl di una pagina, non vedrà il tag noindex e potrebbe indicizzarla comunque perché ha dei link.

Quindi la sequenza per deindicizzare è l’opposto di ciò che viene spontaneo:

1. Consenti il crawl dell’URL (rimuovi il Disallow).
2. Servi noindex (tag meta robots o header X-Robots-Tag) e lascia che Google ripeta il crawl per vederlo.
3. Lascia la pagina sottoponibile a crawl con noindex presente dopo che è uscita dall’indice. Aggiungere di nuovo il blocco in seguito non è una “mossa finale” sicura: se vieti di nuovo l’URL, Google può perdere la visibilità della regola noindex al crawl successivo e un URL bloccato ma collegato può essere indicizzato dai link di altre pagine, ottenendo proprio l’esito “indicizzato nonostante il blocco” che volevi evitare. Se il crawl budget della pagina rimossa è un problema reale, usa autenticazione o cancellazione (404/410), non tornare a robots.txt.

Per le rimozioni urgenti, lo strumento Rimozioni di Search Console, la protezione con password o la semplice cancellazione della pagina (restituendo 404/410) sono percorsi più rapidi.

Come trovare la regola che blocca l’URL

Tre strumenti, ognuno con un compito diverso: non aspettarti che uno faccia il lavoro degli altri:

• Ispezione URL (GSC). Incolla l’URL specifico. Dice se quell’URL è attualmente bloccato ed è il controllo più rapido per singolo URL.
• Rapporto robots.txt (GSC). Un rapporto di monitoraggio a livello di proprietà del dominio — non un tester modificabile — che mostra i file robots.txt trovati da Google per i tuoi host principali, l’ora dell’ultimo fetch, lo stato del fetch e gli avvisi di parsing, oltre all’azione “richiedi un nuovo crawl” dopo la modifica del file. Dice che Google riesce a vedere il file; non prova i singoli URL contro di esso.
• Un validator robots.txt o il parser robots.txt open source di Google. Per vedere quale riga corrisponde a un URL, passalo a un validator: vince la regola corrispondente più lunga e specifica (e un Allow può prevalere su un Disallow più ampio).

Una volta trovata la riga responsabile, la correzione dipende da dove si trova il tuo robots.txt. Se controlli direttamente il file, rimuovi o correggi la regola (e fai attenzione alla sintassi). Se usi una piattaforma ospitata come Wix, Shopify o Squarespace, potresti dover seguire la documentazione specifica del fornitore per modificarla, perché alcune piattaforme gestiscono robots.txt al posto tuo.

Il mio esperimento: che cosa succede quando blocchi una pagina che volevi indicizzare

La domanda davvero utile è: se blocchi per errore una pagina che dovrebbe posizionarsi, quanto è grave? Ho eseguito direttamente il test. Il 30 gennaio 2023 ho bloccato con robots.txt due pagine che si posizionavano davvero — “Top Bing Searches” e “Top YouTube Searches” — e ho osservato che cosa succedeva.

Il danno era reale, ma inferiore alle mie aspettative. Abbiamo perso una posizione qua e là (alcune keyword sono scese di uno o due posti, un paio sono persino salite) e abbiamo perso tutti i featured snippet di quelle pagine mentre erano bloccate: sono tornati dopo la rimozione del blocco. Anche la presenza nella SERP è peggiorata: Google mostrava «nessuna informazione disponibile per questa pagina» invece della meta description e ha perso i nostri titoli personalizzati. Poiché il risultato appariva peggiore, i clic sono diminuiti più delle impression: ha subito il colpo il CTR.

La mia sintesi di allora fu: “We lost a position here or there and all of the featured snippets for the pages. I expected a lot more impact, but the world didn’t end.” (traduzione) «Abbiamo perso una posizione qua e là e tutti gli snippet in primo piano delle pagine. Mi aspettavo un impatto molto maggiore, ma il mondo non è finito.» E la conclusione che continuerei a sostenere è: non bloccare le pagine che vuoi indicizzare. Fa male. Non quanto potresti pensare, ma fa comunque male. È il modo giusto di inquadrare questo rapporto. Se tutto ciò che c’è nel tuo gruppo “Bloccato da robots.txt” è materiale che volevi bloccare, va bene. Se c’è una pagina importante, falla uscire.

Nota sull’ambito dell’esperimento: entrambe le pagine si posizionavano ed erano indicizzate già prima del blocco, quindi ho misurato che cosa accade quando una pagina indicizzata viene spinta nello stato “indicizzato nonostante il blocco”, non che cosa accade a un URL mai indicizzato che si trova semplicemente in questo gruppo escluso. Se un URL qui non è mai stato indicizzato, sbloccarlo consente soltanto a Google di sottoporlo a crawl e valutarlo normalmente: non ci sono storico di featured snippet o CTR da perdere, perché non c’erano mai stati.

Il decision tree

• Volevi bloccarlo? → Lascialo così. Funziona come previsto.
• No, vuoi indicizzarlo? → Rimuovi o allenta la regola robots.txt, poi richiedi l’indicizzazione.
• Vuoi che sparisca da Google? → Non usare un disallow. Consenti il crawl + noindex (oppure lo strumento Rimozioni/cancellazione), poi lascia la pagina sottoponibile a crawl: ribloccarla può nascondere di nuovo la regola noindex.
• È un URL bloccato ma indicizzato comunque? → È il caso indicizzato nonostante il blocco, non questo: gestiscilo nell’articolo dedicato.
• La pagina contiene informazioni sensibili o private? → robots.txt non è un controllo degli accessi: è una richiesta che i bot possono ignorare. Usa autenticazione o protezione con password, non un disallow.

Il principio crawl-vs-index è universale: anche Bing rispetta robots.txt per il crawl e, per rimuovere un URL da Bing, usa analogamente lo strumento Block URLs o un noindex su una pagina sottoponibile a crawl, non un semplice disallow.

Per il file nel suo complesso — sintassi, wildcard, posizione e limiti — consulta la guida robots.txt. Per capire come vengono prese a monte le decisioni di indicizzazione, consulta l’hub sull’indicizzazione.

Riepilogo IA

Una sintesi della versione Advanced:

• “Bloccato da robots.txt” = un’esclusione di Indicizzazione delle pagine. Google ha trovato l’URL ma non l’ha sottoposto a crawl perché robots.txt lo vieta, quindi in questo stato non è indicizzato. È il risultato normale di un blocco, di solito intenzionale e innocuo. La voce inglese “Indexed, though blocked by robots.txt.” indica invece l’avviso gemello.
• robots.txt controlla il crawl, non l’indicizzazione. Google dice “is not a mechanism for keeping a web page out of Google.” (traduzione) «non è un meccanismo per tenere una pagina web fuori da Google.» Un disallow ferma il fetch, ma non deindicizza una pagina.
• Non confonderlo con l’avviso “Indicizzato nonostante il blocco da robots.txt”. Stessa causa, esito opposto: un URL bloccato è stato comunque indicizzato, di solito tramite link in ingresso. Per gli URL di servizio, Mueller dice che in genere va bene: gli URL bloccati e indicizzati raramente compaiono nelle query normali.
• Il primo effetto boomerang: noindex + disallow insieme. Google non può eseguire il crawl di una pagina vietata, quindi non vede il noindex e la pagina può restare indicizzata. La regola di Google è: perché noindex funzioni, la pagina non deve essere bloccata da robots.txt.
• Per rimuovere davvero una pagina: consenti il crawl, servi noindex, lascia che Google ripeta il crawl, poi lascia la pagina sottoponibile a crawl. Ribloccarla può nascondere di nuovo la regola noindex e permettere all’URL di essere indicizzato dai link: l’opposto di ciò che volevi. Nei casi urgenti usa lo strumento Rimozioni, la protezione con password o cancella la pagina.
• Trova la regola di blocco con Ispezione URL (per singolo URL) e un validator robots.txt (quale riga corrisponde: vince la regola più lunga e specifica). Il rapporto robots.txt di GSC monitora lo stato del fetch del file, non prova i singoli URL. La correzione dipende da dove vive il file: sulle piattaforme ospitate potrebbero servire passaggi specifici del fornitore.
• Esperimento di Patrick: il blocco di due pagine già posizionate e già indicizzate è costato una posizione qua e là e tutti i featured snippet, ha peggiorato il risultato nella SERP e ha ridotto i clic più delle impression: «il mondo non è finito», ma «non bloccare le pagine che vuoi indicizzare». Mostra che cosa succede a una pagina indicizzata spinta nello stato “indicizzato nonostante il blocco”; non prevede l’esito di un URL mai indicizzato.
• robots.txt non è un controllo di sicurezza. È una richiesta che i bot possono scegliere di ignorare. Proteggi i contenuti sensibili con autenticazione, non con un disallow.
• Regola decisionale: volevi bloccarlo → lascialo; vuoi indicizzarlo → sblocca + richiedi indicizzazione; vuoi rimuoverlo → consenti il crawl + noindex (e mantienilo sottoponibile a crawl).

Documentazione ufficiale

Documentazione primaria dei motori di ricerca.

Google

• Page indexing report — il rapporto in cui compare questo stato, con le definizioni letterali di “Blocked by robots.txt” e “Indexed, though blocked by robots.txt”.
• Unblock a page blocked by robots.txt — la procedura Google per trovare e correggere la regola che blocca un URL.
• robots.txt report — il rapporto a livello di proprietà del dominio che mostra file robots.txt trovati, stato del fetch, avvisi e richiesta di nuovo crawl.
• Introduction to robots.txt — che cosa fa e non fa robots.txt, compreso il fatto che “non è un meccanismo per tenere una pagina web fuori da Google”.
• Bloccare l’indicizzazione nella ricerca con noindex — la regola secondo cui noindex funziona solo su una pagina che non è bloccata da robots.txt (il conflitto noindex + disallow).

Bing / Microsoft

• Bing Webmaster Tools Help — anche Bing rispetta robots.txt per il crawl; il suo tester robots.txt e lo strumento Block URLs seguono lo stesso principio crawl-vs-index.

Citazioni dalla fonte

Dichiarazioni verificabili di Google. Ogni link è un deep link che porta direttamente al passaggio citato nella pagina sorgente.

Google — che cosa significa lo stato

• “This page was blocked by your site’s robots.txt file. You can verify this using the robots.txt tester. Note that this does not guarantee that the page won’t be indexed through some other means.” (traduzione) «Questa pagina è stata bloccata dal file robots.txt del tuo sito. Puoi verificarlo con il tester robots.txt. Nota che ciò non garantisce che la pagina non venga indicizzata in altro modo.» — Google Search Console Help, Page indexing report. Vai alla citazione

Google — robots.txt controlla il crawl, non l’indicizzazione

• “it is not a mechanism for keeping a web page out of Google.” (traduzione) «non è un meccanismo per tenere una pagina web fuori da Google.» — Google Search Central, Introduction to robots.txt. Vai alla citazione

Google — perché noindex + disallow sono in conflitto

• “For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file, and it has to be otherwise accessible to the crawler.” (traduzione) «Perché la regola noindex sia efficace, la pagina o risorsa non deve essere bloccata da un file robots.txt e deve essere altrimenti accessibile al crawler.» — Google Search Central, «Bloccare l’indicizzazione nella ricerca con noindex». Vai alla citazione

Statistiche e dati di prima parte degni di citazione

• Bloccare pagine che si posizionano: danno reale ma sostenibile. Nel mio esperimento, bloccando con robots.txt due pagine già posizionate e già indicizzate (iniziato il 30 gennaio 2023), le pagine hanno perso una posizione qua e là e tutti i featured snippet, la voce SERP è peggiorata in «nessuna informazione disponibile per questa pagina» e i clic sono diminuiti più delle impression. La mia sintesi: «Mi aspettavo un impatto molto maggiore, ma il mondo non è finito», ma «non bloccare le pagine che vuoi indicizzare: fa male». Questo prova che cosa succede a una pagina indicizzata spinta nello stato “indicizzato nonostante il blocco”; non prevede l’esito di un URL che non era mai stato indicizzato. Fonte
• Gli URL di servizio bloccati che vengono indicizzati sono di solito innocui. Secondo John Mueller, va bene bloccare con robots.txt gli URL di tipo add-to-cart; anche se appaiono come indicizzati nonostante il blocco, è improbabile che compaiano nelle query normali. Copertura
• Quanto è comune il blocco robots.txt sul web — dati sui tassi di blocco che mostrano quali crawler vengono vietati più spesso da circa 140 milioni di siti, dal mio studio con Xibeijia Guan. Fonte

L’errore che definisce questo stato: noindex + disallow

Errore: associare Disallow a noindex per provare a rimuovere una pagina. È l’errore più comune legato a “Bloccato da robots.txt” e vale la pena nominarlo perché sembra una protezione doppia, mentre in realtà si autodistrugge. Qualcuno vuole far sparire una pagina da Google, quindi la mette in Disallow in robots.txt e aggiunge un tag meta noindex per sicurezza. Non funziona. Google enuncia chiaramente la regola: “For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file, and it has to be otherwise accessible to the crawler.” (traduzione) «Perché la regola noindex sia efficace, la pagina o risorsa non deve essere bloccata da un file robots.txt e deve essere altrimenti accessibile al crawler.» Se la pagina è vietata, Google non la sottopone mai a crawl, non vede il noindex e la pagina può restare indicizzata, esattamente l’opposto del risultato voluto. La correzione segue l’istinto opposto: consenti il crawl, poi servi noindex.

Mito: “Un disallow in robots.txt è uno strumento di deindicizzazione.” Non lo è e Google lo dice direttamente: “is not a mechanism for keeping a web page out of Google.” (traduzione) «non è un meccanismo per tenere una pagina web fuori da Google.» Bloccare un URL ferma il fetch, ma non rimuove l’URL dall’indice e una pagina bloccata ma collegata può comunque comparire (è lo stato gemello “Indicizzato nonostante il blocco da robots.txt”). Usa noindex (con crawl consentito) o lo strumento Rimozioni quando l’obiettivo è davvero la rimozione.

Mito: “Tutto ciò che è nel gruppo ‘Bloccato da robots.txt’ è un problema da correggere.” Di solito è il contrario. Questo stato è il risultato previsto di un disallow intenzionale: risultati di ricerca interni, parametri di navigazione faccettata, percorsi di staging. L’unica versione da trattare come bug è un URL che volevi davvero indicizzare e che si trova nell’elenco per errore.

Errore: bloccare una pagina che vuoi far posizionare senza prima verificare il costo. Bloccare una pagina che vuoi far posizionare per “fare ordine” o “risparmiare crawl budget” è più rischioso di quanto sembri. Nel mio esperimento, bloccando due pagine che si posizionavano ho perso tutti i featured snippet mentre erano bloccate e i clic sono diminuiti più delle impression perché la voce SERP era peggiorata in «nessuna informazione disponibile per questa pagina». Le posizioni in sé hanno retto per lo più, ma considera il blocco robots.txt su una pagina importante come una decisione reale, non come una piccola operazione di pulizia.

Checklist di triage per “Bloccato da robots.txt”

Segui questo elenco dall’alto verso il basso quando apri lo stato in Search Console:

• Apri il rapporto Indicizzazione delle pagine e fai clic su “Bloccato da robots.txt” per vedere l’elenco reale degli URL interessati.
• Per ogni URL (o schema di URL), chiediti: volevo bloccarlo?
• Se sì — ricerca interna, navigazione faccettata, staging, carrello/checkout — lascialo così. Per quell’URL lo stato funziona come previsto.
• Se no o non sei sicuro — passa l’URL in Ispezione URL per confermare che sia attualmente bloccato (non una fotografia obsoleta).
• Trova la regola specifica che intercetta l’URL con il robots.txt Tester (o un altro validator robots.txt): vince la regola corrispondente più lunga e specifica e un Allow può prevalere su un Disallow più ampio. Il rapporto robots.txt di GSC osserva il fetch del file, non verifica i singoli URL.
• Conferma che non stai anche affidandoti a noindex sullo stesso URL vietato: la combinazione non può funzionare; se l’obiettivo è rimuovere la pagina, scegli invece consenti-crawl-più-noindex.
• Rimuovi o allenta la regola di blocco (direttamente se controlli robots.txt, oppure tramite la documentazione della piattaforma di hosting se il file è gestito da lei, per esempio Wix, Shopify o Squarespace).
• Richiedi l’indicizzazione dell’URL corretto in Search Console una volta rimosso il blocco.
• Controlla di non confondere questo stato con “Indicizzato nonostante il blocco da robots.txt”: è l’esito opposto (indicizzato comunque) e richiede una correzione diversa.
• Ricontrolla il gruppo tra qualche settimana per confermare che il conteggio segua la direzione attesa (giù per gli URL corretti, piatto per i blocchi intenzionali).
• Se uno di questi URL contiene informazioni sensibili, non affidarti al disallow per tenerlo privato: aggiungi autenticazione o protezione con password.

Segui il decision tree

Rispondi a una domanda alla volta per arrivare alla scelta corretta per un URL nel gruppo “Bloccato da robots.txt”.

I modelli mentali

1. Crawl ≠ indicizzazione. L’intero stato diventa confuso se confondi le due cose. robots.txt controlla il crawl, cioè se Googlebot recupera una pagina. Non controlla direttamente l’indicizzazione, cioè se l’URL finisce nell’indice di Google. Una pagina vietata non viene indicizzata tramite il crawl, ma può comunque essere indicizzata senza contenuto se altre pagine la collegano. Tieni separate le due idee e gran parte di questo stato smette di essere confusa.

2. Il triage con una sola domanda. Prima di fare qualsiasi cosa, chiediti: volevo bloccarlo? Sì → lascialo: funziona come previsto. No → questo è l’unico caso che vale la pena correggere. Una sola domanda classifica correttamente quasi ogni URL del gruppo.

3. Per rimuovere una pagina, inverti l’istinto. La mossa naturale — disallow più noindex, “così sono più sicuro” — è esattamente al contrario. Google non può vedere una direttiva su una pagina che non recupera. La sequenza corretta è l’opposto di quella intuitiva: consenti il crawl, poi servi noindex. Ogni volta che qualcuno pensa a un disallow per far sparire una pagina, questo è il modello da applicare.

4. robots.txt è uno strumento per il crawl budget, non per i risultati di ricerca. Usalo per tenere i bot lontani da spazi URL di basso valore o infiniti (ricerca interna, faccette, staging), così il crawl si concentra sulle pagine che vuoi far trovare, non come leva per decidere che cosa appare nei risultati. Quel lavoro spetta a noindex, protezione con password o cancellazione.

Misura il conteggio del gruppo, non solo la sua esistenza

Il numero da osservare è quanti URL si trovano nella riga “Bloccato da robots.txt” del rapporto Indicizzazione delle pagine nel tempo: una singola fotografia non dice se una correzione ha funzionato o se stanno comparendo nuovi blocchi involontari.

Conteggio del gruppo “Bloccato da robots.txt” nel tempo

• Metrica — il numero di URL nella voce “Bloccato da robots.txt” del rapporto Indicizzazione delle pagine di GSC, monitorato nel tempo.
• Che cosa indica — se il gruppo si comporta come previsto. Per gli URL che blocchi intenzionalmente (ricerca interna, faccette, staging), il conteggio dovrebbe restare più o meno stabile mentre gli spazi URL restano stabili; un salto improvviso di solito significa che una nuova sezione è stata catturata per errore da un pattern Disallow esistente. Per un URL che hai sbloccato deliberatamente perché volevi indicizzarlo, quell’URL dovrebbe uscire dal gruppo dopo il crawl successivo.
• Come recuperarlo — rapporto Indicizzazione delle pagine di GSC, filtrato alla riga “Bloccato da robots.txt”; controlla singoli URL con Ispezione URL per confermare lo stato attuale, non una fotografia obsoleta.
• Benchmark/intervallo realistico — non esiste un obiettivo universale: dipende da quanta parte del sito vieti intenzionalmente. L’asticella onesta è zero URL in questo gruppo che volevi davvero indicizzare e una tendenza piatta per tutto il resto. Stabilisci il tuo conteggio di base prima di giudicare se una modifica lo ha spostato nella direzione giusta.
• Cadenza — controlla subito dopo ogni modifica a robots.txt; negli altri casi basta uno sguardo periodico (una volta al mese è sufficiente per la maggior parte dei siti) per intercettare la deriva.

Playbook: rimuovere davvero una pagina da Google

Una sequenza ripetibile per quando un URL deve uscire davvero dall’indice di Google, non soltanto essere bloccato dai crawl futuri.

1. Conferma che l’obiettivo sia la rimozione, non solo il controllo del crawl. Se l’obiettivo è davvero “smettere di sprecare crawl budget”, un semplice disallow robots.txt è lo strumento giusto e questo playbook non si applica: la pagina può restare indicizzata tramite link e va bene così. Usa questa sequenza solo quando la pagina deve uscire davvero dall’indice.

2. Consenti il crawl. Rimuovi o allenta la regola Disallow che blocca l’URL. Conferma con robots.txt Tester che l’URL ora risulti consentito, non bloccato.

3. Servi noindex. Aggiungi al momento la pagina sottoponibile a crawl un tag meta robots noindex o un header HTTP X-Robots-Tag. Questa è la vera istruzione di rimozione: il disallow non ha mai svolto quel lavoro.

4. Lascia che Google ripeta il crawl e lo rilevi. Google deve recuperare di nuovo la pagina per vedere il noindex. Non esiste un modo per forzare un fetch immediato oltre a richiedere l’indicizzazione in Search Console e attendere il crawl successivo.

5. Conferma la rimozione. Controlla Ispezione URL in Search Console per lo stato di indicizzazione attuale della pagina. Quando segnala che la pagina è esclusa a causa di noindex, la rimozione ha funzionato.

6. Non considerare il riblocco il passaggio finale. Dopo l’uscita della pagina, aggiungere di nuovo il Disallow non è gratis: Google può perdere ancora visibilità della regola noindex al crawl successivo e un URL bloccato ma collegato può tornare indicizzato tramite link di altre pagine, proprio l’esito “indicizzato nonostante il blocco” che volevi evitare. Se il problema è il crawl budget, valuta questo rischio oppure usa autenticazione/cancellazione per le pagine che devono davvero restare rimosse.

7. Nei casi urgenti, salta l’attesa. Se la pagina deve uscire adesso, usa lo strumento Rimozioni di Search Console, proteggila con password oppure cancellala del tutto (restituendo 404/410) invece di aspettare il ciclo crawl-più-noindex.

Prompt IA pronti all’uso

Prompt da copiare e incollare per lavorare su un blocco robots.txt con un LLM. Considera l’output un’ipotesi iniziale: conferma ogni cosa importante con il robots.txt Tester o con lo strumento Ispezione URL di Search Console prima di agire.

Scopri quale regola blocca quale URL

Here is my robots.txt file and a list of URLs. For each URL, tell me whether it
is blocked or allowed, and quote the exact line in robots.txt responsible
(remember: the longest, most specific matching rule wins, and an Allow can
override a broader Disallow). If a URL isn't matched by any rule, say so.

ROBOTS.TXT:
[paste]

URLS:
[paste list, one per line]

Controllo di buon senso: il blocco sembra intenzionale?

I run a [type of site]. Here is my robots.txt file. For each Disallow rule, tell
me what kind of URLs it likely targets (e.g. internal search, faceted
navigation, staging, cart/checkout, admin) and flag any rule that looks broad
enough it might be catching content pages by accident. Don't guess about pages
you can't see — just reason from the rule pattern and ask me to confirm
anything ambiguous.

ROBOTS.TXT:
[paste]

Prepara la sequenza noindex-poi-crawl per una pagina specifica

I need to remove [URL] from Google. It's currently blocked by this robots.txt
rule: [paste rule]. Walk me through the exact sequence of changes in order
(robots.txt edit, meta tag or header change, what to check in Search Console at
each step) so I don't accidentally leave the noindex tag unseen by Google.

Prova un URL contro le regole robots.txt

Prima di modificare qualsiasi cosa, conferma esattamente quale regola intercetta un determinato URL. Il robots.txt Tester lo fa con un matcher portato dal parser robots.txt open source di Google e mostra la regola vincente per ogni URL: è il modo più rapido e accurato per controllare. Per un controllo manuale veloce senza strumento, ecco la logica essenziale in Python:

import re

def rule_matches(path, rule):
    """Very simplified robots.txt path matcher: '*' = wildcard, '$' = end anchor."""
    pattern = re.escape(rule).replace(r'\*', '.*')
    if pattern.endswith(r'\$'):
        pattern = pattern[:-2] + '$'
    return re.match(pattern, path) is not None

def find_blocking_rule(path, disallow_rules, allow_rules):
    """Longest matching rule wins; ties go to Allow (mirrors Google's documented
    precedence). Returns the winning rule string, or None if nothing matches."""
    matches = [r for r in disallow_rules if rule_matches(path, r)]
    matches += [r for r in allow_rules if rule_matches(path, r)]
    if not matches:
        return None
    return max(matches, key=len)

# Example
disallow = ["/search", "/*?*sort="]
allow = ["/search/help"]
print(find_blocking_rule("/search/help", disallow, allow))  # -> "/search/help" (Allow wins, longer)
print(find_blocking_rule("/search/results", disallow, allow))  # -> "/search" (Disallow, no competing Allow)

Questa è una semplificazione del matcher effettivo di Google (il parsing reale di robots.txt ha più casi limite intorno a escape e selezione dei gruppi): usala per controllare il tuo modello mentale e conferma con il tester reale qualsiasi cosa importante prima di farci affidamento.

Strumenti per diagnosticare e correggere questo stato

• Google Index Checker — dopo aver corretto un blocco, usalo per controllare i segnali osservabili di indicizzabilità della pagina (codice di stato, redirect, noindex, canonical) prima di passare a Search Console per la risposta effettiva di Google.
• Ispezione URL (Google Search Console) — la fonte di verità per sapere se uno specifico URL è attualmente bloccato, la sua indicizzabilità verificata live e, dopo la correzione, se Google lo ha ripreso.
• Rapporto robots.txt (Google Search Console) — una vista a livello di proprietà del dominio sui file robots.txt trovati da Google per gli host principali, l’ora dell’ultimo fetch e lo stato del fetch, con un’azione “richiedi un nuovo crawl” dopo la modifica del file.

Mettiti alla prova: Bloccato da robots.txt

Cinque domande sullo stato “Bloccato da robots.txt” e sugli errori che le persone commettono. Scegli una risposta per ogni domanda, poi controlla.

Dimostra che la rimozione ha funzionato davvero

“Ho impostato noindex” o “ho modificato robots.txt” non dimostra nulla da solo: l’unico risultato che conta è ciò che l’indice di Google riflette dopo. Questi test separano la modifica che hai fatto dall’esito raggiunto da Google.

Test 1 — Il crawl è davvero consentito

• Test da eseguire — passa l’URL nel robots.txt Tester dopo aver modificato il file.
• Risultato atteso — l’URL risulta consentito, senza una regola Disallow che lo intercetti (oppure con un Allow più specifico che prevale su un Disallow più ampio).
• Interpretazione di un fallimento — se è ancora bloccato, una regola diversa e più specifica intercetta l’URL oppure la modifica non è stata distribuita: controlla il contenuto live effettivo del file, non solo ciò che intendevi modificare.
• Finestra di monitoraggio — immediata: è un controllo statico del file servito.
• Segnale di rollback — n/d: correggi la regola prima di passare al test successivo; nulla a valle funziona finché il crawl non è davvero consentito.

Test 2 — Il noindex viene servito correttamente

• Test da eseguire — Ispezione URL → Live Test in Search Console (oppure recupera direttamente la pagina e controlla gli header di risposta/HTML) sull’URL ora sottoponibile a crawl.
• Risultato atteso — il test live mostra noindex presente, come tag meta robots nell’<head> o come header HTTP X-Robots-Tag.
• Interpretazione di un fallimento — se qui manca noindex, la rimozione non avverrà mai, per quanto tu aspetti: il solo passaggio che consente il crawl non rimuove nulla.
• Finestra di monitoraggio — immediata: il test live riflette la pagina servita in questo momento.
• Segnale di rollback — n/d: questo test deve superare il controllo prima che Google possa agire.

Test 3 — Google ha davvero rimosso la pagina

• Test da eseguire — Ispezione URL (il campo sullo stato di indicizzazione, non solo Live Test) sull’URL, controllato periodicamente dopo il superamento dei due test precedenti.
• Risultato atteso — lo stato diventa escluso a causa di noindex e l’URL smette di apparire in una ricerca site: o nei dati di monitoraggio del ranking.
• Interpretazione di un fallimento — se è ancora indicizzato dopo un ciclo completo di crawl, di solito significa ritardo di cache/propagazione, non una configurazione guasta: Google deve ripetere il crawl per notare la modifica e non è immediato.
• Finestra di monitoraggio — 1–3 settimane, a seconda della frequenza con cui Google eseguiva già il crawl dell’URL: non giudicare il risultato il giorno dopo la distribuzione della modifica.
• Segnale di rollback — condizione di interruzione nominata — se è ancora indicizzato dopo un ciclo completo di crawl e nei log del server continua a risultare sottoposto a crawl di recente, smetti di attribuire tutto alla propagazione e ricontrolla i Test 1 e 2 per individuare un errore (cache che serve un robots.txt obsoleto, CDN che rimuove l’header X-Robots-Tag o una seconda regola in conflitto sono i colpevoli abituali).

Cronologia modifiche