Slik skriver du en robots.txt som faktisk blokkerer KI-skrapere

Den ubehagelige sannheten om robots.txt

En robots.txt-fil er ikke en lås. Den er et skilt på døren.

Det skillet er viktig når team spør om de kan «blokkere KI-skrapere» med én liten tekstfil. For seriøse crawlere som følger Robots Exclusion Protocol, ja: en korrekt skrevet robots.txt kan fortelle dem at de ikke skal crawle sidene dine. For ukjente skrapere, etterlignere, nettleserautomatisering og roboter som ganske enkelt ikke bryr seg, gjør den ingenting alene.

Det praktiske målet er derfor ikke «gjør skraping umulig». Det er:

• Fortell etterlevende KI-crawlere at de ikke skal bruke nettstedet ditt.
• Unngå å blokkere søkemotorer eller nyttige tjenester ved et uhell.
• Legg til sterkere serversidekontroller mot misbruk.
• Hold policyen vedlikeholdbar når crawler-navn endrer seg.

Det er den kjedelige versjonen. Det er også versjonen som fungerer.

Hva robots.txt kan og ikke kan gjøre

En robots.txt-fil ligger i roten av et nettsted:

https://example.com/robots.txt

Crawlere ber om den før de crawler. Filen inneholder grupper med regler. Hver gruppe starter med én eller flere User-agent-linjer, etterfulgt av Allow- eller Disallow-direktiver.

En enkel blokkering av hele nettstedet ser slik ut:

User-agent: GPTBot
Disallow: /

Det betyr: Hvis du er GPTBot, ikke crawl noe på dette nettstedet.

Men robots.txt har tydelige begrensninger:

1. Den er frivillig. Ondsinnede aktører kan ignorere den.
2. Den hindrer ikke at en URL blir forespurt av en vanlig nettleser eller et skript.
3. Den fjerner ikke innhold som allerede er samlet inn andre steder.
4. Den definerer ikke opphavsrett, lisensiering eller treningsrettigheter i seg selv.
5. Den kan feilkonfigureres på måter som blokkerer feil roboter.

Hvis du trenger reell tilgangskontroll, bruk autentisering, autorisasjon, hastighetsbegrensning, IP-baserte kontroller, robothåndtering eller juridiske virkemidler. Robots.txt er fortsatt nyttig, men den hører hjemme i en bredere strategi for innholdsbeskyttelse.

Dette ligner andre styringsproblemer på nettet: Den synlige kontrollen er sjelden hele kontrollen. Hvis organisasjonen din allerede har ukontrollert KI-bruk internt, gjelder samme prinsipp; en rask shadow AI audit er ofte mer nyttig enn å late som om ett enkelt policydokument løser problemet.

Start med policybeslutningen

Før du redigerer filen, bestem hva du faktisk prøver å blokkere.

Det finnes minst fire ulike ting folk mener med «KI-skraper»:

• Crawlere som brukes til å samle inn treningsdata.
• Crawlere for KI-søk eller svarmotorer.
• Brukerutløste hentere, for eksempel når noen ber et KI-produkt om å oppsummere en URL.
• Generiske skrapere som later som om de er vanlige nettlesere.

Du vil kanskje blokkere alle. Eller du vil kanskje ha synlighet i søk, samtidig som du reserverer deg mot modelltrening. Dette er ikke samme policy.

OpenAI dokumenterer for eksempel separate user agents for ulike formål, inkludert GPTBot, ChatGPT-User og OAI-SearchBot. Google bruker Google-Extended som et kontrolltoken for noen Gemini- og Vertex AI-bruksområder, mens vanlig crawling for Google Search håndteres av andre Googlebot-user agents.

Dette skillet er viktig. Hvis du blokkerer brede user agents uforsiktig, kan du skade vanlig søkesynlighet mens du prøver å blokkere KI-trening.

En rimelig robots.txt-mal for KI-blokkering

Her er et konservativt utgangspunkt for å blokkere flere vanlig dokumenterte KI-relaterte crawlere, samtidig som generelle søkecrawlere får være i fred:

# AI training and AI product crawlers
User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: OAI-SearchBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Claude-Web
Disallow: /

User-agent: PerplexityBot
Disallow: /

User-agent: Amazonbot
Disallow: /

User-agent: Bytespider
Disallow: /

User-agent: Meta-ExternalAgent
Disallow: /

# Default rule for other crawlers
User-agent: *
Allow: /

Dette er ikke en magisk, universell liste. Det er et vedlikeholdbart mønster.

Noen merknader:

• Disallow: / betyr «ikke crawl noen sti».
• User-agent: * gjelder crawlere som ikke matches av en mer spesifikk gruppe.
• Allow: / er ikke strengt nødvendig for standardgruppen, men det gjør intensjonen din tydelig.
• Hold kommentarer korte. Noen parsere er tilgivende, men robots.txt bør forbli kjedelig.
• Ikke legg private URL-er i robots.txt. Filen er offentlig, og å liste sensitive stier kan gjøre dem kjent.

Det siste punktet er verdt å gjenta. Robots.txt er ikke en mekanisme for hemmelighold. Hvis /client-contracts/ ikke skal være offentlig, beskytt den med autentisering. Ikke bare nekt den i robots.txt.

Vær forsiktig med Google-Extended

Google-Extended blir ofte misforstått. Det er ikke det samme som å blokkere Google Search.

Ifølge Googles dokumentasjon er Google-Extended et frittstående produkttoken som utgivere kan bruke til å styre om nettstedsinnhold kan bidra til å forbedre visse Gemini- og Vertex AI-funksjoner. Å blokkere det skal ikke i seg selv hindre Googlebot i å crawle for Search.

Når det er sagt, ikke erstatt alle Google-direktiver med en bred blokkering som dette med mindre du virkelig mener det:

User-agent: Googlebot
Disallow: /

Det ville fortelle Google Searchs hovedcrawler at den ikke skal crawle nettstedet ditt. For de fleste offentlige nettsteder er det ikke det du ønsker.

Det samme skillet gjelder andre steder. Noen leverandører skiller treningscrawlere fra brukerutløst nettlesing eller crawlere for KI-søk. Andre gjør det ikke. Du må lese dokumentasjonen for robotene du bryr deg om, og behandle robots.txt som en levende fil, ikke en engangsavkrysning.

Test filen som produksjonskode

Robots.txt ser enkel ut, og derfor er den lett å ødelegge.

Vanlige feil inkluderer:

• Å laste den opp til feil sted, for eksempel /assets/robots.txt i stedet for /robots.txt.
• Å bruke typografiske anførselstegn kopiert fra et dokumentredigeringsprogram.
• Å blokkere alle crawlere med User-agent: * og Disallow: / ved et uhell.
• Å anta at én domenefil gjelder for et annet underdomene.
• Å glemme at http://, https://, www og verter uten www kan håndteres forskjellig avhengig av oppsettet ditt.

For nettsteder med flere domener, sjekk hver kanoniske vert. En robots-fil på https://www.example.com/robots.txt styrer ikke automatisk https://app.example.com/robots.txt.

Når du feilsøker, inspiser den faktiske HTTP-responsen, ikke bare det CMS-forhåndsvisningen viser. Du vil ha en 200 OK-respons, innholdstype text/plain hvis mulig, og nøyaktig filen du forventer. Hvis omdirigeringer, mellomlagring eller CDN-regler er involvert, hjelper det å inspisere rå headere. Arbeidsflyten i feilsøking av omdirigeringer og HTTP-headere i produksjon gjelder direkte her.

Legg til serversidekontroller for roboter som ignorerer reglene

Hvis crawleren etterlever reglene, er robots.txt det reneste signalet. Hvis crawleren misbruker tilgangen, trenger du håndheving.

Praktiske kontroller inkluderer:

Hastighetsbegrensning

Sett terskler for uvanlige forespørselsmønstre: for mange sider per minutt, dyp gjennomgang av paginering, gjentatte 404-feil eller høyt forespørselsvolum fra et lite sett IP-er. Hastighetsgrenser bør være romslige nok til ikke å straffe ekte brukere og strenge nok til å gjøre masseuthenting kostbart.

Filtrering av user agent

Du kan blokkere dokumenterte user agents for KI-crawlere på webserveren, i en reverse proxy, i CDN-et eller på applikasjonslaget. Dette er sterkere enn robots.txt fordi det returnerer et faktisk avslagssvar.

Nginx kan for eksempel blokkere et user agent-mønster, selv om produksjonsregler bør testes nøye:

if ($http_user_agent ~* "GPTBot|CCBot|ClaudeBot|Bytespider") {
    return 403;
}

Dette er ikke idiotsikkert. User-agent-strenger er enkle å forfalske. Men det stopper den ærlige eller late trafikken og reduserer belastningen.

IP- og ASN-kontroller

Noen operatører publiserer IP-områder, men mange skraperøkosystemer gjør det ikke. IP-basert blokkering kan fungere mot åpenbart misbruk, særlig fra skyvertsområder uten normal brukertrafikk, men det kan også skape falske positiver. Bruk logger før regler.

Autentisering og betalingsmurer

Hvis innhold ikke skal kopieres i stor skala, ikke legg hele innholdet på en offentlig URL. Robots.txt er uegnet for konfidensielt materiale, lisensierte databaser, private fellesskap eller betalte arkiver.

Innholdsminimering

Noen ganger er den beste beskyttelsen arkitektonisk. Ikke eksponer unødvendige API-er, store JSON-nyttelaster, skjulte metadata, utkast-endepunkter eller fulle arkiver hvis den offentlige siden bare trenger et lite utvalg. Bildetunge nettsteder bør også tenke gjennom hvilke metadata de publiserer; personvernslogikken i å fjerne EXIF-metadata før du deler bilder på nettet gjelder også for innholdsdrift.

Bruk robots meta tags for regler på sidenivå

Robots.txt styrer crawling. Robots meta tags og X-Robots-Tag-headere styrer indeksering og snippet-atferd for etterlevende søkemotorer og crawlere.

For eksempel:

<meta name="robots" content="noindex, noarchive">

Eller som en HTTP-header:

X-Robots-Tag: noindex, noarchive

Dette er ikke KI-spesifikke skjold. De er nyttige når du vil at en side skal være tilgjengelig, men ikke indeksert. Men hvis du blokkerer en crawler fra å hente en side i robots.txt, kan det hende den aldri ser meta-taggen på sidenivå. Ikke stol på en noindex-tagg på en URL som crawleren er forbudt å crawle.

Den grove regelen:

• Bruk robots.txt for å redusere eller forhindre crawling.
• Bruk meta robots eller X-Robots-Tag for å styre indekseringsatferd.
• Bruk serversidekontroller for å håndheve tilgang.

Overvåk logger etter publisering

Å publisere filen er bare første steg. Etterpå må du sjekke loggene.

Se etter:

• Forespørsler til /robots.txt fra user agents du har navngitt.
• Fortsatt crawling etter at disallow-regler er levert.
• Mistenkelige user agents med høyt volum.
• Nettleserlignende user agents som ber om tusenvis av sider i rekkefølge.
• Gjentatt tilgang til feeder, sitemaps, søkesider og paginering.

Hvis en robot ber om robots.txt, ser en full disallow og deretter stopper, gjorde robots.txt jobben sin. Hvis den fortsetter, flytt den roboten over til håndheving: hastighetsgrenser, blokkeringer eller autentisering.

Gå også gjennom eksponeringen av sitemapene dine. Sitemaps er nyttige for søkemotorer, men de er også praktiske kart for skrapere. Det betyr ikke at du bør fjerne dem fra vanlige nettsteder. Det betyr at du ikke bør inkludere URL-er du ikke vil at offentlige systemer skal oppdage.

Hold filen liten og gjennomgått

Robots.txt har en tendens til å råtne. Et markedsføringsteam legger til et kampanjemikronettsted. En utvikler legger til en staging-sti. En leverandør endrer crawler-navnet sitt. To år senere vet ingen hvorfor halvparten av reglene finnes.

Behandle den som konfigurasjon:

• Lagre den i versjonskontroll når det er mulig.
• Legg til en kort kommentar for hver KI-crawlergruppe.
• Gå gjennom den kvartalsvis.
• Sjekk leverandørdokumentasjon før du legger til brede regler.
• Test etter endringer i CDN, CMS eller hosting.

Hvis nettstedet ditt publiserer KI-assistert innhold, bør du også skille crawler-policy fra redaksjonell åpenhet. Blokkering av KI-skrapere handler om tilgang og gjenbruk. Merking handler om lesertillit. De overlapper etisk, men de er ikke samme kontroll. En praktisk tilnærming til merking er omtalt i hvordan ærlig KI-merking ser ut på et lite nettsted.

<!-- tool-cta:start -->

💡 Prøv dette: Etter at du har lagt til regler for AI-crawlere, bekreft syntaksen med Robots.txt Tester slik at du ikke ved et uhell også blokkerer legitime boter.

<!-- tool-cta:end -->

Kort oppsummert

En god robots.txt-fil vil blokkere etterlevende KI-crawlere. Den vil ikke stoppe målrettet skraping, kopierte user-agent-strenger, kompromitterte nettlesere eller folk som limer inn innholdet ditt manuelt i KI-systemer.

Det gjør den ikke ubrukelig. Det gjør den til ett lag.

Skriv eksplisitte regler for dokumenterte KI-crawlere. Unngå brede blokkeringer som skader søkesynlighet. Test den serverte filen, ikke utkastet. Følg med i logger. Håndhev med serversidekontroller der atferd går fra uønsket til misbruk.

Nettet har alltid fungert på en blanding av protokoll, normer og håndheving. Robots.txt er normlaget. Bruk den, men ikke forveksle den med en vegg.