Logfilanalyse for SEO: les serverloggene dine og rett crawl-sløsing

Rask quiz

Passer SEO for deg, og hvordan bør du starte?

Spørsmål 1 av 425%

Søker folk på Google etter det du selger?

Ja, tror jegNei, det er nytt eller svært nisjepregetJeg vet ikke

Hva en serverlogg registrerer, og hvorfor den slår de andre dataene dine

Hver gang noe ber om en fil fra serveren din, skriver serveren én linje i tilgangsloggen sin. De fleste servere bruker et format nær Apaches "combined"-format. En forespørsel fra Googlebot ser slik ut:

66.249.66.1 - - [13/Nov/2026:08:14:22 +0100] "GET /products/red-running-shoes HTTP/1.1" 200 18342 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Les den fra venstre mot høyre: IP-adressen, tidsstemplet, HTTP-metoden og URL-en, statuskoden (her 200), antall byte som ble sendt, referereren og user agent. Hver eneste forespørsel er med, også de som aldri vises som sidevisning i analyseverktøyet ditt: bilder, CSS-filer, omdirigeringer og 404-feil.

De andre datakildene dine ser hver sin del av dette. Rapporten Crawlstatistikk i Search Console er aggregert og dekker bare Googles crawlere. Analyseverktøy registrerer bare besøkende hvis nettlesere kjører JavaScriptet ditt. En nettsidecrawler som Screaming Frog viser det den kan nå ved å følge lenkene dine, og det er ikke det samme som det Google valgte å be om. Bare serverloggen registrerer hva som faktisk skjedde.

Hvorfor logganalyse betyr noe: crawl-budsjett med enkle ord

Crawl-budsjett er settet med URL-er Google kan og vil crawle på nettstedet ditt. Google beskriver det med to faktorer. Den første er kapasitetsgrensen for crawling: hvor mange forbindelser Googles crawlere kan holde åpne mot serveren din uten å overbelaste den. Grensen stiger når nettstedet er friskt og synker når svartidene øker eller svarene inneholder 5xx- eller 429-feil. Den andre er crawl-etterspørselen, som avhenger av nettstedets størrelse, hvor ofte innholdet endres, kvaliteten og hvor populære sidene er.

Google presenterer emnet som en avansert guide for store nettsteder. De grove terskelverdiene er nettsteder med 1 million eller flere unike sider der innholdet endres omtrent én gang i uken, og nettsteder med 10000 eller flere unike sider der innholdet endres hver dag. Nettsteder der mange URL-er står med statusen "Discovered - currently not indexed" faller også innenfor. Mindre nettsteder kan vanligvis stole på et oppdatert sitemap og jevnlige kontroller av rapporten Sideindeksering. Det betyr ikke at loggene er ubrukelige for dem. Når noe er galt med crawlingen, er loggen den raskeste måten å se nøyaktig hvor.

Hvis nettstedet ditt er innenfor det området, er ikke spørsmålet lenger om du skal lese logger, men hvor ofte. En engangsrevisjon viser sløsingen i dag. En månedlig eksport viser om rettelsene dine endret hva Googlebot bruker tiden sin på. For bakgrunn om begrepene dekker ordlisteoppføringen om crawl-budsjett det grunnleggende, og guiden om Discovered, currently not indexed forklarer statusen som vanligvis utløser denne typen gjennomgang.

Metoden, steg for steg

Arbeidsflyten nedenfor fungerer med alle servere og alle verktøy. Seksjonene lenger ned forklarer hvert steg i detalj og gir kommandoene du kan kjøre på en rå loggfil i dag.

Hent loggene fra riktig lag

Be utvikleren din eller hostingleverandøren om de rå tilgangsloggene fra webserveren (Apache, Nginx eller IIS). Sjekk tre ting før du starter: loggformatet, tidssonen og hvor lenge loggene lagres. Avhengig av oppsettet ditt kan gamle logger roteres bort etter noen dager eller uker, så be om eksporten nå i stedet for senere.

Laget betyr mer enn folk tror. Hvis et CDN svarer på en forespørsel fra cachen sin, ser serveren din aldri den. Googlebot kan crawle en URL som aldri dukker opp i origin-loggen din, så en eksport bare fra origin undertelle crawl-aktiviteten på cachet innhold. Eksporter også CDN-loggene, og sammenlign de to kildene for noen URL-er før du stoler på noen av totalene.

Filtrer og tell Googlebot med noen få kommandoer

I en logg i combined-format er statuskoden det 9. feltet og URL-stien det 7. feltet. Disse to kolonnene besvarer de fleste første spørsmål. Denne kommandoen teller Googlebot-forespørsler per statuskode:

grep "Googlebot" access.log | awk '{print $9}' | sort | uniq -c | sort -rn

Denne lister de 20 stiene Googlebot ber om oftest, med søkestrengen fjernet slik at filtervarianter grupperes sammen:

grep "Googlebot" access.log | awk '{print $7}' | cut -d '?' -f1 | sort | uniq -c | sort -rn | head -20

Den første kommandoen leser user agent-teksten, som alle kan forfalske. Behandle resultatet som en kandidatliste til neste seksjon er ferdig. Hvis loggen din bruker et eget format, endres feltnumrene, så sjekk én linje for hånd før du stoler på kolonnene.

Verifiser Googlebot slik Google beskriver det

Googles egen metode for å bekrefte at en besøkende er Googlebot, bruker DNS. Gjør et omvendt DNS-oppslag på IP-adressen fra loggen din, kontroller at vertsnavnet ender på googlebot.com, google.com eller googleusercontent.com, og gjør deretter et framoverrettet oppslag på vertsnavnet og kontroller at det returnerer den opprinnelige IP-adressen. Googles dokumentasjon bruker dette eksempelet, der 66.249.66.1 løses omvendt til crawl-66-249-66-1.googlebot.com:

host 66.249.66.1

Det framoverrettede sjekken er den andre kommandoen, og den må returnere samme IP:

host crawl-66-249-66-1.googlebot.com

Hvis du behandler millioner av linjer, blir DNS-oppslagene trege. Google publiserer også JSON-filer med IP-områdene til crawlerne sine, blant dem common-crawlers.json for Googlebot. Å matche mot disse områdene er raskere, og den offisielle verifiseringsguiden beskriver begge metodene i Googles guide for verifisering av Googlebot.

Grupper, mål og les resultatene

Rå antall per URL er vanskelige å handle på. Grupper derfor URL-ene etter mal først, for en rettelse gjelder vanligvis en mal og ikke én side. Mål deretter fire ting for hver gruppe. Mål hvor mange Googlebot-treff den får sammenlignet med hvor viktig den er for virksomheten din. Mål fordelingen av statuskoder. Mål hvor raskt nye sider får det første treffet etter publisering. Mål om treffene samles på sidene du vil ha rangert.

Les resultatene som et mønster, ikke som ett enkelt tall. Hvis de fleste Googlebot-treffene havner på filter-URL-er og bare noen få på produktsider, lekker crawl-budsjettet, og problemet er sannsynligvis interne lenker eller parameterhåndtering, ikke produktsidene. Neste seksjon viser signalene du skal se etter.

De syv signalene skjult i loggene

Når Googlebot-linjene er verifisert og gruppert, forklarer syv signaler de fleste crawlproblemer. Tabellen gir mønsteret å se etter og den vanlige rettelsen. Hver rettelse er en endring på nettstedet, så bekreft den i neste eksport.

Signal	Hva loggene viser	Hva du gjør
Crawl-sløsing	Googlebot-treff på filtre, sorteringsrekkefølger, intern søk og session-URL-er	Konsolider med canonicals, fjern de interne lenkene til disse URL-ene, og blokker meningsløse varianter i robots.txt der de ikke kan konsolideres
Omdirigeringer	Treff på 301- eller 302-svar, og kjeder med to eller flere hopp	Lenk direkte til den endelige URL-en. Guiden om 301 vs 302 hjelper deg å velge riktig type omdirigering
Feil	Gjentatte 404- eller 410-treff, og topper av 5xx-svar	Gjenopprett eller omdiriger sider som fortsatt betyr noe, og rett serverfeil, fordi 5xx-svar reduserer hvor mye Google crawler
Manglende crawl	Viktige URL-er uten noe Googlebot-treff i vinduet	Sjekk interne lenker, sitemap-oppføringer og robots.txt-regler som kan holde crawlere borte fra dem
Duplikater	Samme innhold truffet under flere URL-er, med skråstrek til slutt, store bokstaver eller parametere	Velg én kanonisk URL, og lenk til den overalt
Tid til første crawl	Tiden mellom publisering og første Googlebot-treff på en ny side	Lenk nye sider fra sider som allerede crawles ofte, og hold sitemapet rent
Svartid	Trege svar på malene Googlebot treffer mest	Gjør disse malene raskere først, siden Google sier at trege svar får den til å crawle mindre

Raden om manglende crawl er den folk hopper over, og den er ofte den dyreste. En side du aldri ser i loggen, kan fortsatt ikke rangere for noe, selv om innholdet er utmerket. Hvis en URL står i sitemapet ditt, men aldri dukker opp i loggene, nås siden sannsynligvis bare via en sti crawlere ikke følger. Guiden om Crawled, currently not indexed dekker den andre siden av situasjonen, når Googlebot besøker, men fortsatt ikke indekserer.

Tre måter å kjøre analysen på, sammenlignet

Du kan kjøre logganalyse med skript, med et skrivebordsprogram eller med en plattform. Hver løsning passer ulike volumer og ulike team. Valget avhenger mindre av nettstedets størrelse enn av hvor ofte du trenger svaret, og hvem som skal lese det.

Kommandolinjen: grep, awk og Python

Prinsipp: du analyserer råfilene med skript og skriver resultatene til en fil eller et regneark. Når du bruker det: engangssjekker, små nettsteder eller en utvikler som vil ha full kontroll. Fordeler: det er gratis, du ser hver linje, og du kan automatisere det med en planlagt jobb. Begrensninger: det tar tid å skrive og vedlikeholde, det går bare så raskt som maskinen din, det har ingen grafer, og du må verifisere robotene selv.

Eksempel: kommandoene i metodeseksjonen, kjørt en gang i måneden på samme eksport, gir deg statuskodefordelingen og de vanligste stiene for Googlebot. Et kort Python-skript kan gjøre det samme og legge til DNS-sjekken, som er tregere men mer nøyaktig.

Skrivebordsverktøy: Screaming Frog Log File Analyser

Prinsipp: du importerer råloggene i et skrivebordsprosjekt, og verktøyet grupperer robotene, sjekker identiteten deres og tegner diagrammene. Når du bruker det: en konsulent eller en intern analytiker som jobber med et nettsted med titusenvis av URL-er. Fordeler: det leser Apache-, IIS- og Nginx-logger i W3C Extended-format, verifiserer søkemotorroboter og flagger store eller trege sider. Begrensninger: gratisversjonen er begrenset, og mengden data du kan laste inn, avhenger av harddisken din.

Les Screaming Frogs side om Log File Analyser før du kjøper. For en fullstendig gjennomgang av crawleren som passer sammen med den, se vår guide til Screaming Frog SEO Spider. Logganalysatoren gjør én jobb som crawleren ikke kan gjøre: den viser hva robotene faktisk ba om i virkeligheten, ikke hva lenkene dine antyder.

Plattform: kontinuerlig loggovervåking

Prinsipp: plattformen mottar loggene dine etter en plan, ofte fra CDN-en eller serveren, og kobler dem til en crawl av nettstedet ditt og til indekseringsdata. Når du bruker det: store netthandelsnettsteder eller bedriftsteam som overvåker crawling hver uke på tvers av flere markeder. Fordeler: den skalerer til svært store logger, beholder historikk, og flere team kan dele dashbord. Begrensninger: den koster mer, tar tid å ta i bruk, og innlåsingen er reell, så sjekk hvordan du kan eksportere dataene dine før du binder deg. Leverandører i denne kategorien inkluderer Oncrawl og Botify, og det er verdt å spørre hver av dem hvordan de verifiserer roboter.

Kriterium	Kommandolinje	Skrivebordsverktøy	Plattform
Kostnad	Gratis	Gratis opptil 1000 loggbegivenheter, £99 per år for full lisens	Abonnement, pris avhengig av volum
Oppsett	Du skriver og vedlikeholder skriptene	Installer, importer, start	Koblinger og onboarding
Volum	Begrenset av maskinen din	Begrenset av harddisk og lisens	Bygget for svært store logger
Botverifisering	Manuelt, med DNS- eller IP-områdesjekker	Innebygd	Spør leverandøren
Best for	Engangssjekker og små nettsteder	Konsulenter og mellomstore nettsteder	Bedrifts- og netthandelsteam med ukentlig overvåking

Googles rapport Crawlstatistikk: nyttig, men ikke nok

Før du eksporterer en eneste logg, åpne rapporten Crawlstatistikk i Search Console. Den viser totale crawl-forespørsler, total nedlastingsstørrelse, gjennomsnittlig svartid, svar gruppert etter type, filtyper, crawl-formål og hvilken Googlebot-type som gjorde hver forespørsel. For en trendsjekk er det den raskeste visningen du har, og veiledningen om Google Search Console forklarer hvor du finner den.

Begrensningene forklarer hvorfor loggene fortsatt betyr noe. Rapporten er bare tilgjengelig for domeneegenskaper og URL-prefiks på rotnivå. Den dekker bare Googles crawlere, så GPTBot, ClaudeBot og de andre robotene mangler. Den grupperer data i stedet for å liste hver URL, så den kan fortelle deg at crawl-forespørslene falt, men ikke hvilke maler som mistet dem. Bruk den til å oppdage at noe har endret seg, og bruk deretter loggene til å finne ut hva.

Googles hjelpeside for Crawlstatistikk beskriver hver gruppering. Når diagrammet og loggeksporten din ikke stemmer overens, stol ikke på noen av dem før du har sjekket tidsvinduet og verifiseringstrinnet. De fleste av disse uoverensstemmelsene skyldes et annet vindu, et CDN som svarer fra cache, eller et botantall som inkluderer uverifiserte forespørsler.

Rett opp crawl-sløsing når du først ser den

Rettelsene følger av signalene. De fleste kommer ned til tre grep: slutt å sende crawlere til sider som ikke betyr noe, send dem rett til den endelige URL-en når en side er flyttet, og gjør sidene som betyr noe raskere å laste.

Fasettert navigasjon. Filtre og sorteringer lager mange URL-er med nesten likt innhold. Konsolider dem med canonicals der du kan, og fjern de interne lenkene til varianter uten søkeverdi. Der en variant ikke kan konsolideres og må holdes utenfor crawlingen, blokker den i robots.txt. Googles veiledning er tydelig her: ikke bruk noindex for dette, for Google må fortsatt be om siden før den kan se taggen. Her er den typen regel du bør teste:

User-agent: Googlebot
Disallow: /*?sort=
Disallow: /*?color=

Hold robots.txt-endringen i proporsjon. Google sier at blokkering av URL-er ikke frigjør crawl-budsjett til de andre sidene dine, med mindre nettstedet allerede treffer kapasitetsgrensen sin. Blokkering er for URL-er uten verdi, ikke en måte å skyve budsjett mot de beste sidene dine. Vår ordlisteoppføring om robots.txt forklarer hvordan filen leses.

Omdirigeringskjeder. Når en side er flyttet to ganger, går crawleren gjennom begge omdirigeringene hver gang. Oppdater de interne lenkene slik at de peker til den endelige URL-en, og behold deretter de gamle omdirigeringene for eksterne lenker. Valget mellom en permanent og en midlertidig omdirigering betyr noe av samme grunn, og guiden om 301 vs 302 dekker det i detalj.

Slettede sider. Returner 404 eller 410 for sider som er fjernet permanent. Google sier at myke 404-er fortsetter å bli crawlet og sløser crawl-budsjett, så en "siden finnes ikke"-melding servert med status 200 er verre enn en ekte 404.

Svartid og caching. Google sier at trege eller mislykkede svar får den til å crawle mindre. Støtt 304-svar (Not Modified), slik at uendrede sider kan serveres fra cache. Se deretter på malene som får flest Googlebot-treff, og gjør disse svarene raskere først.

Feilene som koster mest, og hvordan du unngår dem

De fleste logganalyser som går galt, gjør en av en liten gruppe feil. Hver av feilene nedenfor har et symptom du kan se i dataene, og en rettelse du kan bruke samme uke.

Å stole på user agent-strengen

Hva det er: å telle hver forespørsel som sier "Googlebot" som Googles crawling. Hvordan du oppdager det: Googlebot-treff fra IP-adresser som ikke løses omvendt til Googles vertsnavn, eller et plutselig hopp fra én enkelt adresse. Hvordan du retter det: kjør verifiseringen fra metodeseksjonen før du teller noe, og hold de uverifiserte treffene i en egen gruppe, så du fortsatt ser skrapeaktivitet.

Å bare lese 200-svarene

Hva det er: å fokusere på sider som returnerer 200 og ignorere resten. Hvordan du oppdager det: rapporten din har ingen 3xx-, 4xx- eller 5xx-seksjon, eller statuskodefordelingen diskuteres aldri. Hvordan du retter det: start alltid med statuskodefordelingen. En økning i 404-treff kan avsløre en ødelagt intern lenke, og en økning i 5xx-treff kan avsløre et serverproblem som bremser hele crawlingen.

Å blokkere en side du vil deindeksere

Hva det er: å legge til en robots.txt-regel på en side som også har en noindex-tag. Hvordan du oppdager det: siden blir værende i indeksen, og loggen viser ingen Googlebot-treff, fordi crawleren er forhindret i å be om den. Hvordan du retter det: fjern blokkeringen, slik at Google kan lese noindex-taggen, vent til siden forsvinner fra indeksen, og gjeninnfør deretter blokkeringen hvis du fortsatt trenger den. Guiden om Blocked by robots.txt forklarer Search Console-statusen som dukker opp i dette tilfellet.

Å sammenligne vinduer av ulik lengde

Hva det er: å sammenligne en 3-dagerseksport før en rettelse med en 30-dagerseksport etter. Hvordan du oppdager det: totalene beveger seg mye, men andelen per mal gjør det ikke. Hvordan du retter det: sammenlign samme antall dager, helst på samme tid av året, og sammenlign andeler i stedet for rå totaler når volumet endrer seg.

Å måle treff i stedet for verdi

Hva det er: å feire en økning i Googlebot-treff uten å sjekke om treffene når sider som blir indeksert. Hvordan du oppdager det: treffene samles på URL-er som ikke er indeksert, eller som aldri tjener trafikk. Hvordan du retter det: koble loggruppene dine til indekseringsstatusen fra URL-inspeksjonsverktøyet i Search Console, og tell bare en rettelse som en seier når crawlingen beveger seg mot sider som betyr noe.

Hvor AI-roboter passer inn i de samme loggene

De samme loggene viser hva AI-crawlere gjør på nettstedet ditt, og metoden er den samme: grupper dem, verifiser dem der leverandøren gir en måte å gjøre det på, og les statuskodene. Vår guide om AI-crawler-logger dekker hvilke roboter du bør se etter, og hvordan de skiller seg fra Googlebot. Denne artikkelen dekker Googlebot-metoden i dybden, og AI-seksjonen nedenfor viser hvordan du får begge i samme rapport.

Robottype	Eksempler	Hva du sjekker i loggene	Les mer
Søkecrawler	Googlebot	Treff per mal, statuskodefordeling, tid til første crawl på nye sider	Seksjonene over i denne artikkelen
Treningscrawler	GPTBot, ClaudeBot, CCBot	Om de i det hele tatt ber om innholdet ditt, og om de respekterer robots.txt	Robots.txt for AI-crawlere
Hentecrawler	ChatGPT-User, PerplexityBot	Korte bølger av besøk knyttet til brukernes spørsmål, og hvilke sider bølgene når	AI-crawler-logger

Skillet mellom trening og henting kommer av måten AI-crawlere er dokumentert på. Treningscrawlere samler inn innhold til modeller, og hentecrawlere henter sider når en bruker stiller et spørsmål. Rapporten din bør holde dem adskilt, for en policybeslutning for den ene gjelder ikke automatisk for den andre.

Hvis du vil se Google-trafikk og AI-trafikk side om side mens du gjennomfører disse rettelsene, viser Soranks GEO / SEO-dashbord begge i ett overblikk. Bruk det til å sjekke om endringene du gjør fra loggene flytter trafikk, ikke bare om de endrer antall crawlinger.