Bloccare i falsi Googlebot con .htaccess significa identificare e impedire l’accesso ai bot dannosi che si camuffano da crawler di Google, separando quelli autentici tramite User-Agent, verifica IP e analisi dei log, e fermando solo quelli sospetti con un errore 403. Il metodo più sicuro: non fidarsi solo del User-Agent, usare i range IP ufficiali di Google o la verifica DNS inversa, prima registrare i comportamenti sospetti e poi applicare regole .htaccess mirate.
Molti bot malevoli si presentano come Googlebot, Google-InspectionTool, AdsBot-Google o Googlebot-Image per aggirare firewall e filtri semplici, sapendo che i webmaster raramente bloccano Google. Questa vulnerabilità facilita scraping di contenuti, consumi eccessivi di risorse, traffico finto, spam su moduli, tentativi di login e dati SEO inquinati. Su hosting condiviso, WordPress, WooCommerce, siti di news e blog aggiornati, questo traffico può rapidamente saturare CPU, RAM e limiti I/O. In questa guida scoprirai come leggere il comportamento dei falsi Googlebot, scrivere regole .htaccess sicure su Apache e verificare che i crawler autentici di Google non vengano bloccati per errore. Se cerchi un’infrastruttura performante e scalabile, includi anche Soluzioni web hosting Hostragons e installazione del certificato SSL nel tuo piano.
Cos’è un falso Googlebot e perché è pericoloso?
Un falso Googlebot è un bot automatico che si presenta come Googlebot nel campo User-Agent delle richieste HTTP, ma proviene da IP che non appartengono a Google. Il User-Agent è solo una stringa che identifica il client: chiunque può scrivere “Googlebot” e simulare il crawler. Ecco perché basarsi solo su User-Agent è rischioso.
Il vero Googlebot serve per indicizzare il tuo sito, rilevare aggiornamenti e raccogliere segnali per il ranking. I falsi Googlebot invece hanno obiettivi diversi: possono estrarre prezzi, copiare contenuti, cercare URL amministrativi, sovraccaricare pagine di ricerca o individuare plugin vulnerabili. Alcuni bot inviano decine di richieste al secondo, causando rallentamenti anche su siti piccoli.
I segnali tipici di bot sospetti sono:
- Richieste che generano centinaia di errori 404, 403 o 500 in breve tempo.
- Scansione di percorsi sensibili come wp-login.php, xmlrpc.php, admin, phpmyadmin, backup.zip.
- User-Agent Googlebot, ma IP non nei range ASN o ufficiali di Google.
- Accesso a pagine di filtro, ricerca, carrello o account ignorando robots.txt.
- Richieste ripetute ad alta frequenza sugli stessi URL, molto più del normale Googlebot.
Perché il controllo User-Agent non basta?
Scrivere “Googlebot” nell’header HTTP non prova che il bot sia di Google. Da terminale, ad esempio, si può simulare facilmente con curl. Bloccare o permettere tutti i “Googlebot” solo in base al User-Agent è sbagliato: rischi di bloccare il crawler vero o lasciare libero quello falso.
Nel 2026 la strategia SEO e security si basa su tre livelli: verifica identità dichiarata, controllo IP/DNS, monitoraggio dei comportamenti anomali nei log. Così proteggi la visibilità su Google e pulisci le risorse del server dai bot inutili.
Come verificare il vero Googlebot?
Google suggerisce due metodi principali: verifica DNS inversa e controllo IP ufficiali. Nel DNS inverso, l’IP deve risolvere in un dominio che termina con googlebot.com o google.com, e la risoluzione diretta di quel dominio deve restituire lo stesso IP. Questo doppio controllo evita falsificazioni tramite PTR record.
L’alternativa è usare i range IP pubblicati da Google. Per Googlebot, tool speciali e fetcher azionati dagli utenti, esistono liste JSON dedicate. Queste liste cambiano nel tempo: non è sicuro fidarsi di vecchie liste statiche. Se gestisci un VPS/server, scarica periodicamente le liste e aggiornale come firewall o file include Apache. Su hosting condiviso, usa log accessi, .htaccess e gli eventuali moduli di sicurezza del pannello.
Logica di blocco dei falsi Googlebot con .htaccess
.htaccess permette di definire regole per directory su Apache: redirect, controllo accessi, compressione, cache e restrizioni di sicurezza. Bloccare i falsi Googlebot significa valutare le richieste secondo certe condizioni e restituire 403 Forbidden a quelle sospette.
Limite importante: .htaccess non è il luogo ideale per query DNS inversa in tempo reale; HostnameLookups di Apache è spesso disattivato per motivi di performance. La soluzione pratica è confrontare User-Agent Googlebot con una allowlist IP, oppure filtrare con più durezza i percorsi critici. Per controlli più avanzati, usa WAF, firewall server, CDN o automazioni basate sui log. che cos'è il CDN e il suo impatto sulle prestazioni del sito web ti aiuta a pianificare questo livello.
Step by Step: individuare e bloccare i falsi Googlebot
1. Analizza i log di accesso
Prima di scrivere regole, analizza almeno 24-72 ore di access log. Se hai molto traffico, anche un’ora di log basta. Controlla IP, data, URL richiesto, status HTTP, dimensione, referer e User-Agent. Ad esempio, se un IP invia 800 richieste in 10 minuti, la maggior parte con errori e User-Agent Googlebot, è un forte indizio di attività sospetta.
Su cPanel o simili, scarica i log da Raw Access Logs. Con accesso SSH puoi filtrare le richieste Googlebot con grep, awk e sort, individuando gli IP più attivi. L’obiettivo è capire il comportamento degli IP che si dichiarano Googlebot, non solo la presenza del User-Agent.
2. Verifica gli IP che si dichiarano Googlebot
Identifica gli IP sospetti e controlla DNS inverso e diretto. Se il PTR record appare come crawl-66-249-66-1.googlebot.com supera il primo controllo. Poi, risolvi il dominio: deve tornare lo stesso IP. Se manca il PTR, risolve su un altro dominio o la risoluzione non coincide, non è Googlebot autentico.
Questo è essenziale per siti SEO-critical: bloccare Googlebot vero rallenta l’indicizzazione, abbassa la freschezza, genera errori di crawl su Search Console e può ridurre il traffico organico. Non basta una regola User-Agent, serve la verifica completa.
3. Prima osserva, poi blocca
In sicurezza, meglio monitorare prima di bloccare. Segna IP e User-Agent sospetti. Poi limita solo i percorsi che mostrano segni di abuso. Infine, blocca le richieste che si dichiarano Googlebot ma arrivano da IP non ufficiali.
Questo è cruciale su siti e-commerce: una regola errata può danneggiare checkout, carrello, varianti prodotto o integrazioni di stock. Se hai molto traffico, testa prima in ambiente staging. Trasferimento del sito WordPress e creazione di un ambiente di test aiuta a sperimentare senza rischi.
Esempi di regole .htaccess sicure
Questi esempi vanno testati prima della messa in produzione, verificando versione Apache, moduli attivi e permessi hosting. Apache 2.4 e mod_rewrite sono standard, ma alcune direttive possono essere limitate su hosting condiviso. Backup sempre il file .htaccess: un errore nel file può causare 500 Internal Server Error.
Filtro comportamentale: bloccare bot falsi su percorsi sensibili
Questo metodo impedisce ai bot che si presentano come Googlebot di accedere a file di amministrazione e backup. Googlebot autentico non ha motivo di scansionare wp-login.php, phpmyadmin o file zip di backup, quindi il rischio di falsi positivi è basso.
- RewriteEngine On
- RewriteCond %{HTTP_USER_AGENT} (Googlebot|Google-InspectionTool|AdsBot-Google|Mediapartners-Google) [NC]
- RewriteCond %{REQUEST_URI} (wp-login[.]php|xmlrpc[.]php|phpmyadmin|adminer|backup|[.]sql|[.]zip) [NC]
- RewriteRule ^ - [F,L]
Questa regola restituisce 403 se un client si dichiara Googlebot e accede a percorsi critici. L’impatto SEO è minimo: queste URL non devono essere indicizzate. Su WordPress, verifica però plugin di sicurezza, uso di XML-RPC e servizi di pubblicazione remota.
Allowlist IP: confrontare User-Agent Googlebot con IP ufficiali
Metodo più robusto: permette solo le richieste Googlebot da IP affidabili. L’esempio mostra la logica, ma i range IP vanno aggiornati dalle liste ufficiali Google. Liste obsolete possono bloccare anche Googlebot autentico.
- RewriteEngine On
- RewriteCond %{HTTP_USER_AGENT} (Googlebot|Googlebot-Image|Googlebot-News|Google-InspectionTool|AdsBot-Google) [NC]
- RewriteCond expr "! ( %{REMOTE_ADDR} -ipmatch '66.249.64.0/19' || %{REMOTE_ADDR} -ipmatch '64.233.160.0/19' || %{REMOTE_ADDR} -ipmatch '72.14.192.0/18' )"
- RewriteRule ^ - [F,L]
Gli IP qui sono solo esempi. In produzione usa i range generati dal JSON Googlebot IP ufficiale. Se il tuo Apache non supporta -ipmatch o le espressioni, chiedi al provider di attivare Apache 2.4. In alternativa, crea regole su CDN/WAF.
Limitare richieste sospette
.htaccess non è il migliore per rate limiting avanzato, ma può bloccare comportamenti malevoli. Per limiti veri usa mod_evasive, mod_security, rate limit CDN o protezioni applicative. Bot che superano 5-10 richieste al secondo possono saturare database anche su siti piccoli. Su WordPress, le pagine di ricerca, categorie filtrate e tag sono spesso bersagli di bot. Qui robots.txt, canonical, noindex e regole di sicurezza vanno pianificate insieme. Guida all'ottimizzazione della velocità di WordPress completa il lato performance.
Tabella di confronto: quale metodo usare e quando?
| Metodo | Punto di forza | Limite | Uso consigliato |
|---|---|---|---|
| Solo controllo User-Agent | Molto facile da implementare | Facile da imitare, alto rischio di errore | Non consigliato da solo; solo come filtro preliminare |
| Verifica DNS inversa | Affidabile per autenticare Googlebot | Non pratico su .htaccess, richiede automazione | Usato in analisi log, WAF o sul server |
| Allowlist IP Google | Blocco rapido ed efficace | Se la lista non è aggiornata, rischi falsi positivi | Ideale su Apache, firewall o CDN |
| Blocco basato sul comportamento | Protegge percorsi sensibili e pattern di attacco | Non autentica l’identità | Efficace su login, xmlrpc, backup e scan admin |
| Protezione CDN/WAF | Rate limit, punteggio bot e gestione centralizzata | Se mal configurata, può impattare utenti veri | Consigliata su siti trafficati, ecommerce e aziendali |
Checklist per non bloccare Googlebot autentico per errore

Il rischio principale è bloccare il vero Googlebot. Dopo ogni modifica, esegui questi controlli:
- Verifica su Search Console se ci sono cali improvvisi o aumento di errori 403 nel report Crawl Stats.
- Controlla nei log server che le richieste da IP Google autentici ricevano codici 200, 301 o corretti.
- Assicurati che robots.txt non blocchi Googlebot su directory importanti.
- Dopo ogni modifica .htaccess, testa sitemap, homepage, categorie e pagine prodotto principali.
- Documenta la fonte e la data di aggiornamento della lista IP usata.
Il codice 403 è un segnale forte per SEO. Se Googlebot riceve ripetuti 403 su pagine importanti, diminuisce la scansione. Usa 403 solo su bot indesiderati e percorsi critici. Per manutenzione o rallentamenti temporanei, il codice 429 Too Many Requests può essere più adeguato, ma 403 resta il più diffuso e chiaro su .htaccess.
Misure extra per WordPress e siti e-commerce
Su WordPress, il traffico dei falsi Googlebot si concentra spesso su xmlrpc.php, wp-login.php, API REST, URL di ricerca e archivi autore. Su ecommerce, bersagliano parametri filtro, richieste stock, carrello e varianti prodotto. Proteggi non solo dai Googlebot falsi, ma migliora l’igiene dei bot in generale.
- Usa autenticazione a due fattori e limiti di tentativi su pagina login.
- Disattiva o restringi le funzioni XML-RPC non necessarie.
- Su URL di ricerca e filtro, pianifica noindex, canonical e robots.txt insieme.
- Usa versioni PHP aggiornate, temi e plugin affidabili.
- SSL sempre attivo; HTTPS obbligatorio per sessioni e form. Certificati SSL Hostragons
- Controlla regolarmente record DNS del dominio; errori DNS e email aumentano i rischi. Verifica del dominio e gestione DNS
Impatto sul performance: come il traffico bot consuma risorse hosting
Il traffico bot è un problema non solo di sicurezza, ma anche di performance hosting. Una richiesta di immagine statica costa poco; una ricerca WordPress o filtro WooCommerce richiede query database. Un falso Googlebot che manda 300 richieste dinamiche al minuto può saturare i worker PHP, aumentare le connessioni DB e rallentare gli utenti veri.
Esempio: una pagina filtro prodotto consuma 250 ms di PHP in media. 600 richieste bot/minuto generano 150 secondi di carico. In parallelo, la CPU si avvicina al limite e il TTFB aumenta. Core Web Vitals peggiora, con impatto diretto su UX e conversioni. Bloccare bot non è solo compito security, ma anche SEO e performance.
Test: le tue regole funzionano?
Dopo aver aggiunto regole .htaccess, fai tre test. Primo: naviga homepage, categorie e flussi login con browser normale. Secondo: usa lo strumento URL Inspection di Search Console per test live su una pagina importante. Terzo: verifica nei log che gli IP sospetti con User-Agent Googlebot ricevano 403, mentre quelli verificati siano accettati.
Da terminale puoi simulare User-Agent Googlebot, ma questo non prova che tu sia Googlebot vero: serve solo a testare la parte User-Agent della regola. La verifica reale deve essere su IP e DNS. Se ricevi 500 error, controlla sintassi .htaccess, ripristina le ultime modifiche, ispeziona i log errori e verifica le direttive Apache supportate.
Piano di manutenzione: ogni quanto aggiornare le regole?
Bloccare bot non è una procedura “una tantum”. Range IP di Google cambiano, i pattern User-Agent evolvono, la struttura URL del sito si modifica. Su siti poco trafficati, basta un controllo log mensile. Su news, ecommerce e campagne, meglio settimanale. Su progetti grandi, imposta allarmi automatici: ad esempio, se le richieste User-Agent Googlebot da IP non verificati superano una soglia, ricevi una notifica.
Versiona anche il file .htaccess: basta un backup datato (es. htaccess-2026-02-15.bak) per ripristinare rapidamente. Se più persone gestiscono il sito, aggiungi note su chi e perché ha inserito ogni regola: riduce il rischio di downtime.
Conclusioni
Bloccare i falsi Googlebot con .htaccess, se fatto bene, protegge la visibilità SEO e le risorse server dai crawler malevoli. Il principio base: User-Agent non basta; valuta IP, DNS, comportamento e log insieme. Prima osserva, poi limita i percorsi a basso rischio, infine applica blocco basato su allowlist IP aggiornata.
Con Hostragons, pianifica hosting sicuro, SSL attuale, DNS corretto e backup regolari per una web experience stabile. Puoi partire analizzando il traffico bot del tuo sito, e quando necessario, scegliere Pacchetti Hosting Hostragons per una struttura più sicura e performante.
Domande frequenti
I falsi Googlebot possono influire sul ranking Google?
Sì, indirettamente. Se consumano risorse, rallentano utenti e Googlebot veri. Inoltre, inquinano i log e i dati di analisi, portando a decisioni SEO errate. Bloccare correttamente aiuta a preservare budget crawl e performance.
È corretto bloccare tutti i User-Agent Googlebot con .htaccess?
No. Così rischi di bloccare il crawler autentico e causare problemi di indicizzazione. Le richieste “Googlebot” vanno prima verificate su IP o DNS; blocca solo se sono falsi. Il metodo migliore combina allowlist IP e regole comportamentali.
Quanto spesso aggiornare la lista IP di Googlebot?
Settimanale per siti trafficati, mensile per siti piccoli. Il modo migliore: genera liste automaticamente dai JSON ufficiali Google. Liste vecchie possono causare blocchi accidentali del Googlebot vero.
Dopo una regola .htaccess ricevo errore 500, cosa fare?
Errore 500 di solito è dovuto a sintassi sbagliata, direttiva Apache non supportata o caratteri errati. Ripristina le ultime regole, controlla i log errori e verifica che il tuo hosting supporti Apache 2.4, mod_rewrite e le espressioni. Backup prima di ogni modifica è fondamentale.
Se uso CDN o WAF, serve ancora la regola .htaccess?
CDN/WAF sono ottimi per filtrare bot, ma .htaccess offre protezione aggiuntiva vicino all’applicazione. Il risultato migliore si ottiene usando rate limit e validazione bot su CDN/WAF, e restrizioni mirate su percorsi sensibili via .htaccess.