Analisi dei log su PrestaShop: dove finisce il crawl di Googlebot

Search Console ti dice quante pagine Googlebot ha scansionato. Gli access log del server ti dicono quali, quante volte, con che risposta, e chi ha solo finto di essere Googlebot. Su un e-commerce la differenza pesa: il crawl che finisce su URL inutili è crawl che non arriva ai prodotti nuovi.

Il 30 settembre 2026 ho letto i log di dieci giorni, dal 20 al 29 settembre, di due shop PrestaShop reali che seguo e di questo blog come termine di paragone: 1,8 milioni di richieste sullo shop A, 8,4 milioni sullo shop B, 37.000 qui. Ho verificato i bot principali contro gli indirizzi IP pubblicati dai gestori e ho incrociato le URL visitate da Googlebot con la sitemap dello shop. Gli shop restano anonimi e dai log non è uscito nessun indirizzo IP: lo script gira sul server e restituisce solo conteggi. Più sotto trovi la versione breve per rifarlo sul tuo.

In pratica: una parte del tempo che Google dedica al tuo negozio va su indirizzi doppi o inutili, e i prodotti nuovi o aggiornati aspettano il loro turno più del necessario. I log dicono quanta, e dove.

🛠️ Prima di contare, verifica chi è davvero Googlebot

Lo user agent è una stringa che il client scrive da sé: chiunque può presentarsi come Googlebot, e gli scraper lo fanno proprio perché molti siti ai bot dei motori aprono tutto. Contare le righe che contengono “Googlebot” senza verificarle vuol dire contare anche quelle.

Google indica due metodi nella pagina Verificare le richieste dei crawler di Google, aggiornata il 20 marzo 2026. Il primo è il DNS inverso: l’IP deve risolvere su un nome in googlebot.com, google.com o googleusercontent.com, e quel nome deve risolvere di nuovo sullo stesso IP. Il secondo, più comodo su milioni di righe, è confrontare l’IP con gli elenchi JSON pubblicati da Google, uno per famiglia di crawler: common-crawlers.json per Googlebot, special-crawlers.json per AdsBot e simili, i due user-triggered-fetchers per le richieste avviate da un utente e il nuovo user-triggered-agents.json.

Gli altri gestori fanno lo stesso: OpenAI pubblica un elenco per GPTBot, uno per OAI-SearchBot e uno per ChatGPT-User; Anthropic un unico bots.json; Bing, Perplexity e Apple i loro; Amazon una pagina con la lista degli IP di Amazonbot. Il risultato sui tre siti:

Sullo shop B ClaudeBot e Amazonbot non li ho verificati: il primo passaggio sui suoi log è stato fatto prima di aggiungere quegli elenchi, e rifarlo su 8 milioni di righe voleva dire tenere occupato per un’altra mezz’ora il server di un negozio aperto.

Su un blog che parla di SEO, EVE Milano ha misurato che circa un “Googlebot” su cinque non era Google. Sui due shop la quota non supera l’1,1%, qui è lo 0,2%. Non è una contraddizione: la quota dipende da chi ti prende di mira, e un sito letto da chi fa SEO attira più crawler di test che si travestono. Il punto è che il numero va misurato sul proprio sito, non preso da un altro.

Due dettagli contano più della percentuale. Il primo: sullo shop A 929 dei 1.187 Googlebot finti hanno ricevuto una risposta 200, cioè la pagina completa, come un cliente. Il recinto contro gli scraper del negozio filtra per comportamento, e chi si presenta come Googlebot e si comporta con educazione passa. Il secondo: le quote più alte, ChatGPT-User al 6,1% e PerplexityBot al 3,9%, sono quasi tutte scanner di vulnerabilità travestiti da agente AI. Sui ChatGPT-User finti, 42 richieste su 103 erano sonde verso file e percorsi che un bot vero non chiede mai, e fra le URL cercate dai finti agenti AI ci sono .env, rclone.conf e credenziali cloud. Se nei log vedi un “agente AI” che chiede /.env, non è l’AI che ti legge.

Un “Googlebot” nei log non è un dato finché non verifichi l’IP.
Sullo shop A 3 impostori su 4 hanno ricevuto la pagina come un cliente.

⚠️ Chi consuma davvero il server

Prima di guardare cosa fa Googlebot conviene guardare quanto pesa, perché la risposta cambia il modo di leggere tutto il resto. Richieste per famiglia, dieci giorni:

Sullo shop B Googlebot è lo 0,6% delle richieste: il 97,8% arriva con user agent da browser, ed è in gran parte lo scraping sulla navigazione a faccette che ho raccontato nel caso dei bot sui filtri. Quando un cliente mi dice che “Google gli rallenta il sito”, la prima cosa da guardare è questa tabella: quasi sempre Google è una frazione piccola del carico.

Sullo shop A la sorpresa è Amazonbot: 215.325 richieste in dieci giorni, più di Googlebot, e quasi tutte autentiche: 215.225 dagli IP pubblicati da Amazon. L’89% riguarda immagini dei prodotti, e l’82% delle richieste è stato respinto con un 429 dal limite di frequenza del server. Amazonbot nel robots.txt è controllabile, e per uno shop che non vende su Amazon la domanda da farsi è cosa ci guadagni a servirgli il catalogo fotografico. Stessa logica per Meta AI: le sue 40.884 richieste sullo shop A hanno ricevuto tutte un 403, perché il negozio lo blocca a livello server.

Quanto ai crawler delle AI che citano le fonti, OAI-SearchBot, PerplexityBot e ChatGPT-User, sullo shop A valgono insieme meno dell’1%. Se nel robots.txt stai valutando di bloccarli per “alleggerire il server”, i log dicono che non è da lì che arriva il peso. La scelta su chi bloccare e chi no l’ho affrontata nel pezzo su come bloccare le AI con il robots.txt.

🛠️ Le anteprime di WhatsApp nei log

Fra i bot che non consumano quasi niente ce n’è uno che vale la pena contare. Quando qualcuno incolla un link in una chat, WhatsApp, Telegram, Slack o Facebook scaricano la pagina per costruire l’anteprima, e quel passaggio finisce nei log con il loro user agent. Sullo shop A, in dieci giorni, WhatsApp ha scaricato 364 pagine per costruire un’anteprima, più di 36 al giorno.

Sono condivisioni vere, persone che mandano un prodotto a qualcuno. In GA4 però chi apre quel link arriva spesso come traffico diretto, perché le app di messaggistica di solito non passano il referrer. Wil Reynolds di Seer Interactive ha usato lo stesso segnale, i bot di anteprima visti in Cloudflare, per separare le condivisioni dal traffico diretto generico. Per un negozio italiano, dove i prodotti girano su WhatsApp più che altrove, contare le anteprime per URL è il modo più semplice per sapere quali prodotti la gente si passa, un dato che GA4 non ti dà.

🛠️ Dove finisce il crawl di Googlebot su un PrestaShop

Sulle 147.343 richieste di Googlebot verificate dello shop A, il 98,6% ha ricevuto un 200. Diviso per tipo di pagina:

Le categorie prendono lo 0,5% del crawl. Non è un problema in sé: una volta scoperte, le schede prodotto Googlebot le raggiunge anche dalla sitemap. Però vuol dire che una categoria nuova o riordinata viene riletta raramente: in dieci giorni Googlebot ha visitato 202 delle 365 categorie in sitemap. Se hai appena sistemato testi e link interni di una categoria, dai tempo al crawl prima di giudicare.

Sui prodotti ho incrociato le URL visitate con la sitemap pubblica dello shop: su 25.618 prodotti in sitemap, Googlebot in dieci giorni ne ha visitati 16.929, il 66,1%. Altri 948 prodotti visitati in sitemap non ci sono: schede disattivate o spostate che Googlebot conosce da prima. La distribuzione è molto sbilanciata, perché 3.219 prodotti sono stati visitati una volta sola e 1.367 venti volte o più. Per sapere quali stanno nella seconda metà ti servono i log: Search Console non te lo dice.

⚠️ Le varianti: un terzo delle URL prodotto scansionate

Il dato che non mi aspettavo. Delle 27.604 URL prodotto che Googlebot ha visitato sullo shop A, 9.907, il 35,9%, contengono l’id della combinazione: /categoria/44120-25317-letto-imbottito.html invece di /categoria/44120-letto-imbottito.html. Rispondono 200 e hanno il canonical verso la scheda senza combinazione, quindi non creano un duplicato nell’indice. Ma Googlebot le scarica lo stesso, una per una.

Da dove arrivano l’ho verificato nel codice. In PrestaShop 8.2, ProductLazyArray::getProductURL costruisce il link di un prodotto nelle liste con dentro l’id della combinazione di default, e il canonical senza. Nella categoria “matrimoniale” dello shop A tutti i 24 link della griglia puntano alla versione con la combinazione. Così per ogni prodotto con varianti Googlebot trova due indirizzi: quello della sitemap e del canonical, e quello della griglia. Sui cataloghi dove quasi tutto ha varianti, taglie, colori, misure, la griglia raddoppia le URL da scaricare.

Per il titolare del negozio il senso è semplice: Google legge due volte la stessa scheda, e quella seconda lettura la toglie a un prodotto che magari non ha ancora visto.

Le cause minori, sempre dallo stesso incrocio:

• Prodotti spostati di categoria: 487 prodotti visitati sotto due categorie diverse, per esempio quella vecchia e “prodotti non disponibili”. Oggi il vecchio indirizzo risponde con un 301 verso il nuovo, ed è il comportamento giusto: costa una richiesta in più, finché Googlebot non aggiorna la sua copia.
• Slug riscritti: 28 prodotti visitati con due nomi diversi a parità di id, di solito dopo una correzione del titolo o l’aggiunta dell’EAN.
• Categorie con un trattino davanti allo slug (/-appendiabiti/): un errore di riscrittura degli URL rimasto in giro nei link.

⚠️ Il robots.txt di PrestaShop lascia aperte le rotte dei moduli

Due voci della tabella di prima, più una nascosta fra le schede prodotto, sono crawl sprecato puro, e hanno una causa comune: il robots.txt, il file che dice ai motori dove non entrare, di serie su PrestaShop lascia aperte alcune porte che non servono a nessuno.

/module/blockwishlist/action: 323 richieste, tutte respinte con un 403. È il controller del modulo lista dei desideri, che finisce nei link del tema. Il robots.txt che PrestaShop genera da Preferenze > Traffico e SEO blocca la cartella /modules/, ma non le rotte /module/nome/controller con cui i moduli espongono le loro pagine. L’ho controllato in Tools::getRobotsContent della 8.2: nella lista delle regole /module/ non c’è.

Pagina CMS con orderby e orderway: 430 richieste su /content/1-consegna con parametri di ordinamento dei prodotti che su una pagina di testo non hanno senso. Sono i nomi dei parametri delle vecchie versioni di PrestaShop: link rimasti da prima di un aggiornamento, in pagine esterne o in vecchie copie della sitemap, che Googlebot continua a seguire. Il robots.txt standard blocca ?order=, il parametro della versione attuale, non questi.

srsltid: 747 richieste su URL con il parametro che Google Merchant Center aggiunge ai link delle schede gratuite quando è attivo il tracciamento automatico degli eventi chiave. Il canonical le riporta alla scheda pulita, quindi il danno è solo di crawl. Se non usi quel tracciamento, si spegne in Merchant Center da Impostazioni generali > Configurazione degli eventi chiave.

Le faccette invece, ?q=, sullo shop A rispondono 403 anche a Googlebot: 102 richieste in dieci giorni. È voluto, è il recinto contro gli scraper, e con quei numeri Googlebot le ha quasi abbandonate.

✅ Cosa cambiare, in ordine

1. Aggiungi al robots.txt le rotte dei moduli che non servono ai motori. Non tutto /module/: alcuni moduli, per esempio i blog, espongono lì pagine pubbliche. Si parte da quelle che compaiono nei log con un 403 o un redirect, come la lista dei desideri:

Disallow: /module/blockwishlist/
Disallow: /*orderby=
Disallow: /*orderway=

Ogni rigenerazione dal back office riscrive il robots.txt da zero e cancella le modifiche a mano: le righe aggiunte vanno segnate e rimesse, o gestite con un modulo o un override.

2. Decidi cosa fare dei link alle varianti. Due strade. Se le varianti non hanno contenuto proprio, e di solito è così, si fa in modo che la griglia linki la scheda senza combinazione, con un override del presenter o una modifica nel template della miniatura. Se invece le varianti hanno una domanda di ricerca propria, per esempio misure di materasso cercate una per una, il discorso è un altro e riguarda il canonical, non il crawl. In entrambi i casi prima si guarda nei log quante richieste ci vanno: sotto il 10% delle URL prodotto non vale l’intervento.

3. Guarda le immagini che non esistono più. Googlebot-Image sullo shop A ha preso 3.544 errori 404 su 48.812 richieste, il 7,3%: foto di prodotti cancellati che restano nella sitemap delle immagini o in pagine esterne. La guida di Google sulla gestione del crawl budget conferma che 404 e 410 sono un segnale forte per smettere di chiedere quella risorsa: non sono un danno, ma è una pulizia da fare quando si eliminano prodotti in blocco.

4. Metti un tetto ai bot che non ti portano niente. Per Amazonbot, se non vendi su Amazon, Disallow nel robots.txt, che Amazon dichiara di rispettare; il crawl-delay invece lo ignora. Il 429 che gli dà il server lo rallenta, ma ogni richiesta respinta è comunque lavoro. Per gli scraper con user agent da browser il robots.txt non serve: lì servono le regole server, come nel caso delle faccette.

Google stesso dice che la guida sul crawl budget è pensata per siti da 10.000 pagine in su che cambiano ogni giorno, o da un milione in su con contenuto che cambia ogni settimana. Uno shop da 25.000 prodotti con prezzi e disponibilità che cambiano ci sta dentro. Uno da 800 prodotti di solito no: lì i log servono più per sicurezza e carico del server che per il crawl.

🛠️ Rifarlo sul tuo shop

Servono gli access log: sui pannelli come DirectAdmin o cPanel stanno in una cartella logs del dominio, di solito un archivio compresso per giorno; se non hai accesso al server, nel pezzo sulla diagnosi senza SSH spiego dove trovarli dal pannello. Il conteggio grezzo per user agent si fa con una riga:

zcat access.log*.gz | awk -F'"' '{print $6}' \
  | grep -oiE 'googlebot|bingbot|gptbot|oai-searchbot|chatgpt-user|claudebot|perplexitybot|amazonbot|meta-externalagent' \
  | sort | uniq -c | sort -rn

Per la verifica degli IP basta uno script Python con la libreria standard: scarica gli elenchi ufficiali e per ogni riga controlla se l’IP ci sta dentro. È la versione ridotta di quello che ho usato per questo articolo:

import ipaddress, json, re, sys, urllib.request
from collections import Counter

LISTS = {
    'Googlebot': ['https://developers.google.com/static/crawling/ipranges/common-crawlers.json'],
    'bingbot': ['https://www.bing.com/toolbox/bingbot.json'],
    'GPTBot': ['https://openai.com/gptbot.json'],
    'OAI-SearchBot': ['https://openai.com/searchbot.json'],
    'ChatGPT-User': ['https://openai.com/chatgpt-user.json'],
    'ClaudeBot': ['https://claude.com/crawling/bots.json'],
    'PerplexityBot': ['https://www.perplexity.ai/perplexitybot.json'],
    'Applebot': ['https://search.developer.apple.com/applebot.json'],
}
LINE = re.compile(r'^(\S+) .*"([^"]*)"$')

def ranges(urls):
    nets = []
    for url in urls:
        req = urllib.request.Request(url, headers={'User-Agent': 'Mozilla/5.0'})
        for p in json.load(urllib.request.urlopen(req))['prefixes']:
            nets.append(ipaddress.ip_network(p.get('ipv4Prefix') or p.get('ipv6Prefix')))
    return nets

nets = {bot: ranges(urls) for bot, urls in LISTS.items()}
seen, fake = Counter(), Counter()
for line in sys.stdin:
    m = LINE.match(line.strip())
    if not m:
        continue
    ip, ua = m.groups()
    bot = next((b for b in nets if b.lower() in ua.lower()), None)
    if not bot:
        continue
    try:
        addr = ipaddress.ip_address(ip)
    except ValueError:
        continue
    addr = getattr(addr, 'ipv4_mapped', None) or addr
    seen[bot] += 1
    if not any(addr in n for n in nets[bot]):
        fake[bot] += 1

for bot, n in seen.most_common():
    print(f'{bot:15} {n:8} richieste  {fake[bot]:6} finte ({100 * fake[bot] / n:.1f}%)')

Si lancia con zcat access.log*.gz | python3 verifica_bot.py. Quattro accorgimenti imparati facendolo. Il primo: su un hosting condiviso lancialo con nice -n 19 e su pochi giorni alla volta, perché lo shop B aveva 1,2 GB di log compressi in dieci giorni e l’analisi completa ha tenuto occupato un processore per più di venti minuti, sullo stesso account del negozio. Il secondo: gli archivi di DirectAdmin contengono insieme access log ed error log, e le righe dell’error log vanno escluse, altrimenti i totali non tornano. Il terzo: se il sito sta dietro Cloudflare o un proxy, nel log serve l’IP reale del client, altrimenti anche i bot veri risultano finti. E Googlebot-Image finisce nel conteggio di Googlebot: se vuoi separarlo, mettilo come voce a sé prima di Googlebot.

✅ Cosa ti dicono i log che Search Console non dice

Search Console resta il punto di partenza: il report Statistiche di scansione dà i totali e qualche URL di esempio. I log rispondono alle domande che vengono dopo: quali prodotti Googlebot non visita da settimane, quanta parte del crawl va sulle varianti, chi si spaccia per Googlebot e cosa riceve, quale bot sta consumando davvero il server. Sullo shop A la risposta ha portato a tre righe di robots.txt e a una modifica della miniatura; sullo shop B a capire che Google era l’ultimo dei problemi.

Leggere i log con questo metodo è uno dei controlli che faccio come assistenza tecnica PrestaShop, insieme al peso delle categorie, alla cache e alla sicurezza. Scrivimi da uno dei canali qui sotto con l’indirizzo del negozio: ti dico se i tuoi log sono leggibili, quanti giorni ne conserva l’hosting e da dove partire.

Fonti primarie: Verificare le richieste dei crawler di Google (aggiornata il 20 marzo 2026) e gli elenchi JSON collegati, gestione del crawl budget (aggiornata il 22 luglio 2026), bot di OpenAI, crawler di Anthropic, indirizzi IP di Amazonbot, Applebot, parametro srsltid in Merchant Center, tutte consultate il 30 settembre 2026; codice di PrestaShop 8.2: ProductLazyArray (getProductURL) e Tools (getRobotsContent). Il metodo di verifica con gli elenchi IP e la quota di Googlebot finti su un blog sono anche in EVE Milano, Analisi dei log per la SEO (Giovanni Sacheli, 3 settembre 2026). Dati del 30 settembre 2026 da access log di dieci giorni (20-29 settembre) di due shop PrestaShop reali, anonimi, e di enricomorano.it, elaborati sul server senza estrarre indirizzi IP; sitemap e pagine dello shop A lette dal sito pubblico lo stesso giorno.