Kort fortalt
Gary Illyes fra Google sagde i et interview, som Search Engine Roundtable omtalte 30. oktober 2026, at AI har gjort det værre med scrapere, der udgiver sig for at være Googlebot, fordi virksomheder jagter træningsdata. Bot-leverandøren Centinel Analytica målte på nyheds- og mediesites fra slutningen af juni til 21. september 2026, at ca. 1 ud af 7 forespørgsler, der kaldte sig Googlebot, ikke bestod verifikation på det typiske site, og 88 % af de falske kom fra datacentre. For GPTBot var tallet 84 %. Tallene kommer fra en leverandør og dækker kun mediesites. Google udgiver seks IP-lister i JSON, og de er den skalerbare måde at verificere på.
En falsk Googlebot er kun et problem, hvis dit system stoler på navnet, og det gør de fleste steder, hvor nogen engang har skrevet en undtagelse for "Googlebot": i firewall-regler, rate limits, betalingsmure, prerendering og loganalyser. Ret det ét sted ved kanten af systemet, og verificér mod Googles egne IP-lister, ikke mod user-agent-strengen.
Hvad Google sagde, og hvad der er målt
I et interview på Odys Podcast, som Search Engine Roundtable gengav 30. oktober, pegede Gary Illyes på AI som årsagen til, at flere scrapere udgiver sig for at være Googlebot: Virksomheder leder efter data til at træne deres egne modeller, og en forfalsket user-agent åbner døre, som ellers er lukkede. Hans råd var det klassiske: Verificér med omvendt DNS og IP-adresser i stedet for at stole på den streng, klienten selv sender.
Illyes gav ingen tal. Det nyeste offentlige datasæt jeg har fundet, er fra Centinel Analytica, som sælger bot-beskyttelse. De har kørt hver forespørgsel, der påstod at være en kendt crawler, gennem operatørens egen dokumenterede verifikation på nyheds- og mediesites fra slutningen af juni til 21. september 2026.
Forskellen mellem de to søjler er det vigtigste i datasættet. Store sites med meget ægte crawl trækker de samlede andele ned, så medianen er tættest på det, et mindre site ser. For Googlebot fejlede ca. 1 ud af 7 påstande på det typiske site. 88 % af de falske Googlebot-forespørgsler kom fra datacenter-adresser, og 94 % brugte den aktuelle, ægte Googlebot-version i strengen. Med andre ord: Strengen ser rigtig ud. Det er adressen, der afslører den.
Forbeholdene er Centinels egne og værd at tage alvorligt: Det er leverandørdata, de dækker kun mediesites, og der er ikke opgivet et samlet antal forespørgsler. Til gengæld har de krydstjekket mod Googles, Bings, OpenAIs og Perplexitys egne IP-lister i en uge i september, hvor 99,99 % af de verificerede forespørgsler lå inden for de udgivne intervaller.
Hvor din software stoler på navnet
En falsk Googlebot, der henter offentlige sider, koster dig båndbredde. Den bliver først et problem, når den får noget, en almindelig besøgende ikke får. Det sker de steder, hvor nogen engang har skrevet en undtagelse for Google. Dem finder jeg typisk fem steder:
- Firewall og CDN. En regel, der lader alt med "Googlebot" i strengen passere udenom bot-filteret eller geoblokeringen.
- Rate limiting. En undtagelse i API eller applikation, så Google kan crawle hurtigt. Den gælder også for den, der skraber hele produktkataloget.
- Betalingsmur og login. Indhold, der vises fuldt til Googlebot for at blive indekseret. Det er præcis det indhold, en træningsscraper vil have.
- Prerendering. Tjenester, der kun renderer for kendte bots, og som dermed laver fuld HTML af en JavaScript-app gratis for scraperen.
- Loganalyse. Rapporter, der tæller "Googlebot" ud fra strengen og derfor overvurderer crawl-aktiviteten og peger på forkerte sider.
Robots.txt hjælper ikke her. Filen er en høflig anmodning, som kun de crawlere, der vil følge den, læser. En scraper, der lyver om sit navn, har allerede valgt ikke at følge reglerne, og den har ingen grund til at respektere en linje, der er skrevet til en anden. Beskyttelsen skal ligge i det lag, der faktisk afgør, hvem der får et svar.
Strukturen i en verifikation, der holder
Googles dokumentation om verifikation beskriver to metoder: omvendt DNS efterfulgt af et fremadrettet opslag, som er nok til stikprøver, og match mod udgivne IP-lister til større mængder. Listerne er delt i seks filer, blandt andet almindelige crawlere som Googlebot, specialcrawlere som AdsBot og brugerudløste hentere, som ifølge Google ikke følger robots.txt, fordi en bruger har bedt om hentningen. Den rækkefølge, jeg selv bruger:
- Find undtagelserne først. Søg i firewall-regler, CDN-konfiguration, middleware og prerender-opsætning efter crawler-navne. Hver forekomst er et sted, hvor strengen giver adgang.
- Flyt beslutningen til ét lag. Verifikationen hører hjemme ved kanten, så applikationen kun modtager et signal om "verificeret Google" eller ikke. Fem steder med hver sin regel bliver aldrig ens.
- Brug IP-listerne, og cache dem. Hent JSON-filerne med fast interval, og match mod dem. DNS-opslag pr. forespørgsel er langsomt og afhænger af en ekstern tjeneste midt i requesten.
- Skeln mellem kategorierne. En brugerudløst henter er ikke Googlebot og skal ikke have Googlebots undtagelser. Behandl hver fil som sin egen gruppe.
- Afvis ikke blindt. En falsk påstand kan blokeres eller behandles som en almindelig besøgende. Det sidste er sikrest, så en fejl i din liste ikke lukker den ægte Googlebot ude.
- Sammenlign med Search Console. Rapporten over crawl-statistik bygger på Googles egne data. Er der langt flere "Googlebot"-hits i dine logs end i rapporten, tæller du falske med.
Undtagelsen er sårbarheden
De fleste undtagelser for Googlebot er skrevet for at hjælpe med SEO, og de fleste af dem blev aldrig fjernet igen. Med AI-scrapere, der har en klar økonomisk grund til at udgive sig for at være Google, er hver af dem en dør med navneskilt i stedet for lås. Gennemgå dem, saml dem i ét lag, og lad Googles egne IP-lister afgøre, hvem der kommer ind.