Så skriver du en robots.txt som faktiskt blockerar AI-skrapare

Den obekväma sanningen om robots.txt

En robots.txt-fil är inte ett lås. Den är en skylt på dörren.

Den skillnaden spelar roll när team frågar om de kan ”blockera AI-skrapare” med en liten textfil. För välrenommerade crawlers som följer Robots Exclusion Protocol, ja: en korrekt skriven robots.txt kan säga åt dem att inte crawla dina sidor. För okända skrapare, imitatörer, webbläsarautomation och botar som helt enkelt inte bryr sig gör den ingenting i sig själv.

Det praktiska målet är alltså inte att ”göra skrapning omöjlig”. Det är att:

• Säga åt AI-crawlers som följer reglerna att inte använda din webbplats.
• Undvika att av misstag blockera sökmotorer eller användbara tjänster.
• Lägga till starkare serverbaserade kontroller mot missbruk.
• Hålla policyn underhållbar när crawler-namn ändras.

Det är den tråkiga versionen. Det är också den version som fungerar.

Vad robots.txt kan och inte kan göra

En robots.txt-fil ligger i webbplatsens rot:

https://example.com/robots.txt

Crawlers hämtar den innan de börjar crawla. Filen innehåller grupper av regler. Varje grupp börjar med en eller flera User-agent-rader, följda av Allow- eller Disallow-direktiv.

En enkel blockering av hela webbplatsen ser ut så här:

User-agent: GPTBot
Disallow: /

Det betyder: om du är GPTBot, crawla ingenting på den här webbplatsen.

Men robots.txt har tydliga begränsningar:

1. Den är frivillig. Illasinnade aktörer kan ignorera den.
2. Den hindrar inte en URL från att begäras av en vanlig webbläsare eller ett skript.
3. Den tar inte bort innehåll som redan har samlats in någon annanstans.
4. Den definierar inte upphovsrätt, licensiering eller träningsrättigheter i sig själv.
5. Den kan felkonfigureras på sätt som blockerar fel botar.

Om du behöver verklig åtkomstkontroll ska du använda autentisering, auktorisering, hastighetsbegränsning, IP-baserade kontroller, bot-hantering eller juridiska kontroller. Robots.txt är fortfarande användbar, men den hör hemma i en bredare strategi för innehållsskydd.

Det liknar andra frågor inom webbstyrning: den synliga kontrollen är sällan hela kontrollen. Om din organisation redan har ohanterad AI-användning internt gäller samma princip; en snabb shadow AI-granskning är ofta mer användbar än att låtsas att ett enda policydokument löser problemet.

Börja med ditt policybeslut

Innan du redigerar filen behöver du bestämma vad du faktiskt försöker blockera.

Det finns minst fyra olika saker som människor menar med ”AI-skrapare”:

• Crawlers som används för att samla in träningsdata.
• Crawlers för AI-sökning eller svarsmotorer.
• Användarutlösta hämtare, till exempel när någon ber en AI-produkt sammanfatta en URL.
• Generiska skrapare som låtsas vara vanliga webbläsare.

Du kanske vill blockera alla. Eller så vill du ha sökupptäckt samtidigt som du väljer bort modellträning. Det är inte samma policy.

OpenAI dokumenterar till exempel separata user agents för olika syften, inklusive GPTBot, ChatGPT-User och OAI-SearchBot. Google använder Google-Extended som en kontrolltoken för vissa användningsfall med Gemini och Vertex AI, medan vanlig crawling för Google Search hanteras av andra Googlebot-user agents.

Den uppdelningen är viktig. Om du blockerar breda user agents slarvigt kan du skada vanlig synlighet i sökresultat när du försöker blockera AI-träning.

En rimlig robots.txt-mall för att blockera AI

Här är en försiktig utgångspunkt för att blockera flera vanligt dokumenterade AI-relaterade crawlers, samtidigt som allmänna sökcrawlers lämnas ifred:

# 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: /

Det här är inte en magisk universallista. Det är ett mönster som går att underhålla.

Några kommentarer:

• Disallow: / betyder ”crawla ingen sökväg”.
• User-agent: * gäller för crawlers som inte matchas av en mer specifik grupp.
• Allow: / är inte strikt nödvändigt för standardgruppen, men det gör din avsikt tydlig.
• Håll kommentarer korta. Vissa parsers är förlåtande, men robots.txt bör förbli tråkig.
• Lägg inte privata URL:er i robots.txt. Filen är offentlig, och att lista känsliga sökvägar kan annonsera ut dem.

Den sista punkten tål att upprepas. Robots.txt är inte en sekretessmekanism. Om /client-contracts/ inte ska vara offentlig, skydda den med autentisering. Nöj dig inte med att disallowa den.

Var försiktig med Google-Extended

Google-Extended missförstås ofta. Det är inte samma sak som att blockera Google Search.

Enligt Googles dokumentation är Google-Extended en fristående produkttoken som publicister kan använda för att styra om webbplatsinnehåll får bidra till att förbättra vissa Gemini- och Vertex AI-funktioner. Att blockera den bör inte i sig blockera Googlebot från att crawla för Search.

Med det sagt: ersätt inte alla Google-direktiv med en bred blockering som denna om du inte verkligen menar det:

User-agent: Googlebot
Disallow: /

Det skulle säga åt Google Searchs huvudcrawler att inte crawla din webbplats. För de flesta offentliga webbplatser är det inte vad du vill.

Samma åtskillnad gäller på andra håll. Vissa leverantörer skiljer mellan träningscrawlers och användarutlöst surfning eller crawlers för AI-sökning. Andra gör det inte. Du behöver läsa dokumentationen för de botar du bryr dig om och behandla din robots.txt som en levande fil, inte som en engångsruta att kryssa i.

Testa filen som produktionskod

Robots.txt ser enkel ut, och därför är den lätt att ha sönder.

Vanliga misstag är bland annat:

• Att ladda upp den på fel plats, till exempel /assets/robots.txt i stället för /robots.txt.
• Att använda typografiska citattecken kopierade från en dokumentredigerare.
• Att av misstag blockera alla crawlers med User-agent: * och Disallow: /.
• Att anta att en domäns fil gäller för en annan subdomän.
• Att glömma att http://, https://, www och värdar utan www kan hanteras olika beroende på din konfiguration.

För webbplatser med flera domäner bör du kontrollera varje kanonisk värd. En robots-fil på https://www.example.com/robots.txt styr inte automatiskt https://app.example.com/robots.txt.

När du felsöker ska du inspektera det faktiska HTTP-svaret, inte bara vad förhandsgranskningen i ditt CMS visar. Du vill ha ett 200 OK-svar, innehållstypen text/plain om möjligt, och exakt den fil du förväntar dig. Om omdirigeringar, cachelagring eller CDN-regler är inblandade hjälper rå inspektion av headers. Arbetsflödet i felsökning av omdirigeringar och HTTP-headers i produktion gäller direkt här.

Lägg till serverbaserade kontroller för botar som ignorerar reglerna

Om crawlern följer reglerna är robots.txt den renaste signalen. Om crawlern är missbrukande behöver du verkställighet.

Praktiska kontroller är bland annat:

Hastighetsbegränsning

Sätt trösklar för ovanliga begärandemönster: för många sidor per minut, djup genomgång av paginering, upprepade 404:or eller hög begärandevolym från en liten uppsättning IP-adresser. Hastighetsgränser bör vara generösa nog att inte straffa verkliga användare och strikta nog att göra storskalig extrahering dyr.

User-agent-filtrering

Du kan blockera dokumenterade user agents för AI-crawlers på webbservern, i en reverse proxy, i ett CDN eller i applikationslagret. Det är starkare än robots.txt eftersom det returnerar ett faktiskt nekande svar.

Nginx kan till exempel blockera ett user agent-mönster, även om produktionsregler bör testas noggrant:

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

Det är inte idiotsäkert. User-agent-strängar är lätta att förfalska. Men det stoppar den ärliga eller lata trafiken och minskar belastningen.

IP- och ASN-kontroller

Vissa operatörer publicerar IP-intervall, men många skrapningsekosystem gör det inte. IP-baserad blockering kan fungera vid uppenbart missbruk, särskilt från molnhostingintervall utan normal användartrafik, men den kan också skapa falska positiva träffar. Använd loggar före regler.

Autentisering och betalväggar

Om innehåll inte får kopieras i stor skala ska du inte lägga hela innehållet på en offentlig URL. Robots.txt är olämplig för konfidentiellt material, licensierade databaser, privata communities eller betalda arkiv.

Innehållsminimering

Ibland är det bästa skyddet arkitektoniskt. Exponera inte onödiga API:er, stora JSON-payloads, dold metadata, utkast-endpoints eller fullständiga arkiv om den offentliga sidan bara behöver en liten delmängd. Bildtunga webbplatser bör också tänka på vilken metadata de publicerar; integritetslogiken i att ta bort EXIF-metadata innan du delar foton online gäller även för innehållsarbete.

Använd robots meta-taggar för regler på sidnivå

Robots.txt styr crawling. Robots meta-taggar och X-Robots-Tag-headers styr indexering och snippet-beteende för sökmotorer och crawlers som följer reglerna.

Till exempel:

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

Eller som en HTTP-header:

X-Robots-Tag: noindex, noarchive

Det här är inte AI-specifika sköldar. De är användbara när du vill att en sida ska vara åtkomlig men inte indexeras. Men om du blockerar en crawler från att hämta en sida i robots.txt kanske den aldrig ser meta-taggen på sidnivå. Förlita dig inte på en noindex-tagg på en URL som crawlern är förbjuden att crawla.

Den grova regeln:

• Använd robots.txt för att minska eller förhindra crawling.
• Använd meta robots eller X-Robots-Tag för att styra indexeringsbeteende.
• Använd serverbaserade kontroller för att verkställa åtkomst.

Övervaka loggar efter publicering

Att publicera filen är bara steg ett. Kontrollera sedan dina loggar.

Leta efter:

• Begäranden till /robots.txt från de user agents du har namngivit.
• Fortsatt crawling efter att disallow-regler har serverats.
• Misstänkta user agents med hög volym.
• Webbläsarliknande user agents som begär tusentals sidor i följd.
• Upprepad åtkomst till flöden, sitemaps, söksidor och paginering.

Om en bot begär robots.txt, ser ett fullständigt disallow och sedan slutar, gjorde robots.txt sitt jobb. Om den fortsätter, flytta den boten till verkställighet: hastighetsgränser, blockeringar eller autentisering.

Granska också din sitemap-exponering. Sitemaps är användbara för sökmotorer, men de är också praktiska kartor för skrapare. Det betyder inte att du bör ta bort dem från vanliga webbplatser. Det betyder att du inte bör inkludera URL:er som du inte vill att offentliga system ska upptäcka.

Håll filen liten och granskad

Robots.txt tenderar att förfalla. Ett marknadsteam lägger till en kampanjmikrosajt. En utvecklare lägger till en staging-sökväg. En leverantör ändrar namnet på sin crawler. Två år senare vet ingen varför hälften av reglerna finns.

Behandla den som konfiguration:

• Lagra den i versionshantering när det är möjligt.
• Lägg till en kort kommentar för varje AI-crawler-grupp.
• Granska den kvartalsvis.
• Kontrollera leverantörsdokumentation innan du lägger till breda regler.
• Testa efter ändringar i CDN, CMS eller hosting.

Om din webbplats publicerar AI-assisterat innehåll bör du också skilja crawler-policy från redaktionell transparens. Att blockera AI-skrapare handlar om åtkomst och återanvändning. Redovisning handlar om läsarnas förtroende. De överlappar etiskt, men de är inte samma kontroll. Ett praktiskt sätt att redovisa detta beskrivs i hur ärlig AI-redovisning ser ut på en liten webbplats.

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

💡 Prova detta: När du har lagt till regler för AI-crawlare, kontrollera syntaxen med Robots.txt Tester så att du inte av misstag även blockerar legitima botar.

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

Slutsatsen

En bra robots.txt-fil blockerar AI-crawlers som följer reglerna. Den stoppar inte målmedveten skrapning, kopierade user-agent-strängar, komprometterade webbläsare eller personer som manuellt klistrar in ditt innehåll i AI-system.

Det gör den inte värdelös. Det gör den till ett lager.

Skriv explicita regler för dokumenterade AI-crawlers. Undvik breda blockeringar som skadar synlighet i sökresultat. Testa den serverade filen, inte utkastet. Följ loggarna. Verkställ med serverbaserade kontroller där beteendet går från oönskat till missbrukande.

Webben har alltid byggt på en blandning av protokoll, normer och verkställighet. Robots.txt är normlagret. Använd den, men missta den inte för en mur.