Crawl budget: cos’è e come capire se Google scansiona le pagine giuste

Il tuo sito lo conosci a memoria. Google no. Quando correggi un prezzo, riscrivi un articolo, togli una pagina, dai per scontato che la versione nuova sia quella che vedono tutti. In SERP, però, compare quello che Googlebot ha scaricato l’ultima volta, e nelle risposte AI succede lo stesso per vie diverse. Ogni quanto i tuoi URL vengano richiesti di nuovo dipende dal crawl budget – e no, non è solo un affare da siti da un milione di pagine.

Che cos’è il crawl budget

Il crawl budget è l’insieme degli URL che Google può e vuole scansionare su un sito in un certo periodo. In pratica, è il parametro che identifica il tempo e le risorse che Google intende dedicare a un sito web attraverso le scansioni di Googlebot.

Esiste perché il web è troppo grande per essere scaricato tutto e di continuo, e perché ogni richiesta pesa sul server che la riceve. Googlebot deve quindi scegliere, sito per sito, quante richieste fare e su quali indirizzi, senza mettere in difficoltà chi risponde. Il crawl budget è l’esito di quella scelta.

Non è una quota assegnata in anticipo, né un valore da far crescere: nessun pannello lo mostra come un numero, e non esiste un livello di riferimento a cui tendere. Lo leggi a consuntivo, nelle richieste che Googlebot ha fatto davvero, e cambia nel tempo insieme al sito e al server che lo ospita.

Per te vale per ciò che decide: se e quando Google richiede una pagina, quindi quanto tempo passa fra una modifica e il momento in cui Google ne ha la versione nuova. Quel tempo dipende da due fattori che governi in modo diverso, come risponde il tuo server e quanto Google ha motivo di tornare, e i suoi effetti arrivano fino all’indice e alle risposte generate.

Capacità del server e domanda di scansione

Il risultato nasce dall’incontro fra due condizioni. Il limite di capacità di scansione misura quanto lavoro il tuo server regge, e dipende dalle connessioni che Googlebot può aprire insieme e dall’intervallo fra una richiesta e l’altra. Con pagine servite in fretta e senza errori il limite sale, e Googlebot può usare più connessioni; con tempi di risposta che si allungano, errori 5xx o risposte 429 il limite scende, e Google scansiona meno per non mettere in difficoltà il sito.

La domanda di scansione misura quanto Google vuole tornare sui tuoi URL. Si forma sull’inventario che percepisce, cioè gli indirizzi del sito che conosce, sulla popolarità di ciascun URL sul web e sulla frequenza con cui cambia: le pagine nuove, quelle aggiornate spesso e quelle più popolari tornano in coda prima dei documenti fermi da anni. Gli eventi che toccano tutto il sito, come una migrazione, la fanno salire di colpo.

Delle due condizioni comanda la più stretta. Un server velocissimo non porta Googlebot su pagine che non ha motivo di riprendere, e con una domanda bassa la scansione resta bassa anche lontano dal limite di capacità; una domanda alta, a sua volta, si ferma davanti a un server che rallenta. Le leve sono quindi due e non si sostituiscono: più risorse al server quando il limite è la capacità, pagine più utili e più cercate quando manca la domanda. Una sezione aggiornata che resta indietro può soffrire dell’una o dell’altra, e il numero totale delle richieste non ti dice quale.

Verso l’indice e le risposte AI

La scansione consegna a Google una versione del documento, e indicizzazione e ranking vengono dopo. La frequenza con cui una pagina viene ripresa non le assegna posizioni migliori e non misura la sua qualità: un contenuto utile che non cambia può essere scansionato di rado e restare dov’è, mentre una pagina ripresa ogni giorno può non posizionarsi affatto.

Dalla versione scansionata dipendono anche le risposte generate. AI Overview e AI Mode usano come fonti pagine indicizzate e idonee a comparire con uno snippet, cioè pagine che Googlebot ha scansionato. Fuori da Google, gli assistenti che cercano sul web per rispondere partono dagli indici dei motori di ricerca, Google in testa: una pagina che non è mai entrata nell’indice non viene intercettata nemmeno da quelle ricerche. È materia di AEO, e comincia dalla scansione.

Gli URL del tuo sito che Google conosce

Dal CMS vedi le pagine che hai pubblicato. Google conosce gli indirizzi che ha incontrato: quelli dei link interni ed esterni, delle sitemap e dei redirect, e quelli che il sito genera da solo con filtri, ordinamenti, parametri di tracciamento, identificativi di sessione, ricerca interna, calendari che proseguono senza fine, pagine del carrello e pagine che eseguono un’azione, come l’aggiunta di un prodotto al carrello. Nel conto entrano anche le versioni alternative di una pagina, come quelle linguistiche dichiarate con hreflang. L’insieme di questi URL è il tuo inventario, e Google non lo dimentica: senza indicazioni da parte tua prova a scansionare tutti gli indirizzi che ha in elenco, o quasi, parametri compresi.

Ognuno di quegli indirizzi nasce da una decisione: un filtro aggiunto per aiutare la navigazione, una categoria aperta per una campagna, un archivio generato in automatico. Sono decisioni prese in momenti diversi, spesso da persone diverse, e lasciano in circolazione indirizzi che sopravvivono al motivo per cui erano nati.

Contare le pagine pubblicate, così, dice poco su quanto lavoro chiedi a Googlebot. Un catalogo di migliaia di prodotti può avere un inventario ordinato, e un sito di poche centinaia di pagine può averne accumulato uno molto più largo, fatto di percorsi, parametri e tassonomie ancora raggiungibili senza più un ruolo preciso.

Filtri e faccette che moltiplicano gli URL

Un catalogo con 21 marchi, 13 taglie, 11 colori, 7 materiali e 9 fasce di prezzo sembra una vetrina gestibile. Con ogni filtro attivabile o lasciato vuoto, e un indirizzo per ogni combinazione, le combinazioni possibili sono:

22 × 14 × 12 × 8 × 10 – 1 = 295.679

Il calcolo mostra quanto in fretta cresce lo spazio degli URL possibili, non quanti indirizzi esistano su un ecommerce reale: Googlebot scopre le combinazioni che trova linkate, e quante siano dipende da come il sito costruisce i link dei filtri.

Le combinazioni hanno valori diversi. «Scarpe running uomo numero 43» può rispondere a una ricerca vera e meritare una pagina; lo stesso elenco di scarpe ordinato dal prezzo più basso al più alto non aggiunge niente a ciò che Google conosce già. Il CMS le tratta entrambe come varianti della navigazione, e la scelta su quali rendere raggiungibili spetta all’architettura del sito: il numero dei prodotti e quello degli URL che esponi sono grandezze diverse.

Indirizzi che sopravvivono alle modifiche del sito

Le migrazioni sono il caso più visibile, perché il prima e il dopo hanno nomi diversi e un piano di migrazione li mette in fila. Succede anche nei cambiamenti piccoli, che nessun piano registra. Hai rinominato una categoria, sostituito un template, tolto un tag dal menu, spostato una landing, e la versione vecchia continua a ricevere link da altri siti, resta in una sitemap dimenticata o passa da un redirect che qualche link interno richiama ancora. La pagina è sparita dal tuo lavoro quotidiano senza essere sparita dal web.

Un redirect lasciato a metà strada ha un costo preciso. Un vecchio URL che attraversa due reindirizzamenti prima di arrivare alla pagina attuale costa tre richieste invece di una, e Search Console le conta una per una, perché ogni passaggio della catena è una richiesta a sé.

Prima di parlare di spreco devi sapere dove passa davvero il crawler

Un audit con uno spider può trovarti migliaia di URL da sistemare. Ti dice molto sull’architettura del sito e ancora poco su come Googlebot la percorre.

Puoi avere un inventario inefficiente, pieno di indirizzi ridondanti, senza che Googlebot ci torni abbastanza da farne un problema. Lo spreco osservato compare nei log, quando una quota rilevante delle richieste finisce su quegli indirizzi. Il limite di crawl budget arriva dopo ancora: nuovi prodotti fermi in coda, sezioni aggiornate riprese tardi, server sotto pressione, mentre una parte dell’attività di Googlebot continua a finire su pagine che non ti servono. Ogni livello ha la sua prova: la struttura del sito e i log per i primi due, le Statistiche di scansione per il terzo, con un’eccezione che riguarda proprio i siti piccoli.

Livello	Che cosa vedi	Dove lo vedi	Che cosa ti dice
Inventario inefficiente	URL ridondanti raggiungibili: parametri, filtri, archivi, vecchi percorsi	SEO Spider (SEOZoom)	Hai indirizzi da mettere in ordine, e non sai ancora se Googlebot li richiede
Spreco osservato	Richieste di Googlebot che finiscono su quegli URL	Log del server; URL di esempio nelle Statistiche di scansione (Google)	Una parte del lavoro di Googlebot va su pagine che non ti servono
Limite di crawl budget	Pagine utili che aspettano, tempi di risposta in salita, errori 5xx e risposte 429	Statistiche di scansione e rapporto sull’indicizzazione delle pagine (Google); log del server	La scansione non basta per le pagine che ti servono

Googlebot dentro la struttura del sito

Il SEO Spider di SEOZoom ricostruisce la struttura. Segue i link interni e ti restituisce gli URL che il sito rende raggiungibili, ciascuno con il codice di risposta, l’eventuale blocco nel robots.txt, la distanza in clic dalla home, i link, la canonical e le direttive. È la base di un audit di SEO tecnica: dopo una migrazione trova i vecchi percorsi ancora linkati, dopo un intervento sui template ti mostra la sezione che ha cominciato a generare molti più indirizzi del previsto. Anche la distanza dalla home dice qualcosa: le pagine vicine tendono a essere scansionate più spesso, senza per questo posizionarsi meglio.

Lo Spider non vede le visite di Googlebot. Le registra il log del server, con URL, data e ora, codice di risposta, user agent e, secondo la configurazione, il tempo impiegato a rispondere. Lì compaiono tutte le richieste, di Google e degli altri crawler, comprese quelle che il rapporto di Search Console non conteggia.

Nei log le migliaia di URL con parametri trovati durante un audit mostrano il loro peso reale: possono comparire di rado oppure occupare una fetta importante delle richieste di Googlebot. Lo stesso controllo vale per vecchi redirect, paginazioni e archivi. L’inventario inefficiente diventa così spreco osservato, oppure smette di preoccuparti.

Chiunque può falsificare uno user agent, e non tutte le richieste che si presentano come Googlebot arrivano da Google. Prima di contarle verifichi l’indirizzo IP, con una risoluzione inversa o con gli intervalli di IP che Google pubblica. Messi insieme, lo Spider ti mostra la struttura che hai costruito e i log come Googlebot la percorre.

Il limite reale nelle Statistiche di scansione

In Search Console il rapporto sta nelle impostazioni della proprietà, alla voce Statistiche di scansione. Mostra il totale delle richieste, le dimensioni dei download, il tempo medio di risposta e lo stato dell’host, poi divide le richieste per risposta del server, per tipo di file, per tipo di Googlebot e per scopo, cioè rilevamento di URL mai scansionati prima o aggiornamento di pagine già note.

La curva ha senso accanto a quello che hai fatto sul sito nel periodo, perché una variazione identica può avere cause opposte. Dopo una migrazione le richieste crescono e le scansioni di rilevamento salgono: è la domanda che aumenta, come previsto. Dopo il rilascio di un catalogo nuovo salgono insieme richieste e tempi di risposta, e lì è la capacità del server a entrare sotto pressione. Su una sezione che non aggiorni più, le richieste calano, mentre le poche pagine nuove arrivano in fretta: la domanda si è spostata, e non c’è niente da correggere.

Il limite, nel concreto, è una pagina che ti serve e che aspetta. Il Controllo URL di Search Console ti dice, pagina per pagina, quando Googlebot l’ha scansionata l’ultima volta: una scheda nuova o aggiornata ferma da settimane, mentre le richieste vanno altrove, è il segnale che cerchi. Da ogni riga del rapporto apri poi un elenco di URL di esempio, che Google dichiara indicativo e non completo, e per ricostruire dove finiscono le richieste indirizzo per indirizzo torni ai log.

Anche un sito piccolo può mostrare il problema

La guida di Google sul crawl budget indica come soglie approssimative i siti con oltre un milione di pagine uniche che cambiano circa una volta a settimana e quelli con oltre 10.000 pagine che cambiano ogni giorno. Sono i casi in cui la capacità del server rischia di non bastare, e sotto quelle dimensioni anche le Statistiche di scansione servono a poco: Google le considera superflue per i siti con meno di mille pagine. Un sito piccolo non viene scansionato meno di uno grande per le sue dimensioni: se pubblica contenuti importanti che cambiano spesso, Google ci torna spesso.

La guida aggiunge un terzo caso, senza una dimensione minima: una quota consistente di URL nello stato «Rilevata, ma attualmente non indicizzata», che trovi nel rapporto sull’indicizzazione delle pagine di Search Console. Anche su un sito di poche centinaia di pagine, decine di URL fermi lì sono un segnale da verificare.

«Rilevata» significa che Google conosce l’URL e non lo ha ancora richiesto. Di solito, spiega la guida di Search Console, la scansione è stata rimandata perché avrebbe rischiato di sovraccaricare il sito. La verifica parte quindi dai tempi di risposta e dagli errori del server, e da un inventario che manda Googlebot su indirizzi inutili mentre quelli nuovi aspettano.

«Scansionata, ma attualmente non indicizzata» descrive un’altra fase. La richiesta c’è stata, e Google ha scelto di non indicizzare la pagina, almeno per ora: il problema sta dopo la scansione, e il crawl budget non c’entra.

I segnali di un server al limite

Su molti siti la capacità del server è abbondante, e il limite, se c’è, sta nella domanda o nell’inventario. Tempi di risposta che si allungano, errori 5xx e risposte 429 dicono invece che il carico sta diventando difficile da sostenere, e Googlebot riduce le richieste perché continuare allo stesso ritmo peggiorerebbe la situazione.

Lo stato dell’host, nelle Statistiche di scansione, riassume i problemi di disponibilità degli ultimi 90 giorni su tre fronti: recupero del robots.txt, risoluzione DNS e connettività del server. Il robots.txt pesa più di quanto sembri. Un file che risponde con un errore del server ferma la scansione di tutto il sito per le prime 12 ore; poi Google usa per un mese l’ultima versione valida che ha in cache, e oltre quel mese, su un sito con problemi di disponibilità, smette di scansionare.

Tempi lenti ed errori 5xx nascono di solito nell’infrastruttura: una query al database diventata lenta, una cache che copre solo una parte degli URL, un template che esegue troppe operazioni, un server sovraccarico per il traffico che riceve. Il tempo medio di risposta del rapporto ti dice che il sito rallenta; il tempo di risposta per URL registrato nei log ti dice dove, su quale template o in quale sezione.

Aumentare CPU o memoria su un sito che risponde già bene non porta più scansione. Alza la capacità, e la capacità in più resta inutilizzata finché la domanda non cresce. Il conto della capacità, poi, non si fa solo sulle pagine e solo su Googlebot: entrano le risorse che ogni pagina richiede, gli altri crawler che usano lo stesso server e i momenti in cui è Googlebot stesso a chiedere più di quanto il server regga.

Richieste che non coincidono con una pagina HTML

Nelle Statistiche di scansione il raggruppamento per tipo di file mostra che cosa occupa le richieste: HTML, immagini, JavaScript, CSS, JSON. Per il rendering di una pagina Googlebot ne scarica le risorse, e il rapporto conta quei recuperi sotto «Carico di risorse della pagina», fra i tipi di Googlebot. CSS, JavaScript e recuperi XHR consumano crawl budget come le pagine, e Google conta il tempo del rendering al pari del tempo della richiesta: su un sito pesante o molto dinamico il lavoro di scansione cresce anche senza una pagina editoriale in più.

Google richiede una volta sola le risorse condivise da più pagine, e poi le tiene in cache: una risorsa servita sempre dallo stesso URL resta in cache, mentre la stessa risorsa sotto indirizzi diversi va richiesta più volte. Una risorsa pesante e non necessaria a capire la pagina, come un’immagine decorativa, si può escludere dalla scansione con il robots.txt; quelle che servono al rendering, invece, devono restare accessibili.

Per tutto il resto lavorano le richieste condizionali: il server dichiara nella risposta un ETag o un Last-Modified, Googlebot li rimanda alla visita successiva come If-None-Match e If-Modified-Since, e se la risorsa non è cambiata il server risponde 304 Not Modified, senza ritrasmetterla. Con entrambi i valori presenti, i crawler di Google usano l’ETag. Il risparmio conta sui siti con molto materiale statico, file pesanti o risorse richieste di continuo, e ti accorgi che funziona dalla voce «Risorsa non modificata (304)» fra le risposte del rapporto.

Host e crawler che si dividono la capacità

Per Google un sito è un nome host. www.esempio.it e shop.esempio.it hanno ciascuno il proprio crawl budget, mentre www.esempio.it/blog/ rientra in quello del www. Scegliere fra sottodominio e sottocartella vuol dire anche decidere se una sezione nuova viene scansionata come un sito a sé o come parte del sito principale.

I nomi separati possono nascondere un’infrastruttura comune. Un www e uno shop che interrogano un database comune o girano sulla stessa macchina si rallentano a vicenda: il carico dell’uno peggiora le risposte dell’altro, e Google abbassa il limite di capacità di entrambi.

Su ogni host lavorano anche più crawler di Google. Ciascuno ha una domanda propria, ma il limite di capacità è condiviso fra tutti, e la domanda alta di uno riduce la capacità disponibile per gli altri. Su un ecommerce, accanto a Googlebot, arrivano anche AdsBot, che controlla le pagine di destinazione degli annunci, e StoreBot, il crawler degli acquisti di prodotti legato a Google Shopping, e il rapporto li mostra entrambi fra i tipi di Googlebot. Un picco di AdsBot nasce spesso da molti nuovi target negli annunci dinamici della rete di ricerca, si ripete ogni due settimane circa e pesa sulla capacità che serve alle pagine che vuoi vedere scansionate.

I crawler degli altri servizi, da quelli di OpenAI a quelli di Perplexity, stanno fuori dal crawl budget di Google ma consumano il tuo server. Un bot che occupa abbastanza CPU, banda o connessioni da rallentarlo lascia a Googlebot risposte più lente, e le richieste scendono: l’effetto è indiretto e passa dall’infrastruttura, e nei log lo vedi confrontando giorno per giorno i loro picchi con i tempi di risposta.

Troppe richieste da Googlebot

A volte il problema è Googlebot stesso, con più richieste di quante il server regga. Per un sollievo immediato, di qualche ora o di un paio di giorni, Google indica di rispondere 500, 503 o 429 al posto del 200: con molti URL in errore Googlebot riduce la frequenza su tutto il nome host, e con il 503 e il 429 puoi indicare quando tornare con l’intestazione Retry-After. Oltre un paio di giorni le stesse risposte diventano un rischio, perché gli URL che le restituiscono per giorni possono uscire dall’indice.

Il rallentamento ha un prezzo: Google scopre più tardi le pagine nuove, aggiorna più tardi prezzi e disponibilità, toglie più tardi quelle rimosse, e sulle pagine di destinazione degli annunci le campagne possono fermarsi. Se l’infrastruttura non riesce a restituire quei codici, dal rapporto su Googlebot in Search Console puoi inviare una richiesta speciale per segnalare una frequenza anomala; la risposta arriva in qualche giorno, e un aumento non si può chiedere. La regola crawl-delay del robots.txt Googlebot non la legge, e lo strumento di Search Console per limitare la frequenza di scansione è stato ritirato all’inizio del 2024.

Una parte della domanda nasce dalle tue decisioni

Ogni scelta su che cosa pubblicare, aggiornare o tenere online agisce sui fattori da cui nasce la domanda di scansione: l’inventario, la popolarità degli URL e la frequenza con cui cambiano. Molte decisioni editoriali, commerciali o organizzative diventano così anche scelte di crawling, prese in riunioni in cui nessuno parla di scansione.

Una serie di articoli molto simili, conservati sul blog perché nessuno ha deciso quale debba restare, moltiplica gli URL sullo stesso argomento e divide fra più indirizzi i link interni ed esterni che una pagina sola raccoglierebbe. Googlebot si trova così a riprendere più volte la stessa informazione: la cannibalizzazione diventa anche una questione di scansione. La landing di una campagna finita, lasciata nel menu, continua a ricevere link interni e resta fra le pagine che Googlebot riprende come se fossero vive.

Sull’ecommerce vale per le varianti. Dieci schede che differiscono solo per una caratteristica minore, come il colore di un accessorio, sono dieci URL da riprendere per contenuti quasi identici; una scheda che le raccoglie, con un testo che le descrive tutte, ne lascia uno solo. Una variante che risponde a ricerche proprie merita invece il suo indirizzo, con un contenuto che la distingue dalle altre.

Aggiornamenti veri e date spostate

Una scheda con prezzi e disponibilità che variano ogni settimana chiede passaggi frequenti, e Google li regola su quanto spesso la trova cambiata. Un aggiornamento vero è una ragione per tornare; una data spostata o due righe ritoccate senza aggiungere nulla no, e una pagina utile non perde valore perché è vecchia.

La sitemap elenca gli URL che vuoi far scansionare, nella loro versione canonica, e il campo lastmod indica quali sono cambiati: un segnale che Google usa solo se è coerente e verificabile: una data cambiata su pagine identiche gli toglie credibilità. Comprimere la sitemap non fa risparmiare scansione, perché il file va comunque scaricato. Per una singola pagina importante appena aggiornata, il Controllo URL di Search Console ti permette di chiederne la scansione.

Migrazioni e domanda che sale tutta insieme

Una migrazione è la decisione che sposta la domanda più di ogni altra. Cambiando dominio, protocollo o struttura degli URL, Google deve rielaborare i contenuti sotto i nuovi indirizzi, e la domanda di scansione sale per tutto il sito nello stesso momento. Nelle Statistiche di scansione lo vedi come un’ondata di richieste di rilevamento, che poi rientra.

In quelle settimane la capacità deve reggere il picco. Vecchio e nuovo server devono rispondere senza errori, ogni vecchio URL deve rimandare con un redirect diretto alla sua nuova destinazione, e la sitemap deve elencare gli URL nuovi mentre il passaggio avviene. Il robots.txt del sito nuovo va controllato prima di andare online: un blocco rimasto dall’ambiente di test ferma la scansione proprio quando la domanda è più alta.

Quello che ottieni riducendo gli URL

Togliere migliaia di URL inutili non libera altrettante richieste per le pagine importanti. La capacità risparmiata passa ad altre pagine solo se il sito sta già toccando il proprio limite di capacità di scansione, come precisa la stessa guida di Google. Il robots.txt non serve quindi a spostare la scansione da una sezione all’altra per qualche settimana: Google sconsiglia di usarlo per riassegnare il budget in modo temporaneo.

Su un sito con margine, ridurre l’inventario fa solo scendere l’attività di Googlebot. La pulizia serve comunque, per ragioni concrete: meno duplicati, meno percorsi da mantenere, rapporti di Search Console e log più leggibili. Sul sito che subisce la pressione, invece, toglie lavoro che occupava capacità sottratta alle pagine che ti servono.

Come un URL smette di essere richiesto

Il risultato di una pulizia dipende dalla risposta che ogni URL dà a Googlebot, e non tutte le risposte agiscono sulle richieste: diverse lavorano sull’indice e lasciano la scansione com’era. Scambiarle porta a un sito che nei rapporti sembra in ordine e continua a ricevere le stesse richieste.

Intervento	Richieste di Googlebot	Indice	Quando serve
404 o 410	Si riducono: un 404 è per Google un segnale forte per non richiedere più l’URL, e i 4xx diversi dal 429 non sprecano budget	La pagina esce	Pagina rimossa senza una sostituta; combinazioni di filtri senza risultati
Soft 404 (pagina vuota con codice 200)	Continuano: per Googlebot la pagina è viva	Google la riconosce come vuota e non la mostra	Mai: va sostituito da un 404 vero o da una pagina con contenuto
Redirect 301	Googlebot richiede l’URL vecchio per seguire il redirect; ogni passaggio di una catena è una richiesta in più	Passa alla destinazione	Pagina con una sostituta coerente, con il redirect diretto alla destinazione finale
Disallow nel robots.txt	Si fermano	L’URL resta noto e, se altre pagine lo linkano, può comparire nei risultati senza descrizione	Famiglie di URL che non devono essere scansionate: filtri, ordinamenti, ricerca interna
noindex	Continuano: Googlebot deve richiedere la pagina per leggere il tag	La pagina esce	Pagina da lasciare accessibile ma fuori dai risultati; mai per risparmiare scansione
Canonical	Continuano, e nel tempo possono calare	Google consolida sulla versione indicata, che tratta come un suggerimento	Contenuti duplicati e varianti che devono restare raggiungibili

Le risposte si combinano, e l’ordine conta. Una pagina già indicizzata esce dall’indice solo se Google può scansionarla e leggere il noindex: un URL bloccato dal robots.txt non mostra il tag a Googlebot. Il blocco, se ti serve anche fermare le richieste future, viene dopo la rimozione, quando Google l’ha recepita. Sui redirect conta il punto di partenza: i link interni che puntano ancora all’URL vecchio tengono viva la catena, e vanno portati sulla destinazione finale.

Sulla navigazione a faccette la guida di Google applica queste risposte filtro per filtro: il robots.txt per le combinazioni che non devono essere scansionate, un 404 per quelle senza risultati, la canonical come indicazione che nel tempo può ridurre la scansione delle varianti.

Nel SEO Spider ritrovi ogni caso. La vista Response Codes filtra le risposte 3xx, 4xx e 5xx e gli URL bloccati dal robots.txt, con la destinazione di ogni redirect accanto all’URL, e le viste Canonical e Directives mostrano canonical e direttive pagina per pagina. Dopo una pulizia, una nuova scansione ti dice se gli URL rispondono come hai deciso e se qualche link interno porta ancora a un redirect.

Le pagine candidate al taglio e quello che producono ancora

Una pagina con pochissimo traffico organico sembra la prima candidata alla pulizia. Prima di toccarla controlli che cosa fa altrove: in Search Console può avere impressioni su ricerche secondarie, in Analytics conversioni che arrivano da campagne o newsletter, fra i backlink collegamenti che vale la pena conservare, e il suo traffico può concentrarsi in un periodo preciso dell’anno.

In altri casi la verifica conferma il sospetto: l’URL non porta visite, non converte, non riceve link e non serve all’architettura. Da lì la decisione è editoriale, e la gestione strategica dei contenuti la affronta per intero. Aggiorni la pagina se il tema ha ancora domanda, la accorpi a una pagina più forte con un 301 diretto, la rimuovi con un 410 se non ha una sostituta.

Rendimento pagine ti aiuta a restringere il campo

Su un sito di migliaia di URL la verifica pagina per pagina ha bisogno di un elenco da cui partire. Nei Progetti di SEOZoom, alla voce Pagine, Rendimento pagine divide le pagine del sito per fasce di traffico organico stimato e indica, per ogni fascia, quante pagine contiene, quante keyword posizionate raccolgono e quale quota di crawl budget occupano. La fascia a traffico stimato zero è quella che il box Crawl Budget sprecato conta in pagine e in percentuale: sono le pagine a maggior rischio di spreco.

Aprendo la fascia trovi l’elenco degli URL, ciascuno con il traffico stimato, il numero di keyword e le Menzioni AI, e da ogni riga passi al dettaglio della pagina, con le keyword per cui si posiziona. Il traffico di quelle fasce è una stima di SEOZoom, e una posizione non garantisce clic: una pagina a zero secondo la stima può vivere di social, newsletter o traffico diretto. L’elenco ti dice dove guardare, mentre visite e clic reali li danno Search Console e Analytics, che puoi collegare al progetto e leggere nelle sezioni dedicate.

La pagina che lavora come fonte nelle risposte AI

Una pagina con pochi clic può lavorare come fonte. Sulle ricerche in cui la risposta generata assorbe una parte dell’interazione, la tua pagina citata in AI Overview o in AI Mode porta visibilità al marchio anche senza clic, e succede anche nelle risposte di ChatGPT, Perplexity e Gemini.

La colonna Menzioni AI di Rendimento pagine te lo segnala già sull’elenco delle candidate. Il quadro completo lo dà AI Visibility, che raccoglie la presenza del dominio in AI Overview e nelle risposte di AI Mode, ChatGPT, Perplexity e Gemini, con le pagine che compaiono e i prompt in cui compaiono. Una candidata alla rimozione che risulta citata cambia la decisione: aggiornarla tiene la fonte dove i motori la trovano già, rimuoverla la toglie dall’indice da cui quelle risposte attingono.