Loggfilsanalys för SEO: läs dina serverloggar och åtgärda crawl-slöseri

Snabbquiz

Är SEO rätt för dig, och hur ska du börja?

Fråga 1 av 425%

Söker folk på Google efter det du säljer?

Ja, jag tror detNej, det är nytt eller mycket nischatJag vet inte

Vad en serverlogg registrerar, och varför den slår dina övriga data

Varje gång något begär en fil från din server skriver servern en rad i sin åtkomstlogg. De flesta servrar använder ett format nära Apaches "combined"-format. En förfrågan från Googlebot ser ut så här:

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 från vänster till höger: IP-adressen, tidsstämpeln, HTTP-metoden och URL:en, statuskoden (här 200), antalet byte som skickats, referrern och user agent. Varje förfrågan finns med, även de som aldrig syns som sidvisning i ditt analysverktyg: bilder, CSS-filer, omdirigeringar och 404-fel.

Dina andra datakällor ser var sin del av detta. Rapporten Crawlstatistik i Search Console är aggregerad och täcker bara Googles sökrobotar. Analysverktyg registrerar bara besökare vars webbläsare kör ditt JavaScript. En sajtcrawler som Screaming Frog visar det den kan nå genom att följa dina länkar, vilket inte är samma sak som vad Google valde att begära. Bara serverloggen registrerar vad som faktiskt hände.

Varför logganalys spelar roll: crawl-budget i enkla termer

Crawl-budget är uppsättningen URL:er som Google kan och vill crawla på din sajt. Google beskriver den med två faktorer. Den första är kapacitetsgränsen för crawl: hur många anslutningar Googles sökrobotar kan hålla öppna mot din server utan att överbelasta den. Gränsen höjs när sajten håller sig frisk och sänks när svarstiderna ökar eller när servern svarar med 5xx- eller 429-fel. Den andra är crawl-efterfrågan, som beror på sajtens storlek, hur ofta innehållet ändras, dess kvalitet och hur populära sidorna är.

Google presenterar ämnet som en avancerad guide för stora sajter. Dess ungefärliga gränser är sajter med 1 miljon eller fler unika sidor vars innehåll ändras ungefär en gång i veckan, och sajter med 10000 eller fler unika sidor vars innehåll ändras varje dag. Sajter där många URL:er ligger i statusen "Discovered - currently not indexed" faller också inom ramen. Mindre sajter kan vanligtvis förlita sig på en aktuell sitemap och regelbundna kontroller av rapporten Sidindexering. Det betyder inte att loggar är oanvändbara för dem. När något är fel med crawlingen är loggen det snabbaste sättet att se exakt var.

Om din sajt ligger i det intervallet är frågan inte längre om du ska läsa loggar utan hur ofta. En engångsgranskning visar slöseriet i dag. En månatlig export visar om dina åtgärder ändrade vad Googlebot lägger sin tid på. För bakgrund om begreppen förklarar ordlistan om crawl-budget grunderna, och guiden om Discovered, currently not indexed förklarar statusen som brukar utlösa den här typen av granskning.

Metoden, steg för steg

Arbetsflödet nedan fungerar med alla servrar och alla verktyg. Avsnitten längre ner förklarar varje steg i detalj och ger kommandona du kan köra på en råloggfil redan i dag.

Hämta loggarna från rätt lager

Be din utvecklare eller ditt webbhotell om de råa åtkomstloggarna från webbservern (Apache, Nginx eller IIS). Kontrollera tre saker innan du börjar: loggformatet, tidszonen och hur länge loggarna sparas. Beroende på din uppsättning kan gamla loggar roteras bort efter några dagar eller veckor, så be om exporten nu i stället för senare.

Lagret spelar större roll än folk tror. Om ett CDN svarar på en förfrågan från sin cache ser din origin-server aldrig den. Googlebot kan crawla en URL som aldrig syns i din origin-logg, så en export enbart från origin räknar för lågt på cachat innehåll. Exportera även CDN-loggarna och jämför de två källorna för några URL:er innan du litar på någon av totalerna.

Filtrera och räkna Googlebot med några kommandon

I en logg i combined-format är statuskoden det 9:e fältet och URL-sökvägen det 7:e. De två kolumnerna besvarar de flesta första frågor. Det här kommandot räknar Googlebot-förfrågningar per statuskod:

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

Det här listar de 20 sökvägar som Googlebot begär oftast, med frågesträngen borttagen så att filtervarianter grupperas tillsammans:

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

Det första kommandot läser user agent-texten, som vem som helst kan förfalska. Behandla resultatet som en kandidatlista tills nästa avsnitt är klart. Om din logg använder ett eget format ändras fältnumren, så kontrollera en rad för hand innan du litar på kolumnerna.

Verifiera Googlebot så som Google beskriver det

Googles egen metod för att bekräfta att en besökare är Googlebot använder DNS. Gör en omvänd DNS-uppslagning på IP-adressen från din logg, kontrollera att värdnamnet slutar på googlebot.com, google.com eller googleusercontent.com, gör sedan en framåtriktad uppslagning på värdnamnet och kontrollera att den returnerar den ursprungliga IP-adressen. Googles dokumentation använder detta exempel, där 66.249.66.1 löses omvänt till crawl-66-249-66-1.googlebot.com:

host 66.249.66.1

Den framåtriktade kontrollen är det andra kommandot, och den måste returnera samma IP:

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

Om du bearbetar miljontals rader blir DNS-uppslagningarna långsamma. Google publicerar också JSON-filer med sina crawler-IP-intervall, bland annat common-crawlers.json för Googlebot. Att matcha mot dessa intervall går snabbare, och den officiella verifieringsguiden beskriver båda metoderna i Googles guide för att verifiera Googlebot.

Gruppera, mät och läs resultaten

Råa antal per URL är svåra att agera på. Gruppera därför URL:erna per mall först, eftersom en åtgärd oftast gäller en mall och inte en enskild sida. Mät sedan fyra saker för varje grupp. Mät hur många Googlebot-träffar den får jämfört med hur viktig den är för din verksamhet. Mät statuskodsfördelningen. Mät hur snabbt nya sidor får sin första träff efter publicering. Mät om träffarna koncentreras på de sidor du vill ska rankas.

Läs resultaten som ett mönster, inte som en enskild siffra. Om de flesta Googlebot-träffarna hamnar på filter-URL:er och bara några få på produktsidor läcker crawl-budgeten, och problemet ligger troligen i interna länkar eller i hur parametrar hanteras, inte i produktsidorna. Nästa avsnitt listar signalerna att leta efter.

De sju signalerna gömda i loggarna

När Googlebot-raderna är verifierade och grupperade förklarar sju signaler de flesta crawlproblem. Tabellen anger mönstret att leta efter och den vanliga åtgärden. Varje åtgärd är en ändring på sajten, så bekräfta den i nästa export.

Signal	Vad loggarna visar	Vad du gör
Crawl-slöseri	Googlebot-träffar på filter, sorteringsordningar, intern sökning och session-URL:er	Konsolidera med canonicals, ta bort de interna länkarna till dessa URL:er och blockera meningslösa varianter i robots.txt där de inte kan konsolideras
Omdirigeringar	Träffar på 301- eller 302-svar, och kedjor med två eller fler hopp	Länka direkt till slut-URL:en. Guiden om 301 vs 302 hjälper dig välja rätt typ av omdirigering
Fel	Upprepade 404- eller 410-träffar och toppar av 5xx-svar	Återställ eller omdirigera sidor som fortfarande spelar roll, och åtgärda serverfel, eftersom 5xx-svar minskar hur mycket Google crawlar
Saknade crawlar	Viktiga URL:er utan någon Googlebot-träff alls i fönstret	Kontrollera interna länkar, sitemap-poster och robots.txt-regler som kan hålla sökrobotar borta från dem
Dubletter	Samma innehåll träffat under flera URL:er, med snedstreck på slutet, versaler eller parametrar	Välj en kanonisk URL och länka till den överallt
Tid till första crawl	Tiden mellan publicering och första Googlebot-träff på en ny sida	Länka nya sidor från sidor som crawlas ofta, och håll din sitemap ren
Svarstid	Långsamma svar på de mallar Googlebot träffar mest	Snabba upp de mallarna först, eftersom Google säger att långsamma svar får den att crawla mindre

Raden om saknade crawlar är den som folk hoppar över, och den är ofta dyrast. En sida du aldrig ser i loggen kan fortfarande inte rankas för något, även om innehållet är utmärkt. Om en URL finns i din sitemap men aldrig syns i loggarna nås sidan troligen bara via en väg som crawlers inte följer. Guiden om Crawled, currently not indexed täcker den andra sidan av situationen, när Googlebot besöker sidan men ändå inte indexerar den.

Tre sätt att köra analysen, jämförda

Du kan köra logganalys med skript, med ett skrivbordsprogram eller med en plattform. Varje alternativ passar olika volym och olika team. Valet beror mindre på sajtens storlek än på hur ofta du behöver svaret och vem som ska läsa det.

Kommandoraden: grep, awk och Python

Princip: du tolkar råfilerna med skript och skriver resultaten till en fil eller ett kalkylblad. När du använder det: engångskontroller, små sajter eller en utvecklare som vill ha full kontroll. Fördelar: det är gratis, du ser varje rad och du kan automatisera det med ett schemalagt jobb. Begränsningar: det tar tid att skriva och underhålla, det går bara så snabbt som din dator, det har inga diagram och du måste verifiera bottarna själv.

Exempel: kommandona i metodavsnittet, körda en gång i månaden på samma export, ger dig statuskodsfördelningen och de vanligaste sökvägarna för Googlebot. Ett kort Python-skript kan göra detsamma och dessutom lägga till DNS-kontrollen, som är långsammare men mer exakt.

Skrivbordsverktyg: Screaming Frog Log File Analyser

Princip: du importerar råloggarna till ett skrivbordsprojekt, och verktyget grupperar bottarna, kontrollerar deras identitet och ritar diagrammen. När du använder det: en konsult eller en analytiker i huset som arbetar med en sajt med tiotusentals URL:er. Fördelar: det läser Apache-, IIS- och Nginx-loggar i W3C Extended-format, verifierar sökmotorernas bottar och flaggar stora eller långsamma sidor. Begränsningar: gratisversionen är begränsad, och mängden data du kan ladda beror på hårddisken.

Läs Screaming Frogs sida om Log File Analyser innan du köper. För en fullständig genomgång av crawlern som passar ihop med den, se vår guide om Screaming Frog SEO Spider. Logganalysatorn gör ett jobb som crawlern inte kan göra: den visar vad bottar faktiskt begärde i verkligheten, inte vad dina länkar antyder.

Plattform: kontinuerlig loggövervakning

Princip: plattformen tar emot dina loggar enligt schema, ofta från CDN:et eller servern, och kopplar dem till en crawl av din sajt och till indexeringsdata. När du använder det: stora e-handelssajter eller företagsteam som övervakar crawlingen varje vecka över flera marknader. Fördelar: den skalar till mycket stora loggar, sparar historik och låter flera team dela dashboards. Begränsningar: den kostar mer, tar tid att komma igång med, och inlåsningen är verklig, så kontrollera hur du kan exportera din data innan du binder dig. Leverantörer i kategorin inkluderar Oncrawl och Botify, och det är värt att fråga varje leverantör hur den verifierar bottar.

Kriterium	Kommandorad	Skrivbordsverktyg	Plattform
Kostnad	Gratis	Gratis upp till 1000 loggrader, £99 per år för full licens	Prenumeration, priset beror på volym
Installation	Du skriver och underhåller skripten	Installera, importera, starta	Kopplingar och onboarding
Volym	Begränsad av din dator	Begränsad av hårddisk och licens	Byggd för mycket stora loggar
Botverifiering	Manuell, med DNS- eller IP-intervallskontroller	Inbyggd	Fråga leverantören
Bäst för	Engångskontroller och små sajter	Konsulter och medelstora sajter	Företag och e-handel med veckovis övervakning

Googles rapport Crawlstatistik: användbar, men inte tillräcklig

Innan du exporterar en enda logg, öppna rapporten Crawlstatistik i Search Console. Den visar totalt antal crawl-förfrågningar, total nedladdningsstorlek, genomsnittlig svarstid, svar grupperade per typ, filtyper, crawlsyfte och vilken Googlebot-typ som gjorde varje förfrågan. För en trendkontroll är det den snabbaste vyn du har, och Google Search Console-guiden förklarar var du hittar den.

Dess begränsningar förklarar varför loggarna fortfarande spelar roll. Rapporten finns bara för domänegenskaper och URL-prefix på rotnivå. Den täcker bara Googles sökrobotar, så GPTBot, ClaudeBot och de andra bottarna saknas. Den grupperar data i stället för att lista varje URL, så den kan visa att crawl-förfrågningarna minskade men inte vilka mallar som tappade dem. Använd den för att upptäcka att något förändrats, och använd sedan loggarna för att ta reda på vad.

Googles hjälpsida om Crawlstatistik beskriver varje gruppering. När diagrammet och din loggexport inte stämmer överens, lita inte på något av dem förrän du kontrollerat tidsfönstret och verifieringssteget. De flesta av avvikelserna beror på ett annat fönster, ett CDN som svarar från cache eller ett botantal som inkluderar overifierade förfrågningar.

Åtgärda crawl-slöseri när du väl ser det

Åtgärderna följer av signalerna. De flesta kommer ner till tre grepp: sluta skicka crawlers till sidor som inte spelar roll, skicka dem direkt till slut-URL:en när en sida har flyttats, och gör sidorna som är viktiga snabbare att ladda.

Facetterad navigering. Filter och sorteringsordningar skapar många URL:er med nästan samma innehåll. Konsolidera dem med canonicals där det går, och ta bort de interna länkarna till varianter som saknar sökvärde. Där en variant inte kan konsolideras och ändå måste hållas borta från crawlen, blockera den i robots.txt. Googles riktlinjer är tydliga här: använd inte noindex för detta, eftersom Google fortfarande måste begära sidan innan den kan se taggen. Så här ser den typ av regel ut som du ska testa:

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

Håll ändringen i robots.txt i proportion. Google säger att blockering av URL:er inte frigör crawl-budget för dina andra sidor, om inte sajten redan når sin kapacitetsgräns. Blockering är till för URL:er utan värde, inte ett sätt att flytta budget mot dina bästa sidor. Vårt ordlisteavsnitt om robots.txt förklarar hur filen tolkas.

Omdirigeringskedjor. När en sida flyttats två gånger går crawlern igenom båda omdirigeringarna varje gång. Uppdatera de interna länkarna så att de pekar på slut-URL:en, och behåll sedan de gamla omdirigeringarna för externa länkar. Valet mellan permanent och tillfällig omdirigering är viktigt av samma skäl, och guiden om 301 vs 302 går igenom det i detalj.

Borttagna sidor. Returnera 404 eller 410 för sidor som tagits bort permanent. Google säger att soft 404 fortsätter att crawlas och slösar crawl-budget, så ett meddelande om att sidan inte finns som skickas med status 200 är sämre än en riktig 404.

Svarstid och cache. Google säger att långsamma eller misslyckade svar gör att den crawlar mindre. Stöd 304 (Not Modified)-svar, så att oförändrade sidor kan serveras från cache. Titta sedan på de mallar som får flest Googlebot-träffar och gör de svaren snabbare först.

Misstagen som kostar mest, och hur du undviker dem

De flesta logganalyser som går fel gör ett av ett litet antal misstag. Vart och ett av dem nedan har en symptom du kan se i datan och en åtgärd du kan genomföra samma vecka.

Att lita på user agent-strängen

Vad det är: att räkna varje förfrågan som säger "Googlebot" som Googles crawl. Hur du upptäcker det: Googlebot-träffar från IP-adresser som inte löses omvänt till Googles värdnamn, eller ett plötsligt hopp från en enskild adress. Hur du åtgärdar det: kör verifieringen från metodavsnittet innan du räknar något, och håll de overifierade träffarna i en separat grupp så att du fortfarande ser scraper-aktivitet.

Att bara läsa 200-svaren

Vad det är: att fokusera på sidor som returnerar 200 och ignorera resten. Hur du upptäcker det: din rapport saknar ett avsnitt för 3xx, 4xx eller 5xx, eller så diskuteras aldrig statuskodsfördelningen. Hur du åtgärdar det: börja alltid med fördelningen av statuskoder. En ökning av 404-träffar kan avslöja en trasig intern länk, och en ökning av 5xx-träffar kan avslöja ett serverproblem som bromsar hela crawlen.

Att blockera en sida du vill avindexera

Vad det är: att lägga till en robots.txt-regel på en sida som också har en noindex-tagg. Hur du upptäcker det: sidan ligger kvar i indexet, och loggen visar inga Googlebot-träffar, eftersom crawlern hindras från att begära den. Hur du åtgärdar det: ta bort blockeringen så att Google kan läsa noindex-taggen, vänta tills sidan försvinner ur indexet och återställ sedan blockeringen om du fortfarande behöver den. Guiden om Blocked by robots.txt förklarar Search Console-statusen som visas i det här fallet.

Att jämföra fönster av olika längd

Vad det är: att jämföra en 3-dagarsexport före en åtgärd med en 30-dagarsexport efter den. Hur du upptäcker det: totalerna rör sig mycket, men andelen per mall gör det inte. Hur du åtgärdar det: jämför samma antal dagar, helst vid samma tid på året, och jämför andelar i stället för råa totaler när volymen ändras.

Att mäta träffar i stället för värde

Vad det är: att fira en ökning av Googlebot-träffar utan att kontrollera om träffarna når sidor som indexeras. Hur du upptäcker det: träffarna koncentreras på URL:er som inte är indexerade eller som aldrig ger trafik. Hur du åtgärdar det: koppla dina logggrupper till indexeringsstatus från verktyget URL-kontroll i Search Console, och räkna bara en åtgärd som vinst när crawlen rör sig mot sidor som spelar roll.

Var AI-bottar passar in i samma loggar

Samma loggar visar vad AI-crawlers gör på din sajt, och metoden är densamma: gruppera dem, verifiera dem där leverantören ger ett sätt att göra det, och läs statuskoderna. Vår guide om AI-crawler-loggar täcker vilka bottar du ska leta efter och hur de skiljer sig från Googlebot. Den här artikeln går igenom Googlebot-metoden på djupet, och AI-avsnittet nedan visar hur du lägger båda i samma rapport.

Bottyp	Exempel	Vad du kontrollerar i loggarna	Läs mer
Sökcrawler	Googlebot	Träffar per mall, statuskodsfördelning, tid till första crawl på nya sidor	Avsnitten ovan i den här artikeln
Träningscrawler	GPTBot, ClaudeBot, CCBot	Om de begär ditt innehåll alls, och om de respekterar din robots.txt	Robots.txt för AI-crawlers
Hämtningscrawler	ChatGPT-User, PerplexityBot	Korta skurar av besök kopplade till användarnas frågor, och vilka sidor skurarna når	AI-crawler-loggar

Uppdelningen mellan träning och hämtning kommer från hur AI-crawlers dokumenteras. Träningscrawlers samlar in innehåll för modeller, och hämtningscrawlers hämtar sidor när en användare ställer en fråga. Din rapport bör hålla isär de två, eftersom ett policybeslut för den ena inte automatiskt gäller den andra.

Om du vill se Google-trafik och AI-trafik sida vid sida när du genomför dessa åtgärder visar Soranks GEO / SEO-dashboard båda i en vy. Använd den för att kontrollera om ändringarna du gör utifrån loggarna flyttar trafiken, inte bara om de ändrar antalet crawlar.