Otkrivanje i blokiranje lažnih Googlebota pomoću .htaccess predstavlja proces prepoznavanja štetnih botova koji se pretvaraju da su Googlebot, na temelju korisničkog agenta, IP adresa i dnevnika pristupa, te njihovo zaustavljanje sa statusom 403, bez utjecaja na stvarne Googleove pretraživače. Najsigurnija metoda uključuje ne oslanjanje samo na vrijednost User-Agent-a, već i korištenje službenih IP raspona Googlea ili obrnute DNS provjere, prvo bilježenje, a zatim kontrolirano blokiranje putem .htaccess pravila.
Mnogi napadački botovi predstavljaju se kao Googlebot, Google-InspectionTool, AdsBot-Google ili Googlebot-Image kako bi zaobišli vatrozide i jednostavne filtre. Budući da se vlasnici web stranica obično boje blokirati Googleovu pretragu, to otvara mogućnost za probleme poput preuzimanja sadržaja, visoke potrošnje resursa, lažnog prometa, spamovanja obrazaca, pokušaja prijave i onečišćenja SEO podataka. Ovaj promet može brzo iscrpiti CPU, RAM i I/O limite, posebno na dijeljenim hosting uslugama, WordPressu, WooCommerceu, vijestima i često ažuriranim blogovima. U ovom vodiču ćemo korak po korak obraditi kako čitati ponašanje lažnih Googlebota, kako pisati sigurna pravila s Apache .htaccess i koje provjere trebate izvršiti kako ne biste slučajno blokirali stvarni Googlebot. Ako vam je potrebna sigurna, brza i skalabilna infrastruktura za vašu web stranicu, možete uključiti i Hostragons rješenja za web hosting te Instalacija SSL certifikata u svoj plan.
Što su lažni Googleboti i zašto su opasni?
Lažni Googlebot je automatski pretraživač koji se predstavlja kao Googlebot u HTTP zahtjevu, ali dolazi s IP adresa koje nisu povezane s Googleom. User-Agent je jednostavan tekst kojim se klijent identificira; dakle, tehnički, svatko može napisati Googlebot u svom zahtjevu. Iz tog razloga, samo provjeravanje User-Agent-a nije dovoljno za sigurnost.
Prava svrha Googlebota je pregledavanje vaše stranice, indeksiranje, otkrivanje ažuriranja stranica i prikupljanje kvalitativnih signala za rezultate pretraživanja. Lažni Googlebot, s druge strane, dolazi s različitim ciljevima. Na primjer, može prikupiti cijene proizvoda, kopirati vaš sadržaj, pokušati pristupiti URL-ovima administrativnog panela, opteretiti vaše stranice s rezultatima pretraživanja ili skenirati ranjivosti slabih dodataka. Neki napadači mogu slati desetke zahtjeva u sekundi, uzrokujući pad performansi čak i na malim stranicama.
U praksi, lažne botove najčešće prepoznajemo po sljedećim znakovima:
- Veliki broj 404, 403 ili 500 odgovora u kratkom vremenu.
- Skeniranje osjetljivih putanja poput wp-login.php, xmlrpc.php, admin, phpmyadmin, backup.zip.
- Iako se User-Agent prikazuje kao Googlebot, IP adresa nije u Google AS-u ili službenim IP rasponima.
- Pregledavanje stranica bez poštivanja pravila robots.txt, kao što su filteri, pretraživanje, košarice ili računi.
- Zahtjevi za istim URL-ovima s prekomjernom učestalošću u odnosu na normalnog Googlebota.
Zašto samo provjera User-Agent-a nije dovoljna?
To što bot u HTTP zaglavlju piše Googlebot ne dokazuje da pripada Googleu. Na primjer, User-Agent se može lako imitirati jednostavnim curl zahtjevom u komandnoj liniji. Stoga je greška u .htaccess-u samo zadržati sve zahtjeve koji sadrže riječ Googlebot, jer to može blokirati pravi Googleov pregled, dok otvaranje svih tih zahtjeva ostavlja vrata otvorena za napadače.
U 2026. godini, pristup SEO-u i sigurnosti trebao bi biti trostruk: provjeriti navodnu identifikaciju, potvrditi putem IP-a ili DNS-a, pratiti abnormalna ponašanja kroz logove. Ovaj pristup čuva vašu vidljivost na Googleu i oslobađa resurse servera od nepotrebnih botova.
Kako provjeriti pravi Googlebot?
Google preporučuje dvije glavne metode za potvrdu svojih pravih preglednika: obrnuta DNS provjera i službeni IP rasponi. U metodi obrnute DNS provjere, domena IP adrese koja šalje zahtjev trebala bi završavati s googlebot.com ili google.com, a zatim se ta domena mora ponovno riješiti u istu IP adresu. Ova dvosmjerna provjera sprječava obmanu lažnim PTR zapisom.
Druga metoda je korištenje službenih IP raspona koje je Google objavio. Googlebot objavljuje različite JSON liste za posebne preglednike i korisnički aktivirane alate. Budući da se dinamičke liste mogu mijenjati s vremenom, nije ispravno oslanjati se na ručno napisane stare IP liste u produkcijskom okruženju. Ako upravljate VPS-om ili serverom, najbolje je redovito preuzimati te liste i ažurirati ih kao firewall ili uključene datoteke za Apache. Ako koristite dijeljeni hosting, možete napredovati uz kontrolu pristupnih dnevnika u svom upravljačkom panelu, .htaccess i, ako je potrebno, sigurnosne module.
Logika blokiranja lažnih Googlebota putem .htaccess-a
.htaccess omogućuje definiranje pravila na razini direktorija na Apache web serveru. Koristi se za preusmjeravanje URL-a, kontrolu pristupa, kompresiju, keširanje i osnovna sigurnosna ograničenja. U blokiranju lažnih Googlebota, zadatak .htaccess-a je procijeniti dolazni zahtjev prema određenim uvjetima i zaustaviti sumnjive zahtjeve s odgovorom 403 Forbidden.
Međutim, postoji važna ograničenja: standardni .htaccess nije idealno mjesto za izvođenje stvarnih obratnih DNS upita u stvarnom vremenu. U Apacheu je HostnameLookups obično isključen zbog performansi. Stoga je najpraktičnija metoda u .htaccess-u usporediti zahtjeve koji tvrde da su Googlebot s IP allowlistom ili rigoroznije filtrirati sumnjive putanje. Za napredniju provjeru koristi se WAF, firewall servera, CDN ili automatizacija koja se hrani iz dnevnika. što je CDN i njegov utjecaj na performansu web stranice može vam pomoći u planiranju ovog sloja.
Korak po korak primjena: Otkrivanje i blokiranje lažnih Googlebota
1. Istražite pristupne dnevnike
Prije nego što napišete pravilo za blokiranje, pregledajte pristupne dnevnike tijekom najmanje 24-72 sata. Ako je vaš promet visok, čak i jedan sat dnevnika može dati dovoljno signala. Područja na koja trebate obratiti pažnju su IP adresa, datum, traženi URL, HTTP statusni kod, veličina bajta, referer i User-Agent informacija. Na primjer, ako ista IP adresa pošalje 800 zahtjeva u 10 minuta, većina njih se vraća s 404 i predstavlja se kao Googlebot, to je snažan signal sumnje.
U cPanelu ili sličnim panelima možete preuzeti logove iz odjeljka Raw Access Logs. Ako imate SSH pristup, možete koristiti alate kao što su grep, awk i sort za filtriranje gustoće na bazi IP-a kako biste izbacili zahtjeve koji se predstavljaju kao Googlebot. Cilj je vidjeti ponašanje IP-ova koji nose ovu tvrdnju, a ne samo svaki zahtjev koji sadrži riječ Googlebot.
2. Potvrdite IP-ove koji tvrde da su Googlebot
Nakon što ste identificirali sumnjive IP-ove, izvršite obrnute DNS i napredne DNS provjere. Ako PTR zapis za IP izgleda kao crawl-66-249-66-1.googlebot.com, to prolazi prvu fazu. Zatim, kada ponovno riješite tu domenu, trebala bi se vratiti na istu IP adresu. Ako PTR zapis ne postoji, vodi na drugu domenu ili napredna provjera ne daje istu IP adresu, taj IP se ne bi trebao smatrati stvarnim Googlebotom.
Ova provjera posebno je važna na web stranicama kritičnim za SEO, jer blokiranje stvarnog Googlebota može dovesti do kasnijeg otkrivanja novih sadržaja, smanjenja svježine indeksa, grešaka u pretraživanju u Google Search Console i odgođenih gubitaka u organskom prometu. Stoga odluku o blokiranju trebate donositi putem procesa provjere, a ne jednostavno na temelju jedne linije pravila za User-Agent.
3. Prvo bilježenje, zatim blokiranje
U sigurnim operacijama preporučuje se kratka faza promatranja umjesto izravnog blokiranja. U prvoj fazi zabilježite sumnjive IP adrese i User-Agent-e. U drugoj fazi ograničite samo putanje koje pokazuju očito zloćudno ponašanje. U trećoj fazi blokirajte zahtjeve koji se predstavljaju kao Googlebot, a nisu u Googleovim IP rasponima.
Ovaj pristup je posebno važan na e-trgovinskim stranicama. Jer pogrešno pravilo može utjecati na kritične tokove kao što su plaćanja, košarice, varijacije proizvoda ili integracije zaliha. Ako vaša stranica prima visoki promet, prvo testirajte u testnom okruženju. Procesi poput Premještanje WordPress stranice i izrada testnog okruženja čine promjene sigurnosnih pravila manje riskantnima.
Primjeri sigurnih .htaccess pravila
Sljedeći primjeri trebaju biti testirani prema verziji Apachea vašeg servera, aktivnim modulima i dozvolama hostinga prije nego što ih izravno kopirate u produkcijsko okruženje. Apache 2.4 i mod_rewrite obično se podržavaju; međutim, u nekim dijeljenim okruženjima određene direktive mogu biti ograničene. Prije nego što uredite svoj .htaccess, obavezno napravite sigurnosnu kopiju. Jedna greška u pisanju može uzrokovati 500 Internal Server Error na vašoj web stranici.
Jednostavni filtar ponašanja: Zaustavljanje lažnih botova na osjetljivim putanjama
Ovaj pristup sprječava botove koji se predstavljaju kao Googlebot da pristupe datotekama koje su ciljevi napada ili administracije. Pravi Googlebot ne treba skenirati wp-login.php, phpmyadmin ili backup zip datoteke. Stoga je rizik od lažnih pozitivnih rezultata nizak.
- 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]
Ovo pravilo vraća 403 ako klijent koji se predstavlja kao Googlebot pokuša pristupiti osjetljivim putanjama. Vjerojatnost da će utjecati na SEO pregled je niska, jer se ne želi da te putanje budu uključene u Googleovu indeksaciju. Ipak, ako koristite WordPress, trebate provjeriti sigurnosne dodatke, potrebe za XML-RPC-om i udaljene usluge objavljivanja.
IP Allowlist logika: Usporedba tvrdnji Googlebota s službenim rasponima
Jača metoda je propuštanje zahtjeva koji tvrde da su Googlebot samo ako dolaze iz pouzdanih IP raspona. Sljedeći primjer pokazuje simboličku logiku; IP rasponi trebaju biti generirani prema ažuriranim službenim Googleovim popisima. Stare ili nepotpune liste mogu slučajno blokirati pravi Googlebot.
- 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]
Ovdje navedeni IP rasponi su dani samo kao primjer. U produkciji treba koristiti automatski generirane rasponi iz Googleove ažurirane IP JSON liste. Ako vaša Apache izraza ili -ipmatch nisu podržani na vašem serveru, potvrdite podršku za Apache 2.4 od svog pružatelja hostinga. Alternativno, možete stvoriti pravilo s IP listom na CDN/WAF sloju.
Smanjenje brzine sumnjivih zahtjeva
.htaccess nije najbolji alat za napredne limite brzine; međutim, može biti koristan za rano zaustavljanje nekih loših ponašanja. Za pravi limit brzine, trebali bi se koristiti mod_evasive, mod_security, CDN limitiranje brzine ili zaštita na razini aplikacije. Botovi koji kontinuirano šalju više od 5-10 zahtjeva u sekundi mogu čak povećati upite na bazu podataka, čak i na malim stranicama. Dinamički sustavi poput WordPressa mogu biti iskorišteni botovima na stranicama rezultata pretraživanja, filtriranim kategorijama i oznakama. Za ta područja, treba razmotriti kombiniranje robots.txt, kanonikalnih oznaka, noindex i sigurnosnih pravila. Vodič za optimizaciju brzine WordPressa završava dio o performansama.
Usporedna tablica: Kada koristiti koju metodu?
| Metoda | Snaga | Slabost | Preporučena upotreba |
|---|---|---|---|
| Samo provjera User-Agent-a | Vrlo lako se postavlja | Lako se imitira, visoki rizik od pogrešnih odluka | Ne preporučuje se samo; koristi se samo kao prefiltrar |
| Obrnuta DNS provjera | Pouzdana je za potvrdu stvarnog Googlebota | Nije praktična unutar .htaccess-a, zahtijeva automatizaciju | Koristi se u analizi logova, WAF-u ili provjeri na strani servera |
| Google IP allowlist | Osigurava brzu i provedivu blokadu | Može izazvati lažne pozitivne rezultate ako se lista ne ažurira | Idealno je za Apache, firewall ili pravila CDN-a |
| Blokiranje temeljen na ponašanju | Štiti osjetljive putanje i obrasce napada | Ne provodi autentifikaciju | Učinkovita je na wp-login, xmlrpc, backup datotekama i administrativnim skeniranjem |
| CDN/WAF zaštita | Pruža limitiranje brzine, ocjenu botova i centralizirano upravljanje pravilima | Može utjecati na stvarne korisnike ako se pogrešno konfigurira | Preporučuje se za visoki promet, e-trgovinu i korporativne stranice |
Kontrolna lista za sprječavanje slučajnog blokiranja stvarnog Googlebota

Kada blokirate lažne Googlebote, najveći rizik je blokiranje pravih Google pretraživača. Kako biste to spriječili, primijenite kratku kontrolnu listu nakon svake promjene:
- Provjerite postoji li nagli pad ili porast 403 odgovora u izvješću o statistikama pretraživanja Google Search Console.
- Pregledajte server logove kako biste vidjeli vraćaju li zahtjevi koji dolaze s pravih Google IP adresa 200, 301 ili odgovarajuće statusne kodove.
- Osigurajte da vaš robots.txt ne blokira pristup kritičnim direktorijima osim onih koji su zatvoreni za Googlebot.
- Testirajte svoj sitemap, početnu stranicu, kategorije i važne stranice proizvoda prije i nakon promjene .htaccess-a.
- Dokumentirajte izvor i datum ažuriranja IP liste koju koristite.
Iz tehničkog SEO-a, 403 odgovor je snažan signal. Ako pravi Googlebot više puta vidi 403 na važnim stranicama, to može smanjiti preglednost tih URL-ova. Stoga se 403 trebaju primjenjivati samo na botove koje apsolutno ne želite i na osjetljive putanje. U slučajevima održavanja, privremene gustoće ili limita brzine, 429 Too Many Requests može biti prikladniji u nekim scenarijima; međutim, 403 je mnogo češći i razumljiviji u jednostavnoj blokadi botova putem .htaccess-a.
Dodatne mjere za WordPress i e-trgovinske stranice
Na WordPress stranicama, lažni Googlebot promet obično se koncentrira na xmlrpc.php, wp-login.php, REST API krajnje točke, URL-ove pretraživanja i arhive autora. Na e-trgovinskim stranicama, ciljaju se parametri filtra, upiti za zalihe, krajnje točke košarice i varijacije proizvoda. Stoga biste trebali obraditi ne samo one koji se pretvaraju da su Googlebot, već i općenitu higijenu botova.
- Koristite dvostruku autentifikaciju i limit pokušaja prijave na stranici za prijavu.
- Onemogućite ili ograničite XML-RPC funkcije koje ne koristite.
- Planirajte strategiju noindex, kanonikalne oznake i robots.txt zajedno na URL-ovima pretraživanja i filtriranja.
- Korisite ažuriranu verziju PHP-a, ažuriranu temu i pouzdane dodatke.
- Održavajte aktivan SSL certifikat; HTTPS je obavezan za sigurne sesije i slanje obrazaca. Hostragons SSL certifikati
- Redovito provjeravajte DNS zapise svog domene; pogrešni DNS i slabi e-mail zapisi povećavaju sigurnosne rizike. Provjera domene i upravljanje DNS-om
Utjecaj na performanse: Kako bot promet troši resurse servera?
Bot promet nije samo problem sigurnosti; on je i problem performansi hostinga. Dok je zahtjev za statičkom slikom jeftin, WordPressov zahtjev za stranicama rezultata pretraživanja ili WooCommerce filtrirani zahtjev generira upite na bazi podataka. Ako lažni Googlebot šalje 300 dinamičkih zahtjeva u minuti, nepredmemorirane stranice mogu napuniti PHP radnike, povećati veze na bazu podataka i usporiti stvarne korisnike.
Uzmimo jednostavan primjer: ako stranica za filtriranje proizvoda troši prosječno 250 ms vremena obrade PHP-a, 600 bot zahtjeva u minuti generira opterećenje od 150 sekundi. Ovo opterećenje, kada se odvija paralelno, približava se limitu CPU-a i povećava TTFB vrijednosti. Na Core Web Vitals strani, spori odgovori servera neizravno utječu na korisničko iskustvo i stope konverzije. Stoga je blokiranje botova dio ne samo sigurnosnog tima, već i SEO-a i optimizacije performansi.
Testiranje: Funkcioniraju li vaša pravila?
Nakon dodavanja pravila u .htaccess, provedite tri testa. Prvo, provjerite glavnu stranicu vaše web stranice, važne kategorijske stranice i tijekove prijave s normalnim preglednikom. Drugo, testirajte važnu URL adresu u Google Search Console alatu za provjeru URL-a. Treće, provjerite logove da biste vidjeli primaju li sumnjivi IP-ovi koji dolaze s User-Agent-om Googlebot 403, dok IP-ovi koji prolaze stvarnu Googleovu provjeru nisu blokirani.
Ako testirate putem komandne linije, možete se predstaviti kao Googlebot; međutim, ovaj test ne dokazuje da ste stvarno Googlebot, već samo pomaže u razumijevanju aktivira li se dio pravila za User-Agent. Prava provjera trebala bi se provoditi putem IP-a i DNS-a. Ako na kraju testa dobijete 500 grešku, to može značiti da imate grešku u sintaksi u svom .htaccess. U tom slučaju, vratite posljednje dodane linije, pregledajte logove grešaka i provjerite podržane Apache direktive na vašem serveru.
Plan održavanja: Kako često ažurirati pravila?
Blokiranje botova nije jednokratni postupak. Google IP rasponi se mogu mijenjati, napadači mogu mijenjati uzorke User-Agent-a, a struktura URL-a vaše stranice može se s vremenom ažurirati. Na stranicama s niskim prometom, mjesečna provjera logova može biti dovoljna. Na prometnim vijestima, e-trgovini ili kampanjama, tjedna provjera je zdravija. Za velike projekte, postavljanje automatskog alarma je najbolje rješenje; na primjer, kada broj zahtjeva koji dolaze s IP-ova koji nose User-Agent Googlebot, a ne mogu se potvrditi, premaši određeni prag, može se generirati obavijest.
Osim toga, verzionirajte svoj .htaccess. Jednostavno uzimanje datuma kao sigurnosne kopije može ubrzati povratak u slučaju problema. Na primjer, možete zadržati povijest promjena pomoću naziva datoteka kao što su htaccess-2026-02-15.bak. Ako više osoba upravlja stranicom, bilježenje kratkih napomena o tome što je osoba dodala i zašto može smanjiti rizik od prekida.
Zaključak
Otkrivanje i blokiranje lažnih Googlebota pomoću .htaccess može, ako se pravilno primijeni, očuvati vašu SEO vidljivost i osloboditi servere od zlonamjernih preglednika. Temeljno načelo je jasno: User-Agent nije sam po sebi dokaz; IP, DNS, ponašanje i analiza logova trebaju se procijeniti zajedno. Prvo promatrajte, zatim ograničite niskorizične putanje, a na kraju primijenite blokiranje temeljeno na provjeri s ažuriranim Google IP listama.
Planiranjem sigurnog hostinga, ažurnog SSL-a, ispravnog DNS-a i redovitih sigurnosnih kopija dok hostate svoju stranicu na Hostragons infrastrukturi, osiguravate dugoročnije stabilno web iskustvo. Možete započeti analizom bot prometa vaše postojeće stranice, a kada vam zatreba, odaberite snažniju i sigurniju strukturu putem Hostragons paketi hostinga.
Česta pitanja
Utječe li lažni Googlebot na moje stvarne Google rankinge?
Neizravno, da. Ako lažni Googlebot troši resurse servera, stvarni korisnici i pravi Googlebot mogu primiti sporije odgovore. Također, može zamutiti logove i analitičke podatke, dovodeći u zabludu vaše SEO odluke. Pravilno blokiranje pomaže u očuvanju budžeta za pretraživanje i performansi.
Je li ispravno blokirati sve Googlebot User-Agent-e putem .htaccess-a?
Ne. Ovaj pristup može također blokirati pravi Googlebot i uzrokovati probleme s indeksiranjem. Zahtjevi koji sadrže riječ Googlebot trebaju se prvo provjeriti putem IP-a ili DNS-a, a oni koji se utvrde kao lažni trebaju se blokirati. Najsigurnija metoda je zajedno koristiti allowlist i pravila temeljena na ponašanju.
Kako često trebam ažurirati Googlebot IP liste?
Preporučuje se tjedna provjera za prometne stranice, a mjesečna provjera za manje stranice. Najbolja metoda je automatska generacija liste s Googleovih službenih IP JSON izvora. Ručno napisani stari IP rasponi mogu s vremenom postati neaktualni i dovesti do slučajnog blokiranja pravog Googlebota.
Dobio sam 500 grešku nakon dodavanja .htaccess pravila, što trebam učiniti?
500 greška obično je rezultat greške u sintaksi, nepodržane Apache direktive ili pogrešnog escape karaktera. Vratite posljednje dodane pravilo, provjerite logove grešaka i potvrđujte podršku za Apache 2.4, mod_rewrite i izraze u vašem hosting okruženju. Zbog toga je važno napraviti sigurnosnu kopiju .htaccess-a prije promjena.
Ako koristim CDN ili WAF, trebam li još uvijek koristiti .htaccess pravila?
CDN ili WAF su snažan sloj za filtriranje botova; međutim, .htaccess može pružiti dodatnu zaštitu i zaštitu blizu aplikacije. Najbolji rezultati postižu se kada se na CDN/WAF koriste pravila za limitiranje brzine i provjeru botova, a na serveru se koriste .htaccess ograničenja za osjetljive putanje.