Sådan blokerer du falske Googlebot-besøgende med .htaccess – Sikre din hjemmeside mod robotangreb

At blokere falske Googlebot-besøgende med .htaccess handler om at identificere og stoppe skadelige bots, der udgiver sig for Googlebot, uden at påvirke ægte Google-crawlers. Det gøres ved at analysere user-agent, IP-validering og adgangslogs, og derefter returnere 403 Forbidden kun til falske bots. Den sikreste metode er ikke kun at stole på User-Agent, men også at tjekke Googles officielle IP-ranges eller reverse DNS, først logge mistænkelige adgangsforsøg og så sætte præcise .htaccess-regler.

Mange angribende bots udgiver sig for Googlebot, Google-InspectionTool, AdsBot-Google eller Googlebot-Image for at omgå firewall og simple botfiltre. De fleste website-ejere er bange for at blokere Google, og det udnytter angribere til at scrape indhold, skabe falsk trafik, spamme formularer, forsøge login eller forstyrre SEO-data. Særligt på shared hosting, WordPress, WooCommerce, nyhedssites og hyppigt opdaterede blogs kan denne trafik hurtigt presse CPU, RAM og I/O-limiter. I denne guide gennemgår vi, hvordan du analyserer falske Googlebot-adfærd, skriver sikre .htaccess-regler og undgår at blokere den rigtige Googlebot. Har du brug for en robust og skalerbar webhosting, så inkluder Hostragons webhostingløsninger og installation af SSL certifikat i din plan.

Hvad er en falsk Googlebot – og hvorfor er det farligt?

En falsk Googlebot er en automatisk crawler, der sætter User-Agent til Googlebot i HTTP-requesten, men kommer fra en IP, der ikke tilhører Google. User-Agent er bare en tekststreng, og alle kan skrive "Googlebot" i deres requests. Derfor er det ikke sikkert kun at stole på User-Agent-feltet.

Ægte Googlebot besøger din hjemmeside for at indeksere sider, opdatere indhold og samle kvalitets-signaler til søgeresultater. Falske Googlebots har typisk andre motiver – fx at scrape produktpriser, kopiere indhold, prøve admin-URLs, belaste søgefunktioner eller scanne efter svage plugins. Nogle angribere sender dusinvis af requests pr. sekund og kan bremse selv små sites.

Typiske tegn på falske bots er:

• Hundredvis af 404, 403 eller 500-svar på kort tid.
• Scanning af følsomme stier som wp-login.php, xmlrpc.php, admin, phpmyadmin, backup.zip.
• User-Agent med Googlebot, men IP-adressen matcher ikke Googles ASN eller officielle ranges.
• Ignorerer robots.txt og crawler filter-, søge-, kurv- eller konto-sider.
• Sender requests til samme URL med ekstremt høj frekvens, modsat ægte Googlebot.

Hvorfor er User-Agent ikke nok?

At en bot skriver "Googlebot" i HTTP-headeren beviser ikke, at den er fra Google. Med et enkelt curl-kommando kan man nemt efterligne User-Agent. Derfor er det en fejl både at blokere alle User-Agent "Googlebot" eller tillade dem uden yderligere kontrol. Første kan stoppe ægte Google-crawl, og det sidste giver angribere fri adgang.

Den moderne SEO- og sikkerhedsstrategi bør have tre lag: kontrollér den påståede identitet, valider IP eller DNS, og overvåg unormal adfærd via logs. Så beskytter du både Google-synlighed og serverressourcer mod unødvendige bots.

Sådan valideres ægte Googlebot

Google anbefaler to primære metoder: reverse DNS og officielle IP-ranges. Med reverse DNS skal IP-adressen resolve til et domæne, der ender på googlebot.com eller google.com, og domænenavnet skal derefter resolve tilbage til samme IP. Det sikrer, at man ikke kun sætter et falsk PTR-record.

Den anden metode er at bruge Googles offentliggjorte IP-ranges. Google udgiver forskellige JSON-lister for Googlebot, special-crawlers og bruger-initierede fetchers. Listen kan ændre sig over tid, så det er vigtigt ikke bare at stole på gamle, håndskrevne IP-lister. Har du VPS eller server, kan du automatisere opdatering af ranges til firewall eller Apache include. På shared hosting bør du bruge logs, .htaccess og eventuelle sikkerhedsmoduler til at styre adgang.

.htaccess og blokering af falske Googlebot: Grundprincip

.htaccess er en fil, der styrer regler for adgang, URL-redirects, cache, komprimering og basale sikkerhedsbegrænsninger i Apache-webserveren. Til Googlebot-blokering vurderer den indgående requests og returnerer 403 Forbidden til mistænkelige bots.

Bemærk dog: Standard .htaccess er ikke optimal til real-time reverse DNS checks, da HostnameLookups i Apache ofte er slukket for performance. Den mest praktiske metode er at sammenligne User-Agent "Googlebot" requests med en IP-allowlist, eller at filtrere kritiske stier hårdere. Avanceret validering kræver WAF, server-firewall, CDN eller automatisering baseret på logs. Se hvad er CDN og dens indvirkning på webstedets ydeevne for at planlægge dette lag.

Step-for-step: Sådan identificerer og blokerer du falske Googlebot

1. Gennemgå adgangslogs

Før du skriver en blokering, bør du analysere mindst 24-72 timers access logs. Ved højt trafik kan én times log give nok signal. Kig på IP, dato, URL, statuskode, bytes, referer og User-Agent. Fx hvis samme IP laver 800 requests på 10 min., de fleste giver 404, og User-Agent er Googlebot – så er det mistænkeligt.

Du kan hente logs fra cPanel eller lignende. Med SSH kan du filtrere User-Agent "Googlebot" requests med grep, awk og sort for at se IP-aktivitet. Målet er at se adfærden for IP'er med Googlebot User-Agent – ikke nødvendigvis at blokere alle sådanne requests.

2. Valider IP’er med Googlebot User-Agent

Efter du har fundet mistænkelige IP’er, så tjek reverse og forward DNS. Hvis IP’en har PTR-record som crawl-66-249-66-1.googlebot.com, har den bestået første trin. Når du resolver domænet tilbage, skal det give samme IP. Hvis ikke, eller hvis PTR mangler, er det ikke ægte Googlebot.

Dette er især vigtigt for større sites med SEO-fokus. At blokere ægte Googlebot kan betyde langsommere indeksering, forældet index, crawl errors i Search Console og tab af organisk trafik. Derfor må blokering ikke kun baseres på User-Agent, men på en validerings-proces.

3. Log først, bloker bagefter

I sikker drift anbefales en kort observationsfase før du blokerer. Først notér mistænkelige IP’er og User-Agents. Derefter begræns kun klart skadelige stier. Til sidst blokerer du Googlebot User-Agent requests, der ikke matcher Googles IP-ranges.

Dette er særlig vigtigt for webshops, hvor fejl kan påvirke checkout, kurv, produktvarianter eller lagerintegration. Har du meget trafik, så test først i staging. Overførsel af WordPress site og oprettelse af testmiljø hjælper med at gøre sikkerhedsændringer mindre risikofyldte.

Sikre .htaccess-regler: Eksempler

Eksemplerne her bør testes i forhold til din Apache-version, aktive moduler og hosting-rettigheder før de tages i brug. Apache 2.4 og mod_rewrite er udbredt – men på shared hosting kan visse direktiver være begrænsede. Tag altid backup af .htaccess før ændringer; en enkelt fejl kan give 500 Internal Server Error.

Simpel adfærdsfiltrering: Stop falske bots på følsomme stier

Her blokeres bots, der udgiver sig for Googlebot, fra at tilgå admin- eller angrebsrelevante filer. Ægte Googlebot har ikke brug for at crawle wp-login.php, phpmyadmin eller backup.zip, så risikoen for false positives er lav.

• 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]

Reglen giver 403 til enhver request med Googlebot User-Agent, der forsøger en følsom sti. Det påvirker ikke SEO-crawl, da disse sider alligevel ikke ønskes indekseret. Bruger du WordPress, så tjek dog behovet for XML-RPC, sikkerhedsplugins og eksterne publishing-tjenester.

IP Allowlist: Sammenlign Googlebot User-Agent med officielle ranges

En stærkere metode er kun at tillade Googlebot User-Agent requests fra kendte Google IP-ranges. Eksemplet her er illustrativt; brug altid Googles opdaterede JSON-lister til at generere ranges. Gamle eller ufuldstændige lister kan blokere ægte 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]

De viste ranges er eksempler. I produktion bør ranges genereres automatisk fra Googles aktuelle IP-lister. Tjek om din hosting understøtter Apache expressions/-ipmatch. Alternativt kan IP-filtrering sættes op på CDN/WAF-niveau.

Begrænsning af mistænkelige request-rater

.htaccess er ikke optimal til avanceret rate limiting, men kan bruges til at stoppe enkelte dårlige adfærdsmønstre tidligt. Til rigtig rate limiting bør du bruge mod_evasive, mod_security, CDN rate limiting eller applikationsbeskyttelse. Bots, der sender over 5-10 requests pr. sekund, kan overbelaste databasen selv på små sites. I WordPress kan bots misbruge søge-, filter- og tag-sider. Kombiner robots.txt, canonical, noindex og sikkerhedsregler for at beskytte disse områder. Guide til WordPress hastighedsoptimering supplerer performance-siden.

Sammenligningstabel: Hvilken metode skal du vælge hvornår?

Checkliste: Sådan undgår du at blokere ægte Googlebot

Største risiko er at blokere den ægte Googlebot – så brug denne tjekliste hver gang du ændrer regler:

• Tjek Search Console Crawl-rapporten for pludselige fald eller stigning i 403.
• Gennemgå serverlogs for requests fra ægte Google IP’er – får de 200, 301 eller korrekt status?
• Sørg for at robots.txt ikke blokere Googlebot fra kritiske områder uden for bevidst lukning.
• Efter .htaccess-ændringer: test sitemap, forsiden, kategorier og vigtige produktsider.
• Dokumentér kilde og opdateringsdato for din IP-liste.

Fra teknisk SEO-synspunkt er 403 et stærkt signal. Hvis ægte Googlebot gentagne gange får 403 på vigtige sider, vil crawl-raten på disse URLs falde. Brug derfor 403 kun til bots du med sikkerhed ikke ønsker. Ved midlertidig vedligeholdelse eller overload kan 429 Too Many Requests være mere passende, men 403 er mest brugt til simpel bot-blokering med .htaccess.

Ekstra sikkerhedsforanstaltninger for WordPress og webshops

På WordPress ses falske Googlebot-trafik typisk på xmlrpc.php, wp-login.php, REST API-endpoints, søge-URLs og forfatter-arkiver. På webshops angribes filter-parametre, lager-queries, kurv-endpoints og produktvarianter. Du bør sikre generel bot-hygiejne, ikke kun Googlebot-taktik.

• Brug two-factor login og begræns forsøg på login-sider.
• Deaktiver eller begræns XML-RPC-funktioner du ikke bruger.
• Planlæg noindex, canonical og robots.txt strategi for søge-/filter-URLs.
• Brug opdateret PHP-version, tema og plugins fra troværdige kilder.
• Hold dit SSL-certifikat aktivt – HTTPS er et must for sikre sessioner og formularer. Hostragons SSL certifikater
• Overvåg dine DNS-records, især for domæne og mail – svage records øger risikoen. Domæneforespørgsel og DNS-styring

Performance: Hvordan påvirker bot-trafik dine serverressourcer?

Bot-trafik er ikke kun et sikkerhedsproblem – det er også et hosting-performance problem. At hente et statisk billede koster lidt, men en WordPress-søgning eller WooCommerce-filter kræver database-queries. Hvis en falsk Googlebot sender 300 dynamiske requests pr. minut, fyldes PHP-workers, databaseforbindelser stiger, og ægte brugere får langsommere loadtider.

Eksempel: Hvis en produktside bruger 250 ms PHP-tid pr. request, giver 600 bot-requests pr. minut 150 sekunders processing. Kører det parallelt, rammer du CPU-limit og TTFB stiger. Dårlige server-responstider påvirker Core Web Vitals, brugeroplevelse og konvertering. Derfor er bot-blokering relevant for både sikkerhed, SEO og performance.

Test: Virker dine .htaccess-regler?

Efter du har tilføjet regler, bør du lave tre tests: 1) Test forsiden, kategorier og login-flow som almindelig bruger. 2) Brug Google Search Console’s URL Inspection på en vigtig URL. 3) Tjek logs for om mistænkelige IP’er med Googlebot User-Agent får 403, og ægte Googlebot-IP’er ikke blokeres.

Hvis du tester med kommando-linje og sætter User-Agent til Googlebot, viser det kun om User-Agent-reglen trigges – ikke om du faktisk ligner Googlebot. Den rigtige test er IP- og DNS-validering. Hvis du får 500-fejl, har du formodentlig syntax-fejl i .htaccess. Tilbagefør de seneste linjer, tjek error logs og bekræft din Apache-version og moduler.

Vedligeholdelse: Hvor ofte skal regler opdateres?

Bot-blokering er ikke en engangsopgave. Google IP-ranges kan ændre sig, angriberes User-Agent-mønstre varierer, og din URL-struktur kan udvikle sig. På små sites kan månedlig log-check være nok, mens nyheds-, e-handels- eller kampagnesites bør tjekke ugentligt. På store sites er automatiske alarms bedst – fx hvis requests fra Googlebot User-Agent men uden valideret IP overstiger en grænse, sendes notifikation.

Versionér din .htaccess. Selv en simpel backup med dato, fx htaccess-2026-02-15.bak, gør rollback nemmere. Hvis flere administrerer sitet, bør tilføjede regler dokumenteres med korte noter for at undgå driftsstop.

Konklusion

At identificere og blokere falske Googlebot-besøgende med .htaccess beskytter både SEO-synlighed og serverressourcer mod skadelige crawlers. Grundreglen er klar: User-Agent alene er ikke bevis – IP, DNS, adfærd og loganalyse skal kombineres. Observer først, begræns lavrisikostier, og brug til slut opdaterede Google IP-lister til validering og blokering.

Hvis du hoster på Hostragons, bør du kombinere sikker hosting, opdateret SSL, korrekt DNS og regelmæssige backups for et stabilt webmiljø. Start evt. med at analysere dit aktuelle bot-trafik, og vælg Hostragons hostingpakker hvis du har brug for en stærkere og mere sikker løsning.

FAQ: Ofte stillede spørgsmål

Påvirker falske Googlebot min Google-rangering?

Ja, indirekte. Falske Googlebots kan bruge serverressourcer, så ægte brugere og Googlebot får langsommere svar. De kan også forurene log- og analyse-data og give forkerte SEO-beslutninger. Korrekt blokering beskytter crawl-budget og performance.

Skal jeg blokere alle Googlebot User-Agent med .htaccess?

Nej. Det kan blokere ægte Googlebot og give indeksproblemer. Requests med Googlebot User-Agent bør først valideres via IP eller DNS; kun de falske bør blokeres. Den bedste metode er at kombinere allowlist og adfærdsregler.

Hvor ofte skal jeg opdatere Googlebot IP-lister?

På sites med høj trafik anbefales ugentlig tjek, på mindre sites månedligt. Bedst er at generere lister automatisk fra Googles officielle IP JSON-kilder. Gamle, håndskrevne ranges risikerer at blokere ægte Googlebot.

Jeg får 500-fejl efter .htaccess-ændringer – hvad gør jeg?

500-fejl skyldes ofte syntaxfejl, ikke-understøttede Apache-direktiver eller fejl i escape-tegn. Tilbagefør seneste ændringer, tjek error logs og bekræft Apache 2.4, mod_rewrite og expressions-support. Tag altid backup før ændring.

Behøver jeg .htaccess-regler hvis jeg bruger CDN eller WAF?

En CDN eller WAF er et stærkt lag til bot-filtrering, men .htaccess kan stadig give backup og nær applikationsbeskyttelse. Bedste resultat får du ved at kombinere rate limiting og botvalidering på CDN/WAF og adfærdsbaserede regler på serverniveau.