Logfilanalyse til SEO: læs dine serverlogs og ret crawl-spild

Hurtig quiz

Passer SEO til dig, og hvordan skal du starte?

Spørgsmål 1 af 425%

Søger folk på Google efter det, du sælger?

Ja, det tror jegNej, det er nyt eller meget nicheprægetJeg ved det ikke

Hvad en serverlog registrerer, og hvorfor den slår dine øvrige data

Hver gang noget anmoder om en fil fra din server, skriver serveren én linje i sin adgangslog. De fleste servere bruger et format tæt på Apaches "combined"-format. En anmodning fra Googlebot ser sådan ud:

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)"

Læs den fra venstre mod højre: IP-adressen, tidsstemplet, HTTP-metoden og URL'en, statuskoden (her 200), antallet af bytes der blev sendt, referreren og user agent. Hver eneste anmodning er med, også dem der aldrig vises som sidevisning i dit analyseværktøj: billeder, CSS-filer, omdirigeringer og 404-fejl.

Dine andre datakilder ser hver en del af dette. Rapporten Crawlstatistik i Search Console er aggregeret og dækker kun Googles crawlere. Analyseværktøjer registrerer kun besøgende, hvis browsere kører dit JavaScript. En site-crawler som Screaming Frog viser det, den kan nå ved at følge dine links, og det er ikke det samme som det, Google valgte at anmode om. Kun serverloggen registrerer, hvad der faktisk skete.

Hvorfor logfilanalyse betyder noget: crawl budget i almindelige termer

Crawl budget er mængden af URL'er, Google kan og vil crawle på dit site. Google beskriver det med to faktorer. Den første er crawl-kapacitetsgrænsen: hvor mange forbindelser Googles crawlere kan holde åbne til din server uden at overbelaste den. Grænsen stiger, når sitet er sundt, og falder, når svartiderne stiger, eller når der kommer 5xx- eller 429-fejl. Den anden er crawl-efterspørgslen, som afhænger af sitets størrelse, hvor ofte indholdet ændres, dets kvalitet og hvor populære siderne er.

Google præsenterer emnet som en avanceret guide til store sites. Deres grove grænser er sites med 1 million eller flere unikke sider, hvor indholdet ændres cirka en gang om ugen, og sites med 10000 eller flere unikke sider, hvor indholdet ændres hver dag. Sites hvor mange URL'er står i status "Discovered - currently not indexed" falder også ind under emnet. Mindre sites kan normalt klare sig med et opdateret sitemap og jævnlige kontroller af rapporten Sideindeksering. Det betyder ikke, at logfiler er ubrugelige for dem. Når noget er galt med crawlingen, er loggen den hurtigste måde at se præcis, hvor.

Hvis dit site ligger i det interval, er spørgsmålet ikke længere, om du skal læse logfiler, men hvor ofte. En engangsrevision viser spildet i dag. En månedlig eksport viser, om dine rettelser ændrede, hvad Googlebot bruger sin tid på. For baggrund om begreberne dækker ordlistepunktet om crawl budget det grundlæggende, og guiden om Discovered, currently not indexed forklarer den status, der typisk udløser denne type gennemgang.

Metoden, trin for trin

Arbejdsgangen nedenfor virker med enhver server og ethvert værktøj. De senere afsnit forklarer hvert trin i detaljer og giver kommandoerne, du kan køre på en rå logfil i dag.

Hent logfilerne fra det rigtige lag

Bed din udvikler eller din hostingudbyder om de rå adgangslogs fra webserveren (Apache, Nginx eller IIS). Tjek tre ting, før du starter: logformatet, tidszonen og opbevaringsperioden. Afhængigt af din opsætning kan gamle logfiler blive roteret væk efter nogle dage eller uger, så bed om eksporten nu i stedet for senere.

Laget betyder mere, end folk forventer. Hvis et CDN besvarer en anmodning fra sin cache, ser din origin-server aldrig den. Googlebot kan crawle en URL, der aldrig dukker op i din origin-log, så en eksport kun fra origin undertæller crawl-aktiviteten på cachet indhold. Eksportér også CDN-logfilerne, og sammenlign de to kilder for et par URL'er, før du stoler på nogen af totalerne.

Filtrér og tæl Googlebot med få kommandoer

I en logfil i combined-format er statuskoden det 9. felt, og URL-stien er det 7. felt. Disse to kolonner besvarer de fleste første spørgsmål. Denne kommando tæller Googlebot-anmodninger pr. statuskode:

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

Denne lister de 20 stier, Googlebot anmoder om oftest, med query-strengen fjernet, så filtervarianter grupperes sammen:

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

Den første kommando læser user agent-teksten, som alle kan forfalske. Behandl outputtet som en kandidatliste, indtil næste afsnit er færdigt. Hvis din log bruger et eget format, ændrer feltnumrene sig, så tjek én linje med øjnene, før du stoler på kolonnerne.

Verificér Googlebot på den måde, Google beskriver

Googles egen metode til at bekræfte, at en besøgende er Googlebot, bruger DNS. Lav et omvendt DNS-opslag på IP-adressen fra din log, kontrollér at værtsnavnet ender på googlebot.com, google.com eller googleusercontent.com, og lav derefter et fremadrettet opslag på værtsnavnet og kontrollér, at det returnerer den oprindelige IP. Googles dokumentation bruger dette eksempel, hvor 66.249.66.1 løser omvendt til crawl-66-249-66-1.googlebot.com:

host 66.249.66.1

Det fremadrettede tjek er den anden kommando, og den skal returnere samme IP:

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

Hvis du behandler millioner af linjer, bliver DNS-opslagene langsomme. Google udgiver også JSON-filer med deres crawler-IP-intervaller, herunder common-crawlers.json for Googlebot. At matche mod disse intervaller er hurtigere, og den officielle verifikationsguide beskriver begge metoder i Googles guide til verifikation af Googlebot.

Gruppér, mål og læs resultaterne

Rå tal pr. URL er svære at handle på. Gruppér derfor først URL'erne efter skabelon, for en rettelse gælder typisk en skabelon og ikke en enkelt side. Mål derefter fire ting for hver gruppe. Mål hvor mange Googlebot-hits den får sammenlignet med dens betydning for din forretning. Mål fordelingen af statuskoder. Mål hvor hurtigt nye sider får deres første hit efter publicering. Mål om hits koncentreres på de sider, du vil have rangeret.

Læs resultaterne som et mønster, ikke som et enkelt tal. Hvis de fleste Googlebot-hits lander på filter-URL'er, og kun få på produktsider, lækker crawl budget, og problemet er sandsynligvis interne links eller parameterhåndtering, ikke produktsiderne. Næste afsnit viser de signaler, du skal kigge efter.

De syv signaler gemt i logfilerne

Når Googlebot-linjerne er verificeret og grupperet, forklarer syv signaler de fleste crawl-problemer. Tabellen angiver mønsteret at lede efter og den typiske rettelse. Hver rettelse er en ændring på sitet, så bekræft den i næste eksport.

Signal	Hvad logfilerne viser	Hvad du gør
Crawl-spild	Googlebot-hits på filtre, sorteringer, intern søgning og session-URL'er	Konsolidér med canonicals, fjern de interne links til disse URL'er, og bloker meningsløse varianter i robots.txt, hvor de ikke kan konsolideres
Omdirigeringer	Hits på 301- eller 302-svar og kæder med to eller flere hop	Link direkte til den endelige URL. Guiden om 301 vs 302 hjælper dig med at vælge den rigtige omdirigeringstype
Fejl	Gentagne 404- eller 410-hits og pigge af 5xx-svar	Gendan eller omdirigér sider, der stadig betyder noget, og ret serverfejl, da 5xx-svar reducerer, hvor meget Google crawler
Manglende crawls	Vigtige URL'er uden nogen Googlebot-hit i perioden	Tjek interne links, sitemap-poster og robots.txt-regler, der måske holder crawlere væk fra dem
Dubletter	Samme indhold ramt under flere URL'er, med afsluttende skråstreger, store bogstaver eller parametre	Vælg én kanonisk URL, og link til den overalt
Tid til første crawl	Tiden mellem publicering og første Googlebot-hit på en ny side	Link nye sider fra sider, der allerede crawles ofte, og hold dit sitemap rent
Svartid	Langsomme svar på de skabeloner, Googlebot rammer mest	Gør de skabeloner hurtigere først, da Google siger, at langsomme svar får det til at crawle mindre

Rækken "manglende crawls" er den, folk springer over, og den er ofte den dyreste. En side, du aldrig ser i loggen, kan stadig ikke rangere for noget, selv når indholdet er fremragende. Hvis en URL står i dit sitemap, men aldrig dukker op i logfilerne, kan siden sandsynligvis kun nås via en sti, som crawlere ikke følger. Guiden om Crawled, currently not indexed dækker den anden side af situationen, hvor Googlebot besøger men stadig ikke indekserer.

Tre måder at køre analysen på, sammenlignet

Du kan køre logfilanalyse med scripts, med et desktopprogram eller med en platform. Hver løsning passer til forskellige mængder og forskellige teams. Valget afhænger mindre af sitets størrelse end af, hvor ofte du har brug for svaret, og hvem der skal læse det.

Kommandolinjen: grep, awk og Python

Princip: du parser de rå filer med scripts og skriver resultaterne til en fil eller et regneark. Hvornår du bruger det: engangstjek, små sites eller en udvikler, der vil have fuld kontrol. Fordele: det er gratis, du ser hver linje, og du kan automatisere det med et planlagt job. Begrænsninger: det tager tid at skrive og vedligeholde, det kører kun så hurtigt som din maskine, det har ingen grafer, og du skal selv verificere bots.

Eksempel: kommandoerne i metodeafsnittet, kørt én gang om måneden på samme eksport, giver dig fordelingen af statuskoder og de hyppigste stier for Googlebot. Et kort Python-script kan gøre det samme og tilføje DNS-tjekket, som er langsommere men mere præcist.

Desktopværktøj: Screaming Frog Log File Analyser

Princip: du importerer rå logfiler i et desktopprojekt, og værktøjet grupperer bots, tjekker deres identitet og tegner grafer. Hvornår du bruger det: en konsulent eller en intern analytiker, der arbejder på et site med titusindvis af URL'er. Fordele: det læser Apache-, IIS- og Nginx-logs i W3C Extended-format, verificerer søgemaskinebots og markerer store eller langsomme sider. Begrænsninger: gratisversionen er begrænset, og mængden af data du kan indlæse, afhænger af din harddisk.

Læs Screaming Frogs side om Log File Analyser, før du køber. For en fuld gennemgang af crawleren, der passer sammen med den, se vores guide til Screaming Frog SEO Spider. Log-analysatoren gør én ting, crawleren ikke kan: den viser, hvad bots faktisk anmodede om i den virkelige verden, ikke hvad dine links antyder.

Platform: løbende logovervågning

Princip: platformen modtager dine logs efter en fast plan, ofte fra CDN'et eller serveren, og sammenkæder dem med en crawl af dit site og med indekseringsdata. Hvornår du bruger det: store e-handelssites eller enterpriseteams, der overvåger crawling hver uge på tværs af flere markeder. Fordele: den skalerer til meget store logs, gemmer historik, og flere teams kan dele dashboards. Begrænsninger: den koster mere, tager tid at onboarde, og låsningen er reel, så tjek, hvordan du kan eksportere dine data, før du forpligter dig. Udbydere i denne kategori inkluderer Oncrawl og Botify, og det er værd at spørge hver af dem, hvordan de verificerer bots.

Kriterium	Kommandolinje	Desktopværktøj	Platform
Pris	Gratis	Gratis op til 1000 logbegivenheder, £99 om året for den fulde licens	Abonnement, prisen afhænger af volumen
Opsætning	Du skriver og vedligeholder scripts	Installér, importér, start	Konnektorer og onboarding
Volumen	Begrænset af din maskine	Begrænset af din harddisk og licens	Bygget til meget store logs
Botverifikation	Manuelt, med DNS- eller IP-intervaltjek	Indbygget	Spørg leverandøren
Bedst til	Engangstjek og små sites	Konsulenter og mellemstore sites	Enterprise- og e-handelsteams med ugentlig overvågning

Googles rapport Crawlstatistik: nyttig, men ikke nok

Før du eksporterer en eneste logfil, så åbn rapporten Crawlstatistik i Search Console. Den viser samlede crawl-anmodninger, samlet downloadstørrelse, gennemsnitlig svartid, svar grupperet efter type, filtyper, crawl-formål og hvilken Googlebot-type der lavede hver anmodning. Til et trendtjek er det den hurtigste visning, du har, og guiden til Google Search Console forklarer, hvor du finder den.

Dens begrænsninger forklarer, hvorfor logfilerne stadig betyder noget. Rapporten er kun tilgængelig for domæneegenskaber og URL-præfiks-egenskaber på rodniveau. Den dækker kun Googles crawlere, så GPTBot, ClaudeBot og de andre bots mangler. Den grupperer data i stedet for at liste hver URL, så den kan fortælle dig, at crawl-anmodningerne faldt, men ikke hvilke skabeloner der mistede dem. Brug den til at opdage, at noget har ændret sig, og brug derefter logfilerne til at finde ud af hvad.

Googles hjælpeside til Crawlstatistik beskriver hver gruppering. Når grafen og din logeksport ikke stemmer overens, så stol ikke på nogen af dem, før du har tjekket tidsvinduet og verifikationstrinnet. De fleste af disse uoverensstemmelser skyldes et andet vindue, et CDN der svarer fra cache, eller et botantal der inkluderer uverificerede anmodninger.

Ret crawl-spild, når du først ser det

Rettelserne følger af signalerne. De fleste kommer ned på tre greb: stop med at sende crawlere til sider, der ikke betyder noget, send dem direkte til den endelige URL, når en side er flyttet, og gør de sider, der betyder noget, hurtigere at indlæse.

Facetteret navigation. Filtre og sorteringer skaber mange URL'er med næsten samme indhold. Konsolidér dem med canonicals, hvor du kan, og fjern de interne links til varianter uden søgeværdi. Hvor en variant ikke kan konsolideres og skal holdes ude af crawlet, så bloker den i robots.txt. Googles vejledning er præcis her: brug ikke noindex til dette, for Google skal stadig anmode om siden, før den kan se tagget. Her er den slags regel, du skal teste:

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

Hold robots.txt-ændringen i proportion. Google siger, at blokering af URL'er ikke frigør crawl budget til dine andre sider, medmindre sitet allerede rammer sin kapacitetsgrænse. Blokering er til URL'er uden værdi, ikke en måde at flytte budget hen til dine bedste sider. Vores ordlistepunkt om robots.txt forklarer, hvordan filen læses.

Omdirigeringskæder. Når en side er flyttet to gange, går crawleren gennem begge omdirigeringer hver gang. Opdatér de interne links, så de peger på den endelige URL, og behold derefter de gamle omdirigeringer til eksterne links. Valget mellem en permanent og en midlertidig omdirigering betyder noget af samme grund, og guiden om 301 vs 302 dækker det i detaljer.

Slettede sider. Returnér 404 eller 410 for sider, der er fjernet permanent. Google siger, at bløde 404'er bliver ved med at blive crawlet og spilder crawl budget, så en "siden findes ikke"-besked serveret med status 200 er værre end en rigtig 404.

Svartid og caching. Google siger, at langsomme eller fejlende svar får den til at crawle mindre. Understøt 304-svar (Not Modified), så uændrede sider kan serveres fra cache. Kig derefter på de skabeloner, der får flest Googlebot-hits, og gør disse svar hurtigere først.

Fejlene, der koster mest, og hvordan du undgår dem

De fleste logfilanalyser, der går galt, begår en af en lille række fejl. Hver af dem nedenfor har et symptom, du kan se i dataene, og en rettelse, du kan anvende samme uge.

At stole på user agent-strengen

Hvad det er: at tælle hver anmodning, der siger "Googlebot", som Googles crawl. Sådan opdager du det: Googlebot-hits fra IP-adresser, der ikke løser omvendt til Googles værtsnavne, eller et pludseligt spring fra én enkelt adresse. Sådan retter du det: kør verifikationen fra metodeafsnittet, før du tæller noget, og hold de uverificerede hits i en separat bøtte, så du stadig kan se scraper-aktivitet.

Kun at læse 200-svarene

Hvad det er: at fokusere på sider, der returnerer 200, og ignorere resten. Sådan opdager du det: din rapport har ingen 3xx-, 4xx- eller 5xx-sektion, eller fordelingen af statuskoder bliver aldrig diskuteret. Sådan retter du det: start altid med fordelingen af statuskoder. En stigning i 404-hits kan afsløre et brudt internt link, og en stigning i 5xx-hits kan afsløre et serverproblem, der bremser hele crawlet.

At blokere en side, du vil have afindekseret

Hvad det er: at tilføje en robots.txt-regel til en side, der også har et noindex-tag. Sådan opdager du det: siden bliver i indekset, og loggen viser ingen Googlebot-hits, fordi crawleren er forhindret i at anmode om den. Sådan retter du det: fjern blokeringen, så Google kan læse noindex-tagget, vent til siden forsvinder fra indekset, og genindfør derefter blokeringen, hvis du stadig har brug for den. Guiden om Blocked by robots.txt forklarer den Search Console-status, der dukker op i dette tilfælde.

At sammenligne vinduer af forskellig længde

Hvad det er: at sammenligne en 3-dages eksport før en rettelse med en 30-dages eksport efter. Sådan opdager du det: totalerne bevæger sig meget, men andelen pr. skabelon gør ikke. Sådan retter du det: sammenlign det samme antal dage, helst på samme tid af året, og sammenlign andele i stedet for rå totaler, når volumen ændrer sig.

At måle hits i stedet for værdi

Hvad det er: at fejre en stigning i Googlebot-hits uden at tjekke, om hitsene når sider, der bliver indekseret. Sådan opdager du det: hitsene koncentreres på URL'er, der ikke er indekseret, eller som aldrig får trafik. Sådan retter du det: sammenkæd dine loggrupper med indekseringsstatus fra URL-kontrolværktøjet i Search Console, og tæl kun en rettelse som en sejr, når crawlet bevæger sig hen mod sider, der betyder noget.

Hvor AI-bots passer ind i de samme logs

De samme logs viser, hvad AI-crawlere gør på dit site, og metoden er den samme: gruppér dem, verificér dem, hvor udbyderen giver en måde at gøre det på, og læs statuskoderne. Vores guide til AI-crawler-logs dækker, hvilke bots du skal lede efter, og hvordan de adskiller sig fra Googlebot. Denne artikel dækker Googlebot-metoden i dybden, og AI-afsnittet nedenfor viser, hvordan du får begge med i samme rapport.

Bottype	Eksempler	Hvad du tjekker i logs	Læs mere
Søgecrawler	Googlebot	Hits pr. skabelon, fordeling af statuskoder, tid til første crawl på nye sider	Afsnittene ovenfor i denne artikel
Træningscrawler	GPTBot, ClaudeBot, CCBot	Om de overhovedet anmoder om dit indhold, og om de respekterer din robots.txt	Robots.txt for AI-crawlere
Hentecrawler	ChatGPT-User, PerplexityBot	Korte udbrud af besøg knyttet til brugernes spørgsmål, og de sider, udbruddene rammer	AI-crawler-logs

Opdelingen mellem træning og hentning kommer af den måde, AI-crawlere er dokumenteret på. Træningscrawlere indsamler indhold til modeller, og hentecrawlere henter sider, når en bruger stiller et spørgsmål. Din rapport bør holde de to adskilt, for en politikbeslutning for den ene gælder ikke automatisk for den anden.

Hvis du vil se Google-trafik og AI-trafik side om side, mens du udruller disse rettelser, viser Soranks GEO / SEO-dashboard begge i ét view. Brug det til at tjekke, om de ændringer, du laver ud fra logfilerne, flytter trafik, ikke kun om de ændrer antallet af crawls.