Svaret på om ChatGPT, Claude eller Perplexity har hämtat dina sidor står i serverloggen, och det tar några minuter att få fram. Två saker gör ändå att de flesta läser loggen fel. Botarna har olika uppdrag, så ett namn säger inte det du tror att det säger. Och namnet går att skriva dit själv. När vi gick igenom vår egen logg för de senaste två veckorna bar 16 anrop namnet på en AI-bot. Elva av dem var påhittade.
Tre sorters botar, tre olika besked
Att göra sajten läsbar för språkmodeller är en konfigurationsuppgift, och den har vi gått igenom i guiden om att göra din sajt läsbar för AI-sökmotorer. Att i efterhand ta reda på vad som faktiskt hände är något annat. Där räcker det inte att veta vilka namn som finns, du behöver veta vad varje namn betyder.
Leverantörerna delar upp sina robotar i tre roller. En träningscrawler samlar text som kan komma att ingå i framtida modeller. En sökindexerare bygger det index som tjänsten slår i när någon ställer en fråga. En hämtare på begäran går ut och läser en enskild sida i samma stund som en användare frågar om den.
Skillnaden är inte akademisk. Ser du en träningscrawler i loggen vet du att din text kan hamna i en modell om ett år eller två. Det säger ingenting om huruvida du syns i svaren i dag. Ser du i stället en hämtare på begäran vet du att en verklig människa nyss ställde en fråga där din sida kom på tal. Det är den enda av de tre som är en direkt signal om nuvarande synlighet, och den kommer i regel i enstaka anrop, inte i svep.
Namnen du ska söka efter
Namnen nedan är kontrollerade den 4 augusti 2026 mot respektive leverantörs egen dokumentation. Håll listan färsk, den ändras oftare än man tror.
OpenAI dokumenterar fyra robotar. GPTBot hämtar innehåll som kan användas för att träna modellerna. OAI-SearchBot används för att lyfta fram sajter i ChatGPT:s sökfunktion. ChatGPT-User besöker en sida när en användare eller en anpassad GPT ställer en fråga. OAI-AdsBot kontrollerar säkerheten hos sidor som lämnats in som annonser. Alla fyra bär sitt namn i user agent-strängen, i formen GPTBot/1.4 och så vidare.
Anthropic dokumenterar tre, i en artikel senast daterad den 7 april 2026. ClaudeBot samlar webbinnehåll som kan bidra till modellträning. Claude-User hämtar sidor när enskilda användare frågar Claude något. Claude-SearchBot analyserar innehåll för att förbättra kvaliteten i sökresultaten. Notera att Anthropic på den sidan bara publicerar robotarnas namn, inte deras fullständiga user agent-strängar. Sök därför på namnet som delsträng.
Perplexity dokumenterar två, och är ovanligt tydlig med gränsdragningen. PerplexityBot finns till för att lyfta fram och länka sajter i Perplexitys sökresultat, och används enligt bolaget inte för att samla innehåll till modellträning. Perplexity-User hämtar en sida när en användare ställt en fråga. Om den senare skriver Perplexity rakt ut att den i regel struntar i robots.txt, eftersom det är användaren och inte tjänsten som initierat hämtningen.
Common Crawl är en stiftelse utan vinstsyfte som bygger ett öppet webbarkiv, och deras arkiv är i sin tur en vanlig träningskälla för AI-projekt. Roboten heter CCBot och presenterar sig som CCBot/2.0 (https://commoncrawl.org/faq/).
Google-Extended kommer du aldrig att se
Här finns en fälla som kostar tid. Många listor över AI-botar tar med Google-Extended, och det är rätt så länge man talar om robots.txt. Men Googles egen dokumentation är otvetydig: Google-Extended ”doesn’t have a separate HTTP request user agent string”, utan crawlningen sker med Googles befintliga user agent-strängar och tokenet används enbart för styrning.
Med andra ord: du kan blockera eller tillåta Google-Extended, men du kommer aldrig att kunna se den i din access-logg. Söker du efter namnet där får du noll träffar oavsett hur din sajt behandlas, och den nollan betyder ingenting. Tokenet styr om Google får använda ditt innehåll för att träna kommande Gemini-modeller och för grundning i Gemini-apparna, och det påverkar enligt Google varken din närvaro i vanliga sökresultat eller din ranking där.
Var loggen ligger
På en egen server eller VPS med nginx är standardsökvägen den som anges i nginx dokumentation för access_log, alltså logs/access.log relativt installationens rot. På en distributionspaketerad nginx blir det i praktiken oftast /var/log/nginx/access.log. Kör du Apache heter filen typiskt access_log eller access.log och ligger under /var/log/apache2/ på Debian och Ubuntu, eller under /var/log/httpd/ på Red Hat-baserade system. Exakt sökväg står i din CustomLog-rad.
På ett hanterat webbhotell med SSH får varje konto ofta en egen loggkatalog, vanligen ~/logs/<domän>/access.log. Där brukar loggarna dessutom roteras dagligen och komprimeras, så gårdagens fil heter access.log.1 och veckan innan ligger som access.log.5.gz. Söker du bara i den aktuella filen missar du allt utom de senaste timmarna.
Raden du tittar på, fält för fält
En rad i det som Apache kallar Combined Log Format ser ut så här. Adressen är utbytt mot en dokumentationsadress, resten är en verklig rad ur vår logg:
203.0.113.42 - - [02/Aug/2026:17:10:35 +0200] "GET /wp-content/themes/atdt-gp-siteaudit/style.css?ver=1.0.0 HTTP/1.1" 200 1315 "https://www.siteaudit.se/" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; GPTBot/1.4; +https://openai.com/gptbot)"Fälten är, i ordning: klientens IP-adress, två fält för identitet och inloggad användare som nästan alltid är tomma streck, tidsstämpel med tidszon, själva begäran inom citattecken, HTTP-statuskoden, antalet skickade byte, hänvisande sida och sist user agent-strängen. Det är i det sista fältet botnamnet står.
Och här ligger den vanligaste orsaken till att en sajtägare inte hittar någonting alls. Apaches Common Log Format, som fortfarande är den formatsträng många guider utgår från, är %h %l %u %t "%r" %>s %b. Den innehåller varken hänvisande sida eller user agent. Det är först Combined Log Format som lägger till "%{Referer}i" "%{User-agent}i". Loggar din server i Common Log Format går frågan helt enkelt inte att besvara ur loggen, oavsett hur skickligt du söker. Byt formatsträng först. I nginx är motsvarande fördefinierade format redan döpt till combined, och det är standardvärdet för access_log.
Kommandona
När formatet är rätt är själva sökningen enkel. Räkna träffar per bot över alla roterade filer på en gång:
cd ~/logs/exempel.se
for bot in GPTBot OAI-SearchBot ChatGPT-User OAI-AdsBot \
ClaudeBot Claude-User Claude-SearchBot \
PerplexityBot Perplexity-User CCBot; do
printf "%-18s %s\n" "$bot" "$(zcat -f access.log* | grep -c "$bot")"
donezcat -f läser både komprimerade och okomprimerade filer, vilket gör att hela den bevarade historiken kommer med. Vill du se vad en enskild bot faktiskt hämtade, och inte bara hur ofta, plockar du fram raderna och klipper ut begäran:
zcat -f access.log* | grep "GPTBot" | awk -F'"' '{print $2}' | sort | uniq -c | sort -rnEn detalj som Google själv påpekar i sin crawler-dokumentation: versionsnumret i strängar av typen Chrome/W.X.Y.Z byts ut mot den Chromium-version roboten kör för tillfället, och det numret ändras löpande. Söker eller filtrerar du på en user agent med det mönstret ska du använda jokertecken i stället för ett exakt versionsnummer. Samma sak gäller AI-botarnas egna versionsnummer. Vår logg innehöll både GPTBot/1.3 och GPTBot/1.4 under samma tvåveckorsperiod, så en sökning på hela strängen hade missat hälften.
Vad vår egen logg visade
Vi körde metoden ovan på siteaudit.se. Underlaget är samtliga bevarade access-loggfiler på ursprungsservern, alltså hela populationen och inget urval, från den 21 juli 2026 klockan 01:40 till den 4 augusti 2026 klockan 13:34. Totalt 749 anrop. Av dem bar 16 något av de tio namnen i listan ovan.
Sedan kontrollerade vi varje enskild träff mot avsändarens egen publicerade adresslista, som beskrivs i nästa avsnitt. Fem av de 16 höll. Samtliga fem var GPTBot, och samtliga fem hämtade stilmallar och skriptfiler, inte artiklar. Elva höll inte: en som kallade sig GPTBot, fyra ChatGPT-User, två ClaudeBot, en OAI-SearchBot, en PerplexityBot och två CCBot. Namnen Claude-User, Claude-SearchBot, Perplexity-User och OAI-AdsBot förekom inte alls under perioden.
Det som avslöjade de elva var inte bara adresserna, utan vad de bad om. De ville ha /.aws/credentials, /secrets.json, /.dev.vars, /serviceAccountKey.json och /swagger.json. Det är sökningar efter läckta nycklar, inte efter läsbart innehåll. En och samma avsändare hann dessutom presentera sig som tre olika AI-botar inom samma sekund. Common Crawl beskriver problemet i klartext på sin egen sida om CCBot: stiftelsen är medveten om att crawlers utger sig för att vara CCBot och rekommenderar att user agent-strängar verifieras.
En sak till, och den är viktigare än siffrorna. Under hela tvåveckorsperioden levererades inte en enda artikelsida med status 200 från ursprungsservern. Tre anrop mot artikel-URL:er avvisades med 403, resten av loggen består av tillgångar och skanningsförsök. Sajten ligger bakom två cachelager, vilket syns direkt i svarsheadrarna, och sidvisningarna besvaras därför innan de når servern som skriver den här loggen. Våra låga tal är alltså inget bevis för att AI-botar inte läser sajten. De visar vad som råkade nå just den här loggpunkten, vilket är en annan sak.
Så avgör du om en träff är äkta
Eftersom user agent-strängen är ett fält som vem som helst kan fylla i själv är ett namn i loggen en uppgift, inte ett bevis. Verifieringen görs på två sätt, och båda beskrivs av leverantörerna själva.
Det ena är omvänd DNS-uppslagning. Google beskriver metoden i fyra steg: slå upp adressen bakåt med host, kontrollera att domännamnet slutar på googlebot.com, google.com eller googleusercontent.com, slå sedan upp det domännamnet framåt och kontrollera att du får tillbaka samma adress som stod i loggen. Common Crawl kör sedan en tid CCBot från adresser med omvänd DNS under crawl.commoncrawl.org, och samma tvåstegskontroll fungerar där.
Det andra är leverantörens publicerade adresslistor. OpenAI, Anthropic, Perplexity, Google och Common Crawl publicerar alla maskinläsbara JSON-filer med de adresser deras robotar kör från, och länkarna till dem finns i respektive dokumentation ovan. Vi skriver medvetet inte ut några adresser här. Listorna uppdateras löpande, och en avskrift i en artikel är fel så fort den blir gammal. Hämta dem från källan varje gång du kontrollerar.
Om ditt webbhotell inte ger dig loggen
Många delade webbhotell ger aldrig kunden råa access-loggar. Man får en besöksstatistik i kontrollpanelen, ofta byggd på JavaScript-mätning, och den fångar per definition inga botar. Ingen bot kör din analysskript-tagg.
Då återstår tre vägar. Ligger sajten bakom en CDN eller brandvägg med botrapportering, till exempel Cloudflare, finns trafiken i den tjänstens egen logg, och det är dessutom den punkt trafiken faktiskt passerar. Har du inte det kan du logga user agent-strängen server-side i själva applikationen, exempelvis genom ett litet insticksprogram som skriver ner tidpunkt, sökväg och user agent till en egen tabell för de tio namnen ovan. Och för Googles del ger Search Console statistik över crawlningen, dock inget om AI-botarna hos övriga leverantörer.
Frågan man till slut bör ställa sig är vad svaret ska användas till. Ett besök från en träningscrawler kan man varken skynda på eller mäta effekten av. Ett besök från en hämtare på begäran betyder att någon nyss fick din sida uppläst för sig, och det är den siffra som är värd att följa över tid. Vill du veta hur väl sajten står sig när den väl blir hämtad kan du köra den genom vår AI-läsbarhetskontroll, och vill du förstå hur de här systemen väljer källor har vi gått igenom det i genomgången av optimering för AI-sökmotorer.