
Kortversion: Search, Agent och Training är tre olika frågor. En svensk webbplats kan vilja synas i sökresultat, låta en agent hämta aktuell produktinformation och samtidigt säga nej till att innehållet används för modellträning. Börja med innehållet och verksamhetsmålet – välj sedan teknisk kontroll.
AI-botar har länge hanterats som en enkel ja-eller-nej-fråga: släpp in dem eller blockera dem. För ett företag, en e-handel eller ett content-team blir det snabbt för grovt. En sökrobot kan hjälpa en kund att hitta rätt sida. En AI-agent kan behöva läsa en aktuell pris- eller hjälpsida för att svara på en fråga. En träningscrawler kan däremot samla material för att förbättra en modell.
Det är olika användningar av samma webbplatsinnehåll. Därför behöver också policyn vara uppdelad.
Tre sorters AI-trafik
Cloudflare beskriver i sina kontroller tre huvudkategorier: Search, Agent och Training. Kategorierna är ett praktiskt sätt att tänka kring syftet med besöket, inte en garanti för att varje bot alltid kan klassificeras perfekt.
1. Search: hitta och hänvisa
Search-crawlers samlar eller indexerar innehåll för att kunna svara på frågor senare. För de flesta publika företagssidor är sökbarhet fortfarande viktig. En guide, produktsida eller dokumentationssida som aldrig indexeras blir svårare att hitta – oavsett om besökaren använder en traditionell sökmotor eller en sökupplevelse med AI-inslag.
Att tillåta sökindexering betyder dock inte automatiskt att man måste tillåta all annan automatiserad användning. Det är just den separationen som ofta saknats i en generell AI-blockering.
2. Agent: göra något i realtid
En agent besöker ofta webbplatsen för att utföra en uppgift åt en person: hämta en aktuell specifikation, jämföra alternativ eller hitta rätt instruktion. Cloudflare nämner bland annat chatthämtningsrobotar och webbläsarbaserade agenter som exempel.
För en e-handel kan sådan åtkomst vara värdefull om pris, lager och produktdata är tydliga. För ett SaaS-bolag kan det vara rimligt att låta en agent läsa publik dokumentation, men inte att anropa kundspecifika API:er eller försöka navigera genom interna vyer.
Agentåtkomst är därför ofta en fråga om avgränsning: vilka sidor, vilka anrop, vilken hastighet och vilken information får användas?
3. Training: samla för modellträning
Training-crawlers hämtar innehåll för att träna eller finjustera modeller. Här är det vanligt att verksamheten vill göra en annan bedömning än för sök. Ett team kan vilja vara synligt och citerat, men inte ge ett generellt medgivande till att hela arkivet används som träningsdata.
Det går inte att utläsa en kommersiell överenskommelse bara av att en bot får läsa en sida. Om innehållet är viktigt ur upphovsrätts-, affärs- eller konkurrensperspektiv behöver sådana frågor hanteras separat, med avtal och juridisk bedömning där det behövs.
Cloudflare-kontroller och robots.txt är inte samma sak
Cloudflares AI Crawl Control ger enligt dokumentationen synlighet i vilka AI-tjänster som besöker domänen och möjlighet att skapa allow- eller blockregler för identifierade crawlers. Cloudflare beskriver funktionen som tillgänglig på alla planer, medan mer avancerad identifiering via Bot Management ger en annan detaljnivå.
Det är en kontroll i trafiklagret. Den kan tillämpas när webbplatsens trafik faktiskt går via Cloudflare och när trafiken matchar de signaler och regler som Cloudflare kan identifiera. Den ersätter inte inloggning, behörigheter, API-säkerhet eller skydd mot en aktör som byter identitet och kringgår en regel.
robots.txt har en annan roll. Filen uttrycker webbplatsägarens önskemål till crawlers, men efterlevnaden är frivillig. Cloudflares dokumentation säger uttryckligen att en crawler kan ignorera Disallow och hämta innehåll ändå. Vill du uttrycka en policy kan robots.txt och Content Signals vara en del av lösningen. Vill du försöka genomdriva blockering behöver du en kontroll i trafiklagret, till exempel en relevant Cloudflare-regel, kompletterad med vanlig åtkomstkontroll.
Cloudflares dokumentation beskriver signalerna search, ai-input och ai-train. Cloudflare testar dessutom ett content-use-fält som anger om innehåll får lagras och återanvändas mer eller mindre fritt. Sådana signaler är maskinläsbara uttryck för en policy – de är inte i sig ett tekniskt lås.
En enkel beslutsmodell: öppet, begränsat eller blockerat
Bedöm varje innehållstyp utifrån fyra frågor:
- Vill vi att människor ska hitta sidan?
- Har en agent nytta av aktuell information från sidan?
- Är vi bekväma med att innehållet används för träning?
- Vad händer om informationen kopieras, sammanfattas eller blir inaktuell?
Använd sedan tre nivåer:
- Öppet: Sökindexering tillåts. Agentåtkomst kan tillåtas på publika sidor där aktuell information ger kundnytta.
- Begränsat: Åtkomst tillåts bara för vissa botar, sökvägar eller användningsfall. Rate limiting, tydliga API:er och separata dokumentationssidor gör policyn lättare att följa.
- Blockerat: Innehållet ska inte hämtas av automatiserad trafik. Lägg det bakom inloggning eller använd en teknisk kontroll där det är motiverat – och kontrollera att originservern inte är åtkomlig förbi skyddslagret.
Så kan olika sidtyper behandlas
- Publika guider och artiklar: Search öppet, Agent efter behov, Training enligt en uttrycklig policy.
- Produkt- och prissidor: Search öppet, Agent begränsat till aktuell publik information, Training separat bedömt.
- Publik dokumentation: Search öppet, Agent öppet eller begränsat beroende på belastning och innehåll, Training separat bedömt.
- Kunddata, kassa och interna vyer: Ingen publik crawleråtkomst. Använd inloggning, behörigheter och API-skydd.
Det finns inget rätt svar för alla verksamheter. En innehållssajt som lever på räckvidd kan välja öppnare regler än ett bolag vars viktigaste värde finns i detaljerade manualer, prislogik eller kundspecifik information.
Praktisk checklista för ett svenskt SME eller SaaS-bolag
1. Inventera innehållet
Lista publika artiklar, produktsidor, dokumentation, prisinformation, API:er och sidor som kräver inloggning. Markera var det finns personuppgifter, kundunika uppgifter, affärshemligheter eller innehåll som snabbt blir fel.
2. Skriv en kort policy
Besluta separat för Search, Agent och Training. Skriv också vad som gäller för kommersiell återanvändning, hög belastning och innehåll bakom inloggning. En policy på en sida är bättre än ett ospecificerat ”blockera AI”.
3. Börja med signaler
Kontrollera robots.txt, eventuella Content Signals och metadata på viktiga sidor. Se till att reglerna inte råkar blockera den sökindexering som verksamheten faktiskt behöver. Kom ihåg att signaler uttrycker en preferens; de garanterar inte efterlevnad.
4. Lägg enforcement där det behövs
Om ni använder Cloudflare kan AI Crawl Control och relevanta WAF-regler ge en teknisk kontroll för identifierad trafik. Begränsa hellre på rätt sökvägar och innehållstyper än att blockera hela domänen utan att förstå konsekvensen. Skydda samtidigt origin, admin, kassa och API:er med vanliga säkerhetsmekanismer.
5. Följ upp i loggarna
Titta på user-agent, IP, frekvens, sökväg och svarskoder. Jämför trafik före och efter en ändring. En robot kan vara felklassificerad, oidentifierad eller ha flera syften – och Cloudflare påpekar att vissa crawlers kan höra till mer än en kategori.
6. Dokumentera undantag
Om en partner, kund eller söktjänst ska få särskild åtkomst, dokumentera varför, vilka sidor som omfattas och när beslutet ska omprövas. Uppdatera policyn när nya API:er, prisflöden eller inloggade funktioner lanseras.
En rimlig första policy
För många svenska företag är en försiktig startpunkt:
- Tillåt etablerad sökindexering av publikt innehåll som ska hittas.
- Tillåt agentåtkomst bara där den ger tydlig kundnytta och inte öppnar interna flöden.
- Uttryck en separat policy för modellträning och användning av innehåll.
- Använd teknisk blockering för identifierad trafik när ett önskemål måste få faktisk effekt.
- Skydda inloggning, kassa, admin och kunddata med behörighet och säkerhetsregler – inte enbart robots.txt.
- Följ upp effekten i loggar och sökdata innan policyn görs hårdare.
Cloudflare meddelar dessutom att nya standardinställningar för nya domäner ska börja gälla den 15 september 2026: Training och Agent ska då blockeras som standard på sidor med annonser, medan Search fortsatt ska tillåtas. Blandade crawlers, till exempel sådana som kombinerar Search och Training, kan omfattas av den mest restriktiva relevanta regeln. Det är en kommande standardförändring, inte ett skäl att kopiera en standard rakt av. Kontrollera inställningen och välj själv vad som passar webbplatsen.
Slutsats
Frågan är inte om webbplatsen ska ”släppa in AI”. Frågan är vilken åtkomst som skapar värde, vilken som innebär en risk och vilken kontroll som faktiskt kan påverka trafiken.
Search, Agent och Training bör bedömas var för sig. robots.txt är ett viktigt språk för preferenser och samarbete, men inte ett tekniskt lås. Cloudflare kan ge mer synlighet och enforcement för trafik som går genom deras lager, men det behöver kombineras med bra informationsarkitektur, loggning, autentisering och en tydlig policy.