KI-crawlere, robots.txt og innholdssignaler

Per juni 2026. Når folk som driver nettsteder, hører om KI-crawlere, skjer ofte én av to ting: Enten blokkeres alt straks fordi «KI ikke bare skal få stjele alt». Eller alt forblir åpent fordi synlighet høres fint ut. Begge deler er for unyansert.

En bedre tilnærming er mindre dramatisk og langt mer nyttig: Forstå først hvilken bot som gjør hva. Søk, trening, brukerutløst henting, annonsekontroll, testverktøy og gjennomsøking som del av en gjennomgang er ikke det samme. Den som skjærer alt over én kam, mister enten synlighet unødvendig eller lar noe stå åpent som egentlig burde vært kontrollert.

Kortversjonen

• robots.txt styrer gjennomsøking, ikke automatisk synlighet. En blokkert URL kan likevel dukke opp i søkeresultater hvis eksterne sider lenker til den.
• robots.txt er ikke et personvernskjold. Privat innhold hører hjemme bak innlogging, passordbeskyttelse eller på ikke-offentlige systemer, ikke bare i en Disallow-regel.
• KI-crawlere har ulike oppgaver. Søkeboter, treningsboter og brukerutløste hentinger må vurderes hver for seg.
• Google-Extended er ikke en egen synlig crawler. Det er et styringstoken i robots.txt og gjelder ifølge Google Gemini-trening og grounding, ikke rangering i Google Search.
• Den som blokkerer søkeboter, kan miste KI-synlighet. Den som tillater treningsboter, tar en annen beslutning. Nettopp dette skillet er viktig.
• Innholdssignaler er fortsatt avgjørende. Tydelig innhold, god struktur, ryddige Schema-data, nettstedskart, interne lenker og maskinlesbare versjoner hjelper mer enn panisk botbingo.

Min anbefaling er å behandle robots.txt som et skilt på døren, ikke som en safe. For synlighet trenger du tilgjengelighet og gode signaler. For beskyttelse trenger du reell tilgangskontroll. Det er to forskjellige oppgaver.

Hva robots.txt faktisk gjør

Filen robots.txt ligger i rotmappen på nettstedet ditt, for eksempel på https://example.com/robots.txt. Seriøse crawlere leser den før de henter sider. Der står det hvilke områder en bestemt User-Agent kan gjennomsøke, og hvilke den ikke kan gjennomsøke.

Google beskriver robots.txt svært nøkternt: Filen forteller søkemotorenes crawlere hvilke URL-er de kan hente. Hovedformålet er å styre crawlertrafikken slik at serveren ikke belastes unødvendig. Den er ikke ment å holde nettsider ute av Google.

Det høres beskjedent ut, men avklarer mye. robots.txt er en regel for gjennomsøking. Den svarer på spørsmålet «Kan denne boten hente denne URL-en?» Den svarer ikke automatisk på «Kan denne URL-en vises i søkeresultater?» Og den svarer slett ikke på «Er dette innholdet privat?»

Hva robots.txt ikke gjør

Den vanligste feilen er å blande sammen ikke gjennomsøke, ikke indeksere, ikke vise og ikke bruke. Dette er forskjellige mål.

• Ikke gjennomsøke: En bot skal ikke hente en URL. Det er dette robots.txt er ment for.
• Ikke indeksere: En URL skal ikke vises i søkeresultater. Til det trenger du som regel noindex eller faktisk fjerning.
• Ikke være offentlig tilgjengelig: Innhold skal forbli privat. Til det trenger du innlogging, passordbeskyttelse, rettighetskontroll eller et ikke-offentlig lagringssted.
• Ikke brukes til trening: Enkelte leverandører har egne User-Agent-tokener til dette, for eksempel GPTBot, ClaudeBot eller Google-Extended.
• Ikke vises i AI Search: Hos noen leverandører er søkeboter relevante for dette, for eksempel OAI-SearchBot, Claude-SearchBot eller PerplexityBot.

Særlig lett å overse er dette: Selv om du blokkerer en side med robots.txt, kan Google ifølge egen dokumentasjon likevel finne URL-en hvis andre sider lenker til den. Da kan URL-en dukke opp i søkeresultatene uten tekstutdrag. Det er som regel ikke det de som driver nettstedet, ønsket.

Hvis noe virkelig ikke skal være offentlig, holder det ikke å plassere det i robots.txt. Da må det ligge bak tilgangskontroll. Punktum. robots.txt er en beskjed til høflige crawlere, ikke et sikkerhetssystem.

Fire tilfeller som må skilles tydelig fra hverandre

For AI Visibility er skillet mellom botenes formål nå viktigere enn det enkelte botnavnet. I praksis finnes det fire tilfeller:

Tilfelle	Hva det handler om	Typisk beslutning
Søkecrawler	Innhold blir funnet og lenket til i søke- eller svargrensesnitt.	Som regel tillate for viktig, offentlig innhold.
Treningscrawler	Innhold kan samles inn for å trene eller forbedre modeller.	Ta en bevisst beslutning, ofte mer restriktiv enn for søk.
Brukerutløst henting	Et menneske ber et KI-system hente en bestemt URL eller kilde.	Ikke blokkere på refleks, men beskytte sensitive områder.
Verktøy-, audit- eller produktcrawler	En tjeneste kontrollerer, gjengir, tester eller analyserer sider på oppdrag.	Bare tillate når formålet og kilden er troverdige.

Det er nettopp her det i 2026 blir mer interessant enn tidligere. Før var robots.txt for mange WordPress-nettsteder først og fremst et sidespor i SEO-arbeidet. I dag kan den samme filen påvirke om innhold blir lettere å finne i ChatGPT Search, Claude-søk, Perplexity eller Gemini-relaterte funksjoner, om det åpnes for trening, og om WAF-er utilsiktet stenger legitime KI-boter ute.

Googlebot, Google-Extended og Google-CloudVertexBot

Hos Google er skillet særlig viktig, fordi mange debatter om dette er overraskende upresise.

Googlebot er den tradisjonelle Google-crawleren for Google Search. Regler for Googlebot gjelder ifølge Google Google-søk, inkludert søkefunksjoner, og andre flater som Discover, Google Images, Google Video og Google News. Den som blokkerer Googlebot generelt, blokkerer altså ikke «bare KI», men også vanlig synlighet i Google.

Google-Extended er noe annet. Ifølge Google har Google-Extended ingen egen HTTP-User-Agent. Gjennomsøkingen skjer med eksisterende Google-User-Agents; Google-Extended er et styringstoken i robots.txt. Det skal gi publisister kontroll over om innhold Google allerede har gjennomsøkt, kan brukes til å trene framtidige Gemini-modeller og til grounding i Gemini Apps og Vertex AI. Google skriver dessuten uttrykkelig at Google-Extended verken påvirker inkludering i Google Search eller brukes som rangeringssignal i Google Search.

Google-CloudVertexBot gjelder ifølge Googles dokumentasjon gjennomsøking som nettstedeiere starter for å bygge Vertex AI-agenter. Heller ikke dette påvirker Google Search. Hvis en organisasjon bygger egne agenter med Vertex AI, kan denne boten være relevant. For en vanlig WordPress-blogg er den i utgangspunktet ikke bryteren som avgjør synligheten i Google.

Det praktiske poenget er at Google ikke er én enkelt KI-bryter. Googlebot, Google-Extended og Google-CloudVertexBot betyr forskjellige ting. Den som stenger alt i irritasjon, tar samtidig beslutninger om tradisjonelle søk, bilder, nyheter, Gemini-bruk og agentarbeidsflyter. Det bør ikke gjøres i forbifarten.

OpenAI: OAI-SearchBot, GPTBot og ChatGPT-User

OpenAI skiller forholdsvis tydelig mellom formålene i sin egen crawlerdokumentasjon.

• OAI-SearchBot: for ChatGPT Search. Den som blokkerer denne boten, kan ifølge OpenAI falle ut av ChatGPTs søkesvar, selv om navigasjonslenker fortsatt kan være mulige.
• GPTBot: for innhold som kan brukes til å trene generative grunnmodeller. En Disallow for GPTBot signaliserer at innholdet ikke skal brukes til trening.
• ChatGPT-User: for bestemte brukerhandlinger i ChatGPT og Custom GPTs. Disse hentingene er utløst av brukeren, ikke automatisk gjennomsøking av nettet. Derfor påpeker OpenAI at robots.txt-regler ikke alltid gjelder her.

Dette er et svært viktig skille for dem som driver nettsteder. Du kan for eksempel si: Jeg vil kunne finnes i ChatGPT Search, men jeg vil ikke stille innholdet mitt til rådighet for trening. Et mulig mønster ville da være å tillate OAI-SearchBot og blokkere GPTBot . Om det er strategisk riktig, avhenger av nettstedet, innholdet og risikovurderingen din. Men det er i det minste en presis beslutning.

Det du bør unngå, er å blokkere alle OpenAI-User-Agents i samme omgang og deretter undre deg over hvorfor den offentlige fagkunnskapen din ikke dukker opp i ChatGPT Search. Man kan ikke samtidig si «Vær så snill å finne meg» og «Vær så snill å aldri hente noe hos meg» og forvente pålitelig synlighet.

Claude, Perplexity og andre KI-crawlere

Anthropic beskriver også flere boter for Claude: ClaudeBot for trening eller forbedring av modeller, Claude-SearchBot for søkekvalitet og Claude-User for brukerutløste hentinger. Ifølge Anthropic kan blokkering av Claude-SearchBot redusere synlighet og nøyaktighet i Claudes søkeresultater. Blokkering av ClaudeBot signaliserer derimot at framtidig innhold ikke skal tas inn i treningsdatasett.

Perplexity skiller mellom PerplexityBot for søk og Perplexity-User for brukerhandlinger. Perplexity påpeker dessuten at WAF-regler ikke bare bør kontrollere User-Agent-strenger mekanisk, men helst også ta hensyn til offisielle IP-områder. Det er en detalj, men en viktig en: Hvem som helst kan oppgi en User-Agent-streng. Fine navn i loggen er ikke nok for seriøs botstyring.

Og så finnes det mange andre hentinger: SEO-verktøy, overvåkingstjenester, forhåndsvisningsboter, sosiale boter, sikkerhetsskannere, uredelige skrapere, interne crawlere og kontroller fra hostingleverandører. Ikke alle boter med «AI» i navnet er strategisk viktige. Ikke alle ukjente boter er harmløse. Oppgaven er derfor ikke å lære en gigantisk liste utenat, men å formulere egne mål tydelig.

Innholdssignaler i stedet for refleksblokkering

AI Visibility handler ikke bare om hvem som kan gjennomsøke. Det handler også om hva et system finner når det gjør det. Et nettsted kan være teknisk åpent og likevel vanskelig å forstå. Da er det som en butikk med åpen dør, men uten skilt, prislapper og lys. Svært tilgjengelig, svært lite nyttig.

I sin egen veiledning om generativ AI Search skriver Google at grunnleggende SEO-arbeid fortsatt teller: nyttig, unikt og godt organisert innhold som ikke bare resirkulerer det som allerede står overalt. Det er her muligheten ligger. KI-systemer trenger ikke bare tilgang, men signaler de kan bruke.

• Tydelig sidestruktur: beskrivende titler, fornuftige mellomtitler og forståelige avsnitt.
• Tydelige entiteter: Hvem er personen eller organisasjonen, og hvilken merkevare, tjeneste eller hvilket produkt er det snakk om?
• Utsagn som egner seg som kilder: konkrete svar, tydelige definisjoner, data, eksempler og begrensninger.
• Oppdatert innhold: synlige publiserings- og endringsdatoer, vedlikeholdt innhold, ingen zombieveiledninger fra 2018.
• Schema-data: ikke som rangeringsmagi, men som maskinlesbare forbindelser mellom innhold, forfatter, organisasjon og produkt.
• Nettstedskart: slik at viktig innhold forblir lett å finne og ikke forsvinner i et virvar av arkiver.
• Interne lenker: temaklynger, hovedsider, FAQ, produktsider og veiledninger skal forklare hverandre.
• Maskinlesbare versjoner: llms.txt, Markdown eller andre forenklede formater kan gi kontekst. Men de erstatter ikke regler for tilgang.

Dette er også forbindelsen til den forrige artikkelen om Schema, entiteter og innhold som kan brukes som kilde. Hvis en maskin kan gjennomsøke, men bare finner motstridende signaler, er lite vunnet. Hvis den kan gjennomsøke og finner ryddige signaler, blir tilgangen i det minste en mulighet det går an å bruke.

Sjekkliste for WordPress

For WordPress-nettsteder ville jeg gått praktisk til verks slik:

1. Avklar målene for offentlig innhold: Hvilket innhold skal kunne finnes i Google, ChatGPT Search, Claude, Perplexity og andre svarsystemer?
2. Beskytt privat innhold ordentlig: Kundedata, interne dokumenter, testmiljøer og nedlastinger som ikke er frigitt, hører hjemme bak innlogging eller passordbeskyttelse, ikke bare i robots.txt.
3. Ta en egen beslutning om trening: Vil du tillate treningscrawlere, blokkere dem eller behandle dem ulikt?
4. Ikke steng søkeboter ute ved et uhell: Hvis AI Search er et mål, kontroller om søkeboter som OAI-SearchBot, Claude-SearchBot eller PerplexityBot har tilgang.
5. Ikke hindre Googlebot: Ikke blokker Googlebot generelt hvis vanlig synlighet i Google er viktig.
6. Ikke blokker CSS, JavaScript og bilder unødvendig: Hvis en side er vanskelig å forstå uten ressursene sine, gjør du også maskinenes tolkning vanskeligere.
7. noindex bør brukes målrettet: Merk heller stikkordarkiver, tynne søkesider, interne takkesider og duplisert innhold ordentlig med noindex enn å gjemme dem halvhjertet med robots.txt.
8. Kontroller nettstedskartene: Er viktige innlegg, sider, produkter, kategorier og medier riktig tatt med? Er uviktige områder utelatt?
9. Kontroller Schema: Finnes det flere SEO-, nettbutikk- eller KI-utvidelser som leverer konkurrerende JSON-LD-grafer?
10. Følg med på loggene: Hvilke boter kommer faktisk? Hvilke blir blokkert av brannmuren, hurtigbufferen, sikkerhetsutvidelsen eller hostingreglene?
11. Sett llms.txt og Markdown i riktig sammenheng: Bruk dem som et lag for kontekst og orientering, ikke som rettighetsstyring.
12. Dokumenter endringer: robots.txt-regler kan påvirke synligheten. Derfor hører de hjemme i en endringslogg, ikke i et spontant innfall fredag kveld.

Et fornuftig eksempel på robots.txt

Dette er ikke et universalskript du skal kopiere, men et tankeeksempel. For mange offentlige nettsteder med veiledninger, tjenester eller produkter kan en differensiert struktur være mer fornuftig enn «alt åpent» eller «alt stengt».

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

Dette er det eksempelet uttrykker: Tradisjonell gjennomsøking og søkeboter får finne offentlig innhold. Treningstokener behandles mer restriktivt. Om det er riktig for nettstedet ditt, avhenger av hva du publiserer. En fotograf, et juridisk fagforlag, en SaaS-leverandør, en WooCommerce-butikk og en lokal håndverksbedrift har ikke automatisk samme regler for boter.

Det er også viktig at noen leverandører skiller mellom automatisk gjennomsøking og brukerutløste hentinger. Nettopp derfor er robots.txt ikke det eneste laget for styring. WAF-regler, IP-verifisering, innloggingsbeskyttelse, spørsmål om samtykke og personvern, serverlogger og innholdsstrategi må også være med i vurderingen.

Hvordan jeg tenker om dette med citelayer®

I arbeidet mitt med citelayer® AI Visibility Auditer robots.txt bare én del av diagnosen. Jeg vil ikke bare vite om en bot i teorien har lov. Jeg vil vite hva som skjer i praksis: Slipper relevante boter til? Blir de blokkert av brannmurregler? Ser de riktig innhold? Stemmer nettstedskart, Schema, kanoniske URL-er, interne lenker, llms.txt og synlig innhold overens?

Særlig i WordPress ser jeg ofte ikke ett stort problem, men mange små motsetninger: SEO-utvidelsen sier A, nettbutikkutvidelsen sier B, sikkerhetsutvidelsen blokkerer C, hurtigbufferen leverer D, og i robots.txt står det fortsatt en gammel oppføring fra en for lengst glemt migrering. Det er ikke spektakulært. Dessverre er det akkurat den typen rot som gjør at maskinenes tolkning svikter.

citelayer® for WordPress fyller nettopp dette gapet mellom en tradisjonell SEO-utvidelse og AI Visibility: maskinlesbare kontekstlag, llms.txt, Schema-kontekst, botsignaler og et bedre grunnlag for gjennomganger. Men også her gjelder det at en utvidelse kan levere struktur. Den strategiske beslutningen om hvilket innhold som skal være synlig, egnet som kilde, beskyttet eller unntatt fra trening, forblir redaksjonell og forretningsmessig.

FAQ

Bør jeg blokkere alle KI-crawlere?

Ikke generelt. Hvis du vil være synlig i AI Search, bør du ikke stenge søkecrawlere ute på refleks. Treningscrawlere kan du vurdere separat. Uansett hører privat innhold hjemme bak reell tilgangskontroll.

Er robots.txt juridisk bindende?

robots.txt er en teknisk standard eller konvensjon for crawleratferd, ikke en safe og ikke juridisk rådgivning. Seriøse crawlere respekterer reglene. Andre kan ignorere dem. Hvis juridiske spørsmål er viktige, trenger du i tillegg en juridisk vurdering og reelle tekniske beskyttelsestiltak.

Hva er forskjellen mellom GPTBot og OAI-SearchBot?

OpenAI beskriver GPTBot som en crawler for innhold som kan brukes til å trene generative grunnmodeller. OAI-SearchBot er derimot laget for ChatGPT Search. Du kan altså i teorien tillate søk og blokkere trening.

Påvirker Google-Extended rangeringen min i Google?

Ifølge Google, nei. Etter Googles dokumentasjon påvirker Google-Extended verken inkludering i Google Search eller rangering i Google Search. Det styrer om innhold Google har gjennomsøkt, kan brukes til bestemte formål i Gemini og Vertex AI.

Erstatter llms.txt robots.txt?

Nei. robots.txt styrer regler for gjennomsøking. llms.txt er et orienteringslag for KI-systemer og agenter: viktige sider, kontekst, oppsummeringer og maskinlesbare inngangspunkter. Det ene sier snarere «hvor kan du gå?», det andre snarere «dette er viktig her».

Hvorfor bør jeg undersøke botlogger?

Fordi robots.txt bare viser hensikten din. Loggene viser hva som faktisk skjer: Hvilke boter kommer, hvilke URL-er henter de, hvilke statuskoder får de, hvilke brannmurregler slår inn, og hvilket viktig innhold blir aldri nådd?

Kilder og verifisering

• Google Search Central: Introduction to robots.txt og begrensningene ved robots.txt.
• Google Crawling Infrastructure: Google’s common crawlers, særlig Googlebot, Google-CloudVertexBot og Google-Extended.
• Google Search Central: Optimizing for generative AI features on Google Search.
• OpenAI: Overview of OpenAI Crawlers med OAI-SearchBot, GPTBot og ChatGPT-User.
• Anthropic Help Center: Does Anthropic crawl data from the web? med ClaudeBot, Claude-SearchBot og Claude-User.
• Perplexity Docs: Perplexity Crawlers med PerplexityBot og Perplexity-User.
• Egen audit- og utvidelsespraksis med citelayer®: tilbakevendende mønstre fra WordPress-gjennomganger, undersøkelser av botlogger, Schema-/llms.txt-kompatibilitet og tester av AI Visibility. Disse observasjonene brukes i artikkelen som vurderinger fra praksis, ikke som en ekstern primærkilde.