AI-crawler, robots.txt och innehållssignaler

Alla AI-crawlers är inte likadana. Den som vill göra en tydlig åtskillnad mellan synlighet, träning och användarutlösta sökningar behöver mer än en automatisk blockering via robots.txt.

Den här artikeln uppdaterades senast den 18 juni 2026.

info
Skrivet av Saskia Teichmann
den 18 juni 2026
Sändning
Användarrecension
0 (0 röster)
Kommentarer Betyg 0 (0 recensioner)
Humorvolles 1950er-Jahre-Werbeplakat zu AI-Crawlern, robots.txt und sauber getrennten Bot-Zwecken.

Per juni 2026. Så fort webbplatsägare hör talas om AI-crawlers händer ofta en av två saker: Antingen blockeras allt omedelbart, eftersom „AI:n ju inte bara ska stjäla allt“. Eller så lämnas allt öppet, eftersom synlighet på något sätt låter bra. Båda sätten är för grova.

Det bättre sättet är mindre dramatiskt och betydligt mer användbart: Försök först förstå vilken bot som gör vad. Sökning, träning, användarutlöst hämtning, annonsgranskning, testverktyg och revisionsgenomsökning är inte samma sak. Den som slår ihop allt i en och samma kategori förlorar antingen onödigt synlighet eller lämnar saker öppna som egentligen borde kontrolleras.

Sammanfattningen

  • robots.txt styr indexeringen, men inte automatiskt synligheten. En blockerad URL kan ändå dyka upp i sökresultaten om den länkas till från en extern källa.
  • robots.txt är inget skydd för personuppgifter. Privat innehåll ska skyddas med inloggning, lösenord eller placeras i icke-offentliga system, inte bara med en ”disallow”-regel.
  • AI-crawlers har olika uppgifter. Sökrobotar, träningsrobotar och användarutlösta hämtningar måste bedömas separat.
  • Google-Extended är inte en egen synlig sökrobot. Det är en kontroll-token i robots.txt och enligt Google påverkar den Gemini-träning och grounding, inte rankningen i Googles sökmotor.
  • Den som blockerar sökrobotar riskerar att förlora sin synlighet för AI. Den som tillåter träningsbotar fattar ett annat beslut. Just denna åtskillnad är viktig.
  • Innehållssignalerna är fortfarande avgörande. Tydligt innehåll, bra struktur, korrekta Schema-data, webbkartor, interna länkar och maskinläsbara versioner är till större hjälp än panikartat ”bot-bingo”.

Mitt råd: Betrakta robots.txt som en skylt på dörren, inte som ett kassaskåp. För att synas behöver du tillgänglighet och positiva signaler. För att skydda dig behöver du verklig åtkomstkontroll. Det är två olika områden.

Vad robots.txt egentligen gör

Filen robots.txt finns i rotkatalogen på din webbplats, till exempel under https://example.com/robots.txt. Seriösa sökrobotar läser den innan de hämtar sidor. Där anges vilka områden en viss användaragent får indexera och vilka den inte får.

Google beskriver robots.txt på ett mycket sakligt sätt: Filen anger för sökmotorernas sökrobotar vilka webbadresser de får hämta. Huvudsyftet är att styra sökrobotarnas trafik så att servrarna inte belastas i onödan. Den är inte avsedd att hindra webbplatser från att indexeras av Google.

Det låter kanske obetydligt, men det är halva jobbet. robots.txt är en regel för indexering. Den besvarar frågan: „Får den här boten hämta den här URL:en?“ Den besvarar inte automatiskt frågan: „Får den här URL:en visas i sökresultaten?“ Och den besvarar absolut inte frågan: „Är det här innehållet privat?“

Vad robots.txt inte gör

Det vanligaste misstaget är att förväxla inte indexera, inte indexera, visa inte och Använd inte. Det är olika mål.

  • Inte indexera: En bot ska inte hämta en URL. Det är det som robots.txt är till för.
  • Indexera inte: En URL ska inte visas i sökresultaten. För det behöver du vanligtvis inget index eller verkligt avstånd.
  • Att inte vara tillgänglig för allmänheten: Ett innehåll ska förbli privat. För det behöver du inloggning, lösenordsskydd, behörighetskontroll eller ett icke-offentligt arkiv.
  • Följande får inte användas för träning: Däremot har vissa leverantörer egna user-agent-tokens, till exempel GPTBot, ClaudeBot eller Google-Extended.
  • Visas inte i AI Search: Däremot spelar sökrobotar en viktig roll hos vissa leverantörer, till exempel OAI-SearchBot, Claude-SearchBot eller PerplexityBot.

Särskilt förrädiskt: Om du blockerar en sida via robots.txt kan Google, enligt sin egen dokumentation, ändå hitta URL:en om andra sidor länkar till den. Då kan URL:en i vissa fall visas i sökresultaten utan utdrag. Det är oftast inte vad webbplatsägare vill.

Om något verkligen inte ska vara offentligt hör det inte bara hemma i robots.txt. Då måste det skyddas av åtkomstkontroll. Punkt. robots.txt är en vägledning för artiga sökrobotar, inte ett säkerhetssystem.

Fyra fall som man måste skilja tydligt åt

För AI Visibility är det numera viktigare att skilja mellan olika botars syften än att titta på det enskilda botnamnet. I praktiken finns det fyra fall:

FallVad det handlar omEtt typiskt beslut
SökrobotInnehåll hämtas och länkas till sök- eller svarssidor.Tillåt oftast för offentligt tillgängligt, viktigt innehåll.
TräningscrawlerInnehåll kan samlas in för modellträning eller modellförbättring.Att fatta ett medvetet beslut är ofta mer begränsande än att söka.
Användarutlöst hämtningEn person ber ett AI-system att hämta en specifik URL eller källa.Blockera inte reflexmässigt, men skydda känsliga områden.
Verktygs-, revisions- eller produktcrawlerEn tjänst granskar, renderar, testar eller analyserar sidor på uppdrag av någon.Tillåt endast om syftet och källan är rimliga.

Det är just här som det 2026 blir mer intressant än tidigare. Tidigare var robots.txt för många WordPress-webbplatser framför allt en sekundär fråga inom SEO. Idag kan samma fil påverka om innehåll blir lättare att hitta i ChatGPT Search, Claude-sökning, Perplexity eller liknande funktioner, om det släpps för träning och om WAF:er av misstag blockerar legitima AI-botar.

Googlebot, Google-Extended och Google-CloudVertexBot

På Google är denna distinktion särskilt viktig, eftersom många debatter här förvånansvärt nog är otydliga.

Googlebot är Googles klassiska sökrobot för Google Search. Regler för Googlebot Enligt Google gäller detta Googles sökmotor, inklusive sökfunktioner, samt andra plattformar som Discover, Google Bilder, Google Video och Google Nyheter. Den som blockerar Googlebot generellt blockerar alltså inte „bara AI“, utan även den vanliga synligheten på Google.

Google-Extended är något annat. Enligt Google har Google-Extended ingen egen HTTP-user-agent. Crawlingen sker med befintliga Google-user-agents; Google-Extended är en robots.txt-token för styrning. Den är avsedd att göra det möjligt för publicister att kontrollera om innehåll som redan har indexerats av Google får användas för träning av framtida Gemini-modeller och för grounding i Gemini-appar och Vertex AI. Google skriver dessutom uttryckligen att Google-Extended varken påverkar indexeringen i Google Sök eller används som en rankningssignal i Google Sök.

Google Cloud VertexBot Enligt Googles dokumentation gäller detta genomsökningar som webbplatsägare initierar för att bygga Vertex AI-agenter. Inte heller detta påverkar Google Search. Om en organisation bygger egna agenter med Vertex AI kan den här boten vara relevant. För en vanlig WordPress-blogg är den i första hand inte den faktor som avgör synligheten på Google.

Det praktiska budskapet: Google är inte en enda AI-knapp. Googlebot, Google-Extended och Google-CloudVertexBot har olika betydelser. Den som av ren irritation stänger av allt på en gång påverkar samtidigt inställningarna för klassisk sökning, bilder, nyheter, användningen av Gemini och agentarbetsflöden. Det är inget man bör göra i förbigående.

OpenAI: OAI-SearchBot, GPTBot och ChatGPT-användare

OpenAI gör en relativt tydlig åtskillnad mellan olika syften i sin egen dokumentation om webbcrawlaren.

  • OAI-SearchBot: för ChatGPT Search. Enligt OpenAI kan den som blockerar denna bot uteslutas från ChatGPT:s söksvar, även om det fortfarande kan vara möjligt att använda navigeringslänkarna.
  • GPTBot: för innehåll som kan användas för träning av generativa grundmodeller. En ”Disallow”-regel för GPTBot anger att innehållet inte ska användas för träning.
  • ChatGPT-användare: för vissa användaråtgärder i ChatGPT och anpassade GPT:er. Dessa förfrågningar utlöses av användaren och utgör inte automatisk webbindexering. OpenAI påpekar därför att robots.txt-reglerna inte alltid gäller i detta sammanhang.

Det här är en ganska viktig distinktion för webbplatsägare. Du kan till exempel säga: ”Jag vill kunna hittas i ChatGPT Search, men jag vill inte dela mitt innehåll för träning.” Då skulle ett möjligt exempel kunna se ut så här: OAI-SearchBot tillåta, GPTBot blockera. Om det är strategiskt rätt beror på din webbplats, ditt innehåll och din inställning till risk. Men det är åtminstone ett välgrundat beslut.

Vad du bör undvika: att blockera alla OpenAI-användaragenter i ett svep och sedan undra varför din offentliga expertis inte dyker upp i ChatGPT Search. Man kan inte samtidigt säga „Snälla, hitta mig“ och „Snälla, hämta aldrig information om mig“ och förvänta sig att det ska leda till tillförlitlig synlighet.

Claude, Perplexity och andra AI-crawlers

Anthropic beskriver även flera botar för Claude: ClaudeBot för modellträning respektive modellförbättring, Claude-SearchBot för sökkvalitet och Claude-användare för användarstyrda sökningar. Enligt Anthropic kan blockering av Claude-SearchBot minska synligheten och noggrannheten i Claudes sökresultat. Att blockera ClaudeBot innebär däremot att framtida innehåll inte ska inkluderas i träningsdatauppsättningarna.

Perplexity skiljer åt PerplexityBot för Search och Perplexity-användare för användaråtgärder. Dessutom påpekar Perplexity att WAF-regler inte bara bör kontrollera User-Agent-strängar på ett mekaniskt sätt, utan helst även ta hänsyn till officiella IP-intervall. Det är en detalj, men en viktig sådan: vem som helst kan påstå sig ha en viss User-Agent-sträng. För seriös botkontroll räcker det inte med snygga namn i loggen.

Och sedan finns det många fler typer av botar: SEO-verktyg, övervakningstjänster, förhandsgranskningsbotar, sociala botar, säkerhetsskannrar, bedrägliga skrapare, interna sökrobotar och webbhotellskontroller. Inte alla botar med „AI“ i namnet är strategiskt viktiga. Inte alla okända botar är ofarliga. Uppgiften är alltså inte att lära sig en gigantisk lista utantill, utan att tydligt formulera sina egna mål.

Innehållssignaler istället för reflexblockering

AI Visibility handlar inte bara om vem som får genomsöka webbplatsen. Det handlar också om vad ett system hittar när det genomsöker webbplatsen. En webbplats kan vara tekniskt öppen men ändå svår att förstå. Då är den som en butik med öppen dörr, men utan skyltar, prislappar och belysning. Mycket lättillgänglig, men inte särskilt hjälpsam.

Google skriver i sin egen guide om generativ AI-sökning att grundläggande SEO-arbete fortfarande är viktigt: användbart, unikt och välorganiserat innehåll som inte bara återanvänder det som redan finns överallt. Det är just där nyckeln ligger. AI-system behöver inte bara tillgång till information, utan också användbara signaler.

  • Tydlig sidstruktur: Tydliga rubriker, meningsfulla underrubriker, överskådliga stycken.
  • Rena enheter: Vem är personen, organisationen, varumärket, tjänsten eller produkten?
  • Citatvärda uttalanden: konkreta svar, tydliga definitioner, data, exempel och gränser.
  • Aktualitet: tydliga uppgifter om publicering och ändringar, uppdaterat innehåll, inga föråldrade guider från 2018.
  • Schema-data: inte som någon slags ”rankingmagi”, utan som en maskinläsbar koppling mellan innehåll, författare och organisation samt produkt.
  • Webbkartor: så att viktigt innehåll förblir lätt att hitta och inte försvinner i arkivets virrvarr.
  • Interna länkar: Kluster, pelare, vanliga frågor, produktsidor och rådgivare ska förklara varandra.
  • Maskinläsbara versioner: llms.txt, Markdown eller andra förenklade versioner kan ge sammanhang. De ersätter dock inte åtkomstpolicyn.

Det är också en länk till den föregående artikeln om Schema, entiteter och citerbart innehåll. Om en sökrobot får indexera men bara hittar motstridiga signaler, är vinsten liten. Om den får indexera och hittar tydliga signaler blir åtkomsten åtminstone en möjlighet som går att utnyttja.

Checklista för WordPress

För WordPress-webbplatser skulle jag gå tillväga på följande pragmatiska sätt:

  1. Fastställa offentliga mål: Vilket innehåll ska kunna hittas i Google, ChatGPT Search, Claude, Perplexity och andra svarssystem?
  2. Att verkligen skydda privat innehåll: Kunduppgifter, interna dokument, staging-miljöer och nedladdningar som inte har godkänts ska skyddas med inloggning eller lösenord, inte bara i robots.txt.
  3. Besluta separat om träningen: Vill du tillåta, blockera eller hantera träningscrawlers på olika sätt?
  4. Se till att inte av misstag blockera sökrobotar: Om AI-sökning är ett mål, kontrollera om sökrobotar som OAI-SearchBot, Claude-SearchBot eller PerplexityBot är tillgängliga.
  5. Skada inte Googlebot: Blockera inte Googlebot generellt om det är viktigt att webbplatsen syns normalt på Google.
  6. Blockera inte CSS, JavaScript och bilder i onödan: Om en sida blir svår att förstå utan resurser försvårar du också den automatiska klassificeringen.
  7. inget index använda på ett målinriktat sätt: Taggarkiv, tunna söksidor, interna tack-sidor och duplicerat innehåll bör helst märkas med noindex på ett ordentligt sätt, snarare än att halvhjärtat döljas via robots.txt.
  8. Kontrollera webbkartor: Finns viktiga inlägg, sidor, produkter, kategorier och medier med på rätt sätt? Har oviktiga delar tagits bort?
  9. Kontrollera schemat: Finns det flera SEO-plugins, webbutiks-plugins eller AI-plugins som genererar konkurrerande JSON-LD-grafer?
  10. Övervaka loggar: Vilka bots kommer verkligen fram? Vilka blockeras av brandvägg, cache, säkerhetsplugin eller webbhotellets regler?
  11. llms.txt och Markdown: Använd dem som ett sammanhangs- och orienteringslager, inte som en rättighetshantering.
  12. Dokumentera ändringar: Reglerna i robots.txt kan påverka synligheten. Därför hör de hemma i en ändringslogg, inte i ett spontant infall en fredagskväll.

Ett bra exempel på en robots.txt-fil

Det här är inget standardmanus som man kan kopiera rakt av, utan snarare ett exempel som ska ge inspiration. För många webbplatser med rådgivning, tjänster eller produkter kan en differentierad struktur vara mer lämplig än att „öppna allt“ eller „stänga allt“.

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

Sitemap: https://example.com/sitemap_index.xml

Vad detta exempel visar: Traditionella sökrobotar och indexeringsrobotar får hitta offentligt tillgängligt innehåll. Tränings-tokens hanteras mer restriktivt. Om detta är rätt för din webbplats beror på vad du publicerar. En fotograf, ett juridiskt fackförlag, en SaaS-leverantör, en WooCommerce-butik och ett lokalt hantverksföretag har inte automatiskt samma bot-policy.

Det är också viktigt att notera att vissa leverantörer skiljer mellan automatisk genomsökning och användarutlösta hämtningar. Just därför är robots.txt inte det enda styrverktyget. WAF-regler, IP-verifiering, inloggningsskydd, frågor om samtycke och dataskydd, serverloggar och innehållsstrategi är också viktiga faktorer att ta hänsyn till.

Hur jag ser på citelayer®

Enligt min citelayer® AI-synlighetsgranskning-Ur det perspektivet är robots.txt bara en del av diagnosen. Jag vill inte bara veta om en bot teoretiskt sett har tillåtelse. Jag vill veta vad som händer i praktiken: Kommer relevanta bots fram? Blockeras de av brandväggsregler? Ser de rätt innehåll? Stämmer sitemap, schema, kanoniska länkar, interna länkar, llms.txt och synligt innehåll överens?

Just när det gäller WordPress ser jag ofta inte ett enda stort problem, utan många små motsägelser: SEO-pluginet säger A, butikspluginet säger B, säkerhetspluginet blockerar C, cachen levererar D, och i robots.txt finns fortfarande en gammal post från en sedan länge glömd migrering. Det är inget spektakulärt. Tyvärr är det just den här typen av röra som gör att automatisk klassificering misslyckas.

citelayer® för WordPress fyller just denna lucka mellan klassiska SEO-plugins och AI Visibility: maskinläsbara kontextlager, llms.txt, Schema-kontext, botsignaler och en bättre grund för granskningar. Men även här gäller: Ett plugin kan tillhandahålla struktur. Det strategiska beslutet om vilket innehåll som ska vara synligt, citerbart, skyddat eller undantaget från träningen förblir en redaktionell och affärsmässig fråga.

Vanliga frågor

Ska jag blockera alla AI-crawlers?

Det går inte att generalisera. Om du vill synas i AI Search bör du inte automatiskt blockera sökrobotar. Träningsrobotar kan du bedöma separat. Privat innehåll bör oavsett detta skyddas med en ordentlig åtkomstkontroll.

Är robots.txt juridiskt bindande?

robots.txt är en teknisk standard, eller snarare en konvention för sökrobotars beteende – det är varken ett säkerhetsskåp eller juridisk rådgivning. Seriösa sökrobotar följer reglerna. Andra kan välja att ignorera dem. Om juridiska frågor är viktiga behöver du dessutom en juridisk granskning och verkliga tekniska skyddsåtgärder.

Vad är skillnaden mellan GPTBot och OAI-SearchBot?

OpenAI beskriver GPTBot som en sökrobot för innehåll som kan användas för träning av generativa grundmodeller. OAI-SearchBot är däremot avsedd för ChatGPT Search. Du kan alltså i teorin tillåta sökningar och blockera träning.

Påverkar Google Extended min placering i Googles sökresultat?

Enligt Google: nej. Enligt Googles dokumentation påverkar Google Extended varken indexeringen i Google Sök eller rankningen i Google Sök. Det styr om innehåll som Google har genomsökt får användas för vissa Gemini- och Vertex AI-tillämpningar.

Ersätter llms.txt min robots.txt?

Nej. robots.txt styr reglerna för genomsökning. llms.txt är en vägledningslager för AI-system och agenter: viktiga sidor, sammanhang, sammanfattningar, maskinläsbara ingångspunkter. Det ena säger snarare „vart får du gå?“, det andra snarare „det här är viktigt“.

Varför ska jag kontrollera botloggarna?

Eftersom robots.txt bara visar vad du har för avsikt. Loggarna visar vad som verkligen händer: vilka botar som besöker sajten, vilka URL:er de hämtar, vilka statuskoder de får, vilka brandväggsregler som träder i kraft och vilket viktigt innehåll som aldrig nås.

Källor och verifiering

<span class="castledown-font">Saskia Teichmann</span>

Saskia Teichmann

Saskia Teichmann är certifierad AI-strateg (MMAI®) och fullstack webbutvecklare. Hon hjälper små och medelstora företag och industrin att integrera AI, GDPR, EU:s AI-förordning och modern webbteknik i en framtidssäker och rättssäker digital strategi.

För att uttrycka det enkelt:
Som teknisk verklighetsöversättare arbetar hon i gränssnittet mellan AI, webbutveckling och operativ verklighet. Hon utvecklar AI-stödda arbetsflöden för företag och byråer - med målet att se till att tekniken inte bara imponerar i demos, utan också fungerar i vardagen.

Skicka in en projektförfråganServera kaffe

0 kommentarer

Skicka en kommentar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *

Sändning