Il report “Copertura” in Google Search Console mostrava una cifra difficile da ignorare: oltre 1 milione di pagine in stato “scansionata, ma attualmente non indicizzata”. Non un centinaio. Non qualche migliaio. Un milione.
Per un e-commerce con un catalogo reale di qualche migliaio di prodotti, quei numeri non hanno senso, a meno che il sito non stia producendo URL inutili in scala, e Google non stia dedicando una parte significativa delle proprie risorse di scansione a URL inutili invece che alle pagine realmente strategiche del sito.
Questo è il caso che ho analizzato di recente per un’agenzia cliente. Il sito: un e-commerce PrestaShop con 5 lingue, un feed Google Merchant Center attivo, e un robots.txt che conteneva un errore logico sottile ma devastante.
Cos’è il crawl budget e quando diventa un problema
Il crawl budget è la quantità di risorse che Googlebot decide di dedicare a un sito in un determinato periodo. È il risultato di due forze: la crawl capacity (quanto il server regge le richieste del bot senza degradare) e la crawl demand (quanto Google ritiene che valga la pena scansionare quel sito, in base a fattori come la popolarità degli URL, la frequenza di aggiornamento, la qualità complessiva dell’inventario di pagine).
Per la maggior parte dei siti piccoli e medi, il crawl budget non è un problema: Google scansiona tutto in modo abbastanza regolare. Il problema emerge quando le URL si moltiplicano senza controllo, e su un e-commerce multilingua con parametri di ordinamento, filtri, paginazione e parametri di valuta, la moltiplicazione può essere esponenziale.
In questo caso specifico: 5 lingue per ogni URL di listing, moltiplicate per i parametri di ordinamento (order=), per la paginazione (page= e p=), per i parametri di valuta (id_currency=, SubmitCurrency=), spesso combinati tra loro. La combinazione poteva generare milioni di URL uniche potenzialmente accessibili al crawler, e i dati di Search Console mostravano che Google ne stava effettivamente scansionando un numero enorme.
La diagnosi: cosa mostrava il campione GSC
Il primo passo è stato analizzare un campione delle URL in stato “scansionata non indicizzata” estratto da Search Console. Su 1.034.424 URL totali, ho preso un campione di 1.000.
L’81% del campione corrispondeva a pattern espliciti: pagine di listing a basso valore SEO moltiplicate per lingua e per parametri.
I pattern più frequenti:
- /de/verkaufshits, /it/piu-venduti, /en/best-sales, /es/mas-vendidos, pagine “prodotti più venduti” in 5 lingue
- /de/angebote, /it/offerte, /en/promotions, pagine promozioni in 5 lingue
- Combinate con ?order=product.name.asc, ?page=27, ?p=57, ?id_currency=2
- Spesso con più parametri sullo stesso URL: ?p=27&order=product.name.asc&ss_nocache=1&page=57&SubmitCurrency=1&id_currency=2
Questi pattern erano già presenti nel robots.txt come Disallow. Il file dichiarava esplicitamente di bloccare queste sezioni. Eppure Google le stava scansionando attivamente, con date di ultima scansione del 15-19 agosto, cioè dopo che il robots.txt era stato aggiornato il 14 agosto.
Il problema non era che mancassero le regole. Era che le regole si stavano neutralizzando a vicenda.
Il conflitto Allow/Disallow: come un’eccezione necessaria diventava un backdoor
Il robots.txt conteneva, nel gruppo User-agent: Googlebot, queste righe:
Disallow: /*?id_currency=
Disallow: /*&id_currency=
Disallow: /*?SubmitCurrency=
Disallow: /*&SubmitCurrency=
Allow: /*?id_currency=
Allow: /*&id_currency=
Allow: /*?SubmitCurrency=
Allow: /*&SubmitCurrency=
Le righe Allow non erano un errore di distrazione. Erano state aggiunte intenzionalmente: il modulo Google Merchant Center di PrestaShop usa i parametri di valuta per comunicare i prezzi nelle diverse valute a Google Shopping. Bloccare quei parametri avrebbe potuto compromettere il feed.
Il problema è la regola di priorità del robots.txt: quando una riga Allow e una riga Disallow hanno la stessa lunghezza di pattern, Google applica quella meno restrittiva. Vince l’Allow.
I pattern /*?id_currency= e /*?SubmitCurrency= hanno la stessa lunghezza sia nella versione Disallow che in quella Allow. Risultato: su URL che corrispondono a entrambi i pattern, l’Allow prevale sul Disallow equivalente.
E siccome i parametri di valuta erano presenti su quasi tutte le URL del sito, incluse le pagine di listing che si volevano bloccare, l’eccezione Merchant Center finiva per rendere accessibili a Google anche URL che le altre regole del robots.txt intendevano bloccare, incluse le pagine di listing.
La verifica con lo strumento “Ispezione URL” di Search Console su un esempio concreto lo ha confermato:
https://www.esempio-ecommerce.com/de/verkaufshits?p=27&order=product.name.asc&SubmitCurrency=1&id_currency=2Risultato: “L’URL è disponibile per Google” / “La pagina può essere indicizzata”, nonostante verkaufshits fosse esplicitamente in Disallow.
Perché Google continuava a scansionare dopo l’aggiornamento
Un dettaglio importante: le date di ultima scansione nel campione GSC erano del 15-19 agosto, cioè successive all’aggiornamento del robots.txt del 14 agosto.
Inizialmente le scansioni successive all’aggiornamento potevano far pensare a un problema di cache o di propagazione CDN. L’analisi delle regole ha però mostrato che il conflitto Allow/Disallow era ancora presente nel file aggiornato: le righe Allow sui parametri di valuta non erano state toccate.
Questa è la parte più utile del caso studio: il sintomo (Google che scansiona ancora dopo l’aggiornamento) aveva una spiegazione più semplice di quanto sembrasse. Non la cache. Non la CDN. Le regole che si neutralizzavano a vicenda erano ancora lì.
La soluzione: restringere l’eccezione alle sole pagine prodotto
Il problema non era l’eccezione in sé. Era che l’eccezione era troppo ampia. Permetteva l’accesso ai parametri di valuta su qualsiasi URL, incluse le pagine di listing che si volevano bloccare.
La soluzione proposta è restringere l’Allow alle sole URL delle pagine prodotto. Nel campione analizzato queste seguono il pattern /{lingua}/{slug-categoria}/{id}-{slug-prodotto}.html, con l’estensione .html presente in tutti i casi esaminati.
Le pagine di listing non hanno mai .html nel path: /de/verkaufshits, /it/offerte, ecc. Quindi un Allow che richiede .html nel pattern non può mai matchare una pagina di listing.
Le righe da sostituire:
# Prima (troppo ampio):
Allow: /*?id_currency=
Allow: /*&id_currency=
Allow: /*?SubmitCurrency=
Allow: /*&SubmitCurrency=
# Dopo (ristretto alle pagine prodotto):
Allow: /*.html*id_currency=
Allow: /*.html*SubmitCurrency=
I Disallow rimangono invariati. L’eccezione Merchant Center continua a funzionare sulle pagine prodotto. Le pagine di listing tornano bloccate.
Attenzione prima del deploy: questa soluzione presuppone che tutte le URL prodotto nel feed effettivo di Google Merchant Center terminino in .html. La sitemap prodotti generata dal modulo lgsitemaps confermava questo pattern su tutti i campioni analizzati. Ma il modulo gmerchantcenter che genera il feed potrebbe avere una logica di URL diversa. Prima di implementare la modifica, verificare il feed reale scaricandolo dall’account Google Merchant Center (Prodotti → Feed → scarica) o dall’Admin PrestaShop.
I test da fare prima e dopo il deploy
Prima di implementare qualsiasi modifica al robots.txt, conviene fotografare lo stato attuale con “Ispezione URL” su un set di URL campione. Così hai una baseline di confronto.
Pagine prodotto, devono restare “disponibile/indicizzabile” prima e dopo:
…/prodotto-esempio.html?id_currency=2
…/prodotto-esempio.html?SubmitCurrency=1
Pagine listing, devono passare da “disponibile” a “Bloccata da robots.txt” dopo il deploy:
/de/verkaufshits?id_currency=2
/de/angebote?id_currency=2
/it/piu-venduti?id_currency=2
/en/best-sales?id_currency=2
Se dopo il deploy le pagine listing risultano ancora “disponibili”, il problema è nella cache del robots.txt o nella versione servita dalla CDN. In quel caso conviene usare il tool di test del robots.txt in Search Console per verificare se Google segnala l’URL come bloccato dal robots.txt.
Il restante 19%: parametri valuta senza canonical
Il campione mostrava anche un 19% di URL diverse dalle pagine listing: varianti di pagine prodotto e categoria con id_currency e SubmitCurrency combinati con altri parametri (order=, ss_nocache=1).
Queste URL erano il risultato dell’eccezione Merchant Center che funzionava come previsto, ma su URL che non erano nel feed, perché la combinazione di parametri le rendeva varianti diverse dalla pagina pulita.
Il rischio qui non è il blocco mancante, ma il canonical tag. Se queste varianti non indicano come canonical la versione pulita, si riduce uno dei segnali espliciti a disposizione di Google per consolidarle sulla URL principale. Il canonical è un segnale, non un comando: Google può comunque riconoscere i duplicati autonomamente, ma indicarlo esplicitamente riduce l’ambiguità.
La verifica da fare: aprire una pagina prodotto con parametri di valuta (es. ?id_currency=2) e controllare il tag canonical nell’HTML. Deve puntare alla versione senza parametri. Se il canonical non c’è o punta a se stesso con i parametri inclusi, è un problema da correggere in parallelo alla modifica del robots.txt.
Nota: i dati del “dopo” non sono ancora disponibili
La modifica al robots.txt è stata proposta ma non ancora implementata al momento della pubblicazione di questo articolo. I test baseline con “Ispezione URL” sono stati preparati e sono pronti da eseguire.
Aggiornerò questo articolo con i dati reali, incluse le statistiche di scansione da Search Console nel periodo successivo al deploy, appena i tecnici implementeranno la modifica e sarà trascorso tempo sufficiente per misurare l’impatto sul crawl budget.
Domande frequenti sul crawl budget SEO
Cos’è il crawl budget e quando impatta davvero il SEO?
Il crawl budget è la quantità di risorse che Googlebot dedica a scansionare un sito in un dato periodo. Per la maggior parte dei siti piccoli e medi con architettura pulita, non è un problema: Google riesce a scansionare tutto. Diventa rilevante quando le URL si moltiplicano senza controllo, come su e-commerce multilingua con filtri, parametri di ordinamento e paginazione. In quei casi, Google può sprecare la capacità di scansione su URL inutili invece di indicizzare le pagine che generano traffico.
Come si legge il report “scansionata ma non indicizzata” in Search Console?
Il report di Indicizzazione in Search Console distingue tra pagine che Google ha scansionato ma non ha inserito nell’indice. Le cause più comuni sono: contenuto duplicato o troppo simile ad altre URL, pagine thin senza valore aggiunto, URL generate da parametri che producono varianti identiche di una stessa pagina. Non è una condanna: alcune pagine non devono essere indicizzate. Il problema è quando compaiono pagine che dovrebbero esserlo, o quando il numero totale è sproporzionato rispetto al catalogo reale.
Come funziona la priorità tra Allow e Disallow nel robots.txt?
Quando Googlebot incontra un robots.txt con regole potenzialmente conflittuali sulla stessa URL, applica la regola più specifica, cioè quella con il pattern più lungo. Se due regole hanno la stessa lunghezza di pattern (una Allow e una Disallow), Google applica quella meno restrittiva: vince l’Allow. Questo è il meccanismo che in questo caso studio neutralizzava il blocco sulle pagine di listing: i pattern Allow e Disallow per i parametri di valuta avevano la stessa lunghezza, quindi l’Allow scavalcava il Disallow.
È necessario bloccare i parametri URL nel robots.txt su un e-commerce PrestaShop?
Dipende dalla struttura del sito. Se i parametri (order=, id_currency=, page=, p=) producono URL uniche che Google può scansionare, e quelle URL non hanno un canonical che le ricollega alla versione pulita, stai potenzialmente sprecando risorse di scansione su varianti sostanzialmente duplicate e aumentando la complessità con cui Google deve consolidare i segnali tra le diverse URL. Il robots.txt è uno strumento per ridurre questo spreco, ma va configurato con attenzione, specialmente quando esistono eccezioni necessarie come il feed Merchant Center. Il robots.txt può essere utilizzato per controllare la scansione di determinate varianti, mentre il canonical svolge una funzione diversa: aiuta Google a consolidare i segnali verso la versione preferita della pagina. I due strumenti non sono alternativi per lo stesso obiettivo, e se una URL è bloccata via robots.txt Google non può necessariamente leggerne il canonical. Entrambi i temi sono approfonditi nella guida alla SEO tecnica.
Quanto tempo ci vuole prima che Google recepisca una modifica al robots.txt?
Google memorizza nella cache il robots.txt e una modifica potrebbe quindi non riflettersi immediatamente nel comportamento di scansione. La verifica più affidabile è lo strumento “Ispezione URL” in Search Console, che permette di verificare se Google segnala l’URL come bloccato dal robots.txt. Se il sito usa una CDN, verificare anche che la nuova versione del robots.txt sia propagata correttamente.
Se stai affrontando un problema simile su un e-commerce, troppe pagine scansionate non indicizzate, parametri URL che moltiplicano le varianti, un robots.txt che non si comporta come previsto, puoi partire da un audit SEO tecnico per diagnosticare la causa reale prima di intervenire.
Per collaborazioni su progetti tecnici complessi con agenzie, scrivimi.
