Sådan skriver du en robots.txt, der faktisk blokerer AI-scrapere

Den ubehagelige sandhed om robots.txt

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

Den forskel betyder noget, når teams spørger, om de kan “blokere AI-scrapere” med én lille tekstfil. For velrenommerede crawlere, der følger Robots Exclusion Protocol, er svaret ja: En korrekt skrevet robots.txt kan fortælle dem, at de ikke må crawle dine sider. For ukendte scrapere, efterlignere, browserautomatisering og bots, der ganske enkelt er ligeglade, gør den intet i sig selv.

Så det praktiske mål er ikke “gør scraping umuligt”. Det er:

• Fortæl compliant AI-crawlere, at de ikke må bruge dit site.
• Undgå ved et uheld at blokere søgemaskiner eller nyttige tjenester.
• Tilføj stærkere server-side kontroller mod misbrug.
• Hold politikken vedligeholdelig, efterhånden som crawlernavne ændrer sig.

Det er den kedelige version. Det er også den version, der virker.

Hvad robots.txt kan og ikke kan gøre

En robots.txt-fil ligger i roden af et site:

https://example.com/robots.txt

Crawlere henter den, før de crawler. Filen indeholder grupper af regler. Hver gruppe starter med en eller flere User-agent-linjer efterfulgt af Allow- eller Disallow-direktiver.

En simpel blokering af hele sitet ser sådan ud:

User-agent: GPTBot
Disallow: /

Det betyder: Hvis du er GPTBot, så crawl ikke noget på dette site.

Men robots.txt har klare begrænsninger:

1. Den er frivillig. Ondsindede aktører kan ignorere den.
2. Den forhindrer ikke, at en URL bliver hentet af en almindelig browser eller et script.
3. Den fjerner ikke indhold, der allerede er indsamlet andre steder.
4. Den definerer ikke i sig selv ophavsret, licensering eller træningsrettigheder.
5. Den kan fejlkonfigureres på måder, der blokerer de forkerte bots.

Hvis du har brug for egentlig adgangskontrol, skal du bruge autentificering, autorisation, rate limiting, IP-baserede kontroller, bot management eller juridiske kontroller. Robots.txt er stadig nyttig, men den hører hjemme i en bredere strategi for indholdsbeskyttelse.

Det ligner andre governance-problemer på nettet: Den synlige kontrol er sjældent hele kontrollen. Hvis din organisation allerede har uadministreret AI-brug internt, gælder samme princip; en hurtig shadow AI-audit er ofte mere nyttig end at lade som om, at ét enkelt politikdokument løser problemet.

Start med din politiske beslutning

Før du redigerer filen, skal du beslutte, hvad du faktisk prøver at blokere.

Der er mindst fire forskellige ting, folk mener med “AI-scraper”:

• Crawlere, der bruges til at indsamle træningsdata.
• AI-søge- eller svarmotor-crawlere.
• Brugerudløste fetchere, for eksempel når nogen beder et AI-produkt om at opsummere en URL.
• Generiske scrapere, der foregiver at være almindelige browsere.

Du vil måske blokere dem alle. Eller du vil måske have søgesynlighed, men fravælge modeltræning. Det er ikke den samme politik.

For eksempel dokumenterer OpenAI separate user agents til forskellige formål, herunder GPTBot, ChatGPT-User og OAI-SearchBot. Google bruger Google-Extended som en kontroltoken til visse Gemini- og Vertex AI-brugsscenarier, mens almindelig Google Search-crawling håndteres af andre Googlebot-user agents.

Den adskillelse er vigtig. Hvis du blokerer brede user agents uforsigtigt, kan du skade almindelig søgesynlighed, mens du forsøger at blokere AI-træning.

En rimelig robots.txt-skabelon til AI-blokering

Her er et konservativt udgangspunkt for at blokere flere almindeligt dokumenterede AI-relaterede crawlere, mens generelle søgecrawlere lades være:

# 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 universalliste. Det er et vedligeholdeligt mønster.

Et par noter:

• Disallow: / betyder “crawl ikke nogen sti”.
• User-agent: * gælder for crawlere, der ikke matches af en mere specifik gruppe.
• Allow: / er ikke strengt nødvendigt for standardgruppen, men det gør din intention tydelig.
• Hold kommentarer korte. Nogle parsere er tilgivende, men robots.txt bør forblive kedelig.
• Medtag ikke private URL’er i robots.txt. Filen er offentlig, og en liste over følsomme stier kan reklamere for dem.

Det sidste punkt er værd at gentage. Robots.txt er ikke en mekanisme til hemmeligholdelse. Hvis /client-contracts/ ikke bør være offentlig, så beskyt den med autentificering. Nøjes ikke med at disallowe den.

Vær forsigtig med Google-Extended

Google-Extended bliver ofte misforstået. Det er ikke det samme som at blokere Google Search.

Ifølge Googles dokumentation er Google-Extended en selvstændig produkttoken, som udgivere kan bruge til at styre, om siteindhold må hjælpe med at forbedre visse Gemini- og Vertex AI-funktioner. At blokere den bør ikke i sig selv blokere Googlebot fra at crawle til Search.

Når det er sagt, skal du ikke erstatte alle Google-direktiver med en bred blokering som denne, medmindre du virkelig mener det:

User-agent: Googlebot
Disallow: /

Det ville fortælle Google Searchs primære crawler, at den ikke må crawle dit site. For de fleste offentlige websites er det ikke det, du ønsker.

Den samme skelnen gælder andre steder. Nogle leverandører adskiller træningscrawlere fra brugerudløst browsing eller AI-søgecrawlere. Andre gør ikke. Du skal læse dokumentationen for de bots, du bekymrer dig om, og behandle din robots.txt som en levende fil, ikke som et engangsafkrydsningsfelt.

Test filen som produktionskode

Robots.txt ser simpel ud, og det er derfor, den er let at ødelægge.

Almindelige fejl omfatter:

• At uploade den til det forkerte sted, for eksempel /assets/robots.txt i stedet for /robots.txt.
• At bruge typografiske anførselstegn kopieret fra en dokumenteditor.
• At blokere alle crawlere med User-agent: * og Disallow: / ved et uheld.
• At antage, at én domænes fil gælder for et andet subdomæne.
• At glemme, at http://, https://, www og ikke-www-hosts kan håndteres forskelligt afhængigt af din opsætning.

For sites med flere domæner skal du tjekke hver kanonisk host. En robots-fil på https://www.example.com/robots.txt styrer ikke automatisk https://app.example.com/robots.txt.

Når du debugger, skal du inspicere den faktiske HTTP-respons, ikke kun det, din CMS-preview viser. Du vil have et 200 OK-svar, text/plain-content type hvis muligt, og præcis den fil, du forventer. Hvis redirects, caching eller CDN-regler er involveret, hjælper rå header-inspektion. Arbejdsgangen i debugging af redirects og HTTP-headere i produktion gælder direkte her.

Tilføj server-side kontroller for bots, der ignorerer reglerne

Hvis crawleren er compliant, er robots.txt det reneste signal. Hvis crawleren er misbrugende, har du brug for håndhævelse.

Praktiske kontroller omfatter:

Rate limiting

Sæt tærskler for usædvanlige request-mønstre: for mange sider pr. minut, dyb gennemgang af paginering, gentagne 404’er eller høj request-volumen fra et lille sæt IP’er. Rate limits bør være generøse nok til ikke at straffe rigtige brugere og stramme nok til at gøre masseudtræk dyrt.

User-agent-filtrering

Du kan blokere dokumenterede AI-crawler-user agents på webserver-, reverse proxy-, CDN- eller applikationslaget. Det er stærkere end robots.txt, fordi det returnerer et faktisk afslagssvar.

For eksempel kan Nginx blokere et user agent-mønster, selvom produktionsregler bør testes omhyggeligt:

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

Det er ikke idiotsikkert. User-agent-strenge er nemme at forfalske. Men det stopper den ærlige eller dovne trafik og reducerer belastningen.

IP- og ASN-kontroller

Nogle operatører offentliggør IP-intervaller, men mange scraper-økosystemer gør ikke. IP-baseret blokering kan fungere ved åbenlyst misbrug, især fra cloud-hosting-intervaller uden normal brugertrafik, men den kan også skabe falske positiver. Brug logs før regler.

Autentificering og paywalls

Hvis indhold ikke må kopieres i stor skala, skal du ikke lægge hele indholdet på en offentlig URL. Robots.txt er uegnet til fortroligt materiale, licenserede databaser, private communities eller betalte arkiver.

Indholdsminimering

Nogle gange er den bedste beskyttelse arkitektonisk. Eksponér ikke unødvendige API’er, store JSON-payloads, skjulte metadata, draft endpoints eller fulde arkiver, hvis den offentlige side kun har brug for et lille udsnit. Billedtunge sites bør også overveje, hvilke metadata de publicerer; privatlivslogikken i fjernelse af EXIF-metadata før deling af fotos online gælder også for indholdsoperationer.

Brug robots meta tags til regler på sideniveau

Robots.txt styrer crawling. Robots meta tags og X-Robots-Tag-headere styrer indeksering og snippet-adfærd for compliant søgemaskiner og crawlere.

For eksempel:

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

Eller som en HTTP-header:

X-Robots-Tag: noindex, noarchive

Det er ikke AI-specifikke skjolde. De er nyttige, når du vil have, at en side er tilgængelig, men ikke indekseret. Men hvis du blokerer en crawler fra at hente en side i robots.txt, ser den måske aldrig sidens meta tag. Stol ikke på et noindex-tag på en URL, som crawleren er forbudt at crawle.

Den grove regel:

• Brug robots.txt til at reducere eller forhindre crawling.
• Brug meta robots eller X-Robots-Tag til at styre indekseringsadfærd.
• Brug server-side kontroller til at håndhæve adgang.

Overvåg logs efter publicering

At publicere filen er kun første skridt. Derefter skal du tjekke dine logs.

Kig efter:

• Requests til /robots.txt fra de user agents, du har navngivet.
• Fortsat crawling efter disallow-regler er blevet serveret.
• Mistænkelige user agents med høj volumen.
• Browserlignende user agents, der requester tusindvis af sider i rækkefølge.
• Gentagen adgang til feeds, sitemaps, søgesider og paginering.

Hvis en bot requester robots.txt, ser et fuldt disallow og derefter stopper, gjorde robots.txt sit arbejde. Hvis den fortsætter, skal du flytte den bot over i håndhævelse: rate limits, blokeringer eller autentificering.

Gennemgå også din sitemap-eksponering. Sitemaps er nyttige for søgemaskiner, men de er også praktiske kort for scrapere. Det betyder ikke, at du bør fjerne dem fra almindelige sites. Det betyder, at du ikke bør medtage URL’er, som du ikke ønsker, at offentlige systemer skal opdage.

Hold filen lille og gennemgået

Robots.txt har en tendens til at forfalde. Et marketingteam tilføjer et kampagne-microsite. En udvikler tilføjer en staging-sti. En leverandør ændrer navnet på sin crawler. To år senere ved ingen, hvorfor halvdelen af reglerne findes.

Behandl den som konfiguration:

• Gem den i version control, når det er muligt.
• Tilføj en kort kommentar for hver AI-crawlergruppe.
• Gennemgå den kvartalsvist.
• Tjek leverandørdokumentation, før du tilføjer brede regler.
• Test efter ændringer i CDN, CMS eller hosting.

Hvis dit site publicerer AI-assisteret indhold, skal du også adskille crawlerpolitik fra redaktionel gennemsigtighed. Blokering af AI-scrapere handler om adgang og genbrug. Disclosure handler om læsernes tillid. De overlapper etisk, men de er ikke den samme kontrol. En praktisk disclosure-tilgang er dækket i hvordan ærlig AI-disclosure ser ud på et lille website.

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

💡 Prøv dette: Når du har tilføjet regler for AI-crawlere, skal du bekræfte syntaksen med Robots.txt Tester, så du ikke også kommer til at blokere legitime bots ved et uheld.

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

Konklusionen

En god robots.txt-fil vil blokere compliant AI-crawlere. Den vil ikke stoppe målrettet scraping, kopierede user-agent-strenge, kompromitterede browsere eller personer, der manuelt indsætter dit indhold i AI-systemer.

Det gør den ikke ubrugelig. Det gør den til ét lag.

Skriv eksplicitte regler for dokumenterede AI-crawlere. Undgå brede blokeringer, der skader søgesynlighed. Test den serverede fil, ikke kladden. Hold øje med logs. Håndhæv med server-side kontroller der, hvor adfærd går fra uønsket til misbrugende.

Nettet har altid fungeret på en blanding af protokol, normer og håndhævelse. Robots.txt er normlaget. Brug den, men forveksl den ikke med en mur.