Googlebot och loggfiler: där SEO möter cybersäkerhet

SEO och cybersäkerhet låter som två olika yrken, men för en webbserver går de hand i hand. Båda börjar i samma loggfil. SEO letar efter den trafik du vill ha mer av, säkerhet efter den du vill ha mindre av. Och ofta handlar det om samma rader.

Vad är en loggfil? En fil, två frågor

En loggfil är serverns dagbok. Varje gång någon hämtar en sida skriver webbservern en rad i sin accesslogg: vem som frågade (IP-adress), när, vilken adress, vilket svar servern gav och vad besökaren säger att den är (user agent). Två rader kan se ut så här:

66.249.66.1   "GET /tjanster/ HTTP/1.1"  200  "Mozilla/5.0 (compatible; Googlebot/2.1; …)"
203.0.113.45  "GET /.env HTTP/1.1"       404  "Mozilla/5.0 (compatible; Googlebot/2.1; …)"

Det sista fältet är besökarens user agent: en textsträng där webbläsaren eller roboten talar om vad den är, till exempel Chrome på en Mac eller Googlebot, Googles crawler som hämtar sidorna till sökresultatet.

Båda raderna säger att de är Googlebot. Den första är det: adressen finns i Googles egen lista och den hämtar en riktig sida. Den andra letar efter en fil med lösenord och kommer från en adress som inte har med Google att göra. För SEO är den första raden intressant och den andra brus. För säkerheten är det tvärtom.

Vad SEO letar efter i loggen

Search Console visar vad du syns på i Google, men inte vilka sidor Google faktiskt besöker. Det står bara i loggen:

• Hur ofta Googlebot kommer, och om takten ökar eller minskar efter en ändring.
• Sidor Google aldrig besöker. En viktig sida som inte hämtas på veckor saknar oftast interna länkar.
• Bortkastade besök på felsidor, kedjor av omdirigeringar och adresser med parametrar som ger samma innehåll.
• Långsamma svar. Svarar servern långsamt minskar Google själv hur mycket den hämtar.

Vad säkerhet letar efter i samma logg

• Prober efter hemliga filer som /.env, /.git/config och molnnycklar. De ger 404 på en välskött sajt, men visar att någon letar.
• Inloggnings- och installationssidor. På en av våra egna sajter frågade en enda adress efter WordPress installationssida var fjortonde minut hela dagen, 142 gånger, trots att sajten inte kör WordPress.
• Skrapare som kopierar hela sajten från serverhallar, ofta utklädda till vanliga webbläsare.
• Falska sökmotorer. Robotar som utger sig för att vara Googlebot för att slippa spärrar.

Falsk Googlebot: kontrollera IP-adressen

En user agent är bara text som besökaren själv skriver, och vem som helst kan skriva "Googlebot". När vi gick igenom en av våra sajters logg var 24 av 43 rader som kallade sig Googlebot i själva verket sårbarhetsskannrar som letade efter /.env och konfigurationsfiler. Över hälften.

Det ställer till det för båda sidorna. För SEO blir statistiken fel: du tror att Google besöker sidor den aldrig har sett. För säkerheten blir det en lucka: en spärr som släpper igenom allt som heter Googlebot släpper också igenom angriparna.

Lösningen är densamma för båda: avgör robotar på IP-adress, aldrig på user agent. Google publicerar Googlebots IP-adresser som öppna listor, och Bing gör detsamma. En rad som säger Googlebot men kommer från en annan adress är inte Google, oavsett vad den påstår.

Så här såg det ut på en av våra egna sajter under en vecka i oktober 2026, där brandväggen kontrollerar just detta:

Trafik som kallade sig Googlebot	Anrop	Från Googles adresser
Släpptes igenom	cirka 39 600	ja
Stoppades av brandväggen	248 (från 11 adresser)	ingen av dem

Inget riktigt Google-anrop stoppades, och inga falska kom fram.

När säkerheten skadar SEO

En brandvägg som är för ivrig kan stänga ute Google. Det vanligaste misstaget är att spärra eller utmana trafik från vissa länder utan undantag. Google hämtar de flesta sidor från USA, så en spärr mot "allt utanför Sverige" stoppar också Googlebot, och sidorna försvinner sakta ur sökresultatet utan att något felmeddelande syns.

Därför ska varje regel som spärrar på land eller user agent ha ett undantag för verifierade sökmotorer. Och efter varje ändring i brandväggen ska någon titta i Search Console, under Inställningar och Genomsökningsstatistik, att Google fortfarande får svar.

När SEO behöver säkerheten

Det fungerar åt andra hållet också. Robotar som hamrar på servern gör den långsammare, och en långsam server får färre besök av Google. En sajt där bottrafiken är tio gånger större än den mänskliga, vilket inte är ovanligt, lägger serverns kraft på fel besökare. Att stoppa skräptrafiken i dörren är alltså också teknisk SEO.

Två fällor som lurar båda

Loggen på servern visar inte allt. Ligger sajten bakom ett CDN som Cloudflare serveras de flesta sidor från CDN:ets cache och når aldrig servern. På en av våra sajter såg serverloggen bara 4,8 procent av Googlebots besök. Vill du veta hur Google crawlar, eller vad som attackerar, ska du läsa CDN:ets statistik, inte bara serverns logg.

En brandvägg framför servern hjälper inte om servern går att nå direkt. Känner någon till serverns egen IP-adress kan den gå runt Cloudflare helt. Vi upptäckte själva att våra servrar svarade på sådana anrop, vilket gjorde alla brandväggsregler verkningslösa för den som visste hur. Servern ska bara ta emot trafik från Cloudflare, och det går att kontrollera utifrån.

Så kommer du igång

1. Hämta en veckas accesslogg från ditt webbhotell, eller trafikstatistiken från Cloudflare.
2. Plocka ut raderna som säger att de är Googlebot eller Bingbot och jämför adresserna med sökmotorernas egna listor.
3. Gör två listor: sidor som Google besöker och får fel på (SEO), och adresser som letar efter filer som inte ska finnas (säkerhet).
4. Rätta felsidorna och de interna länkarna. Stoppa proberna i brandväggen, med undantag för verifierade sökmotorer.
5. Kontrollera efter en vecka att Google fortfarande kommer fram, och att proberna inte gör det.

Loggar innehåller besökarnas IP-adresser, som är personuppgifter. Den som analyserar dem åt dig ska ha ett biträdesavtal och spara så lite som möjligt.