429 är ett besked gjort för människor och skript, inte för AI-crawlers
HTTP 429 – Too Many Requests – finns för att stoppa missbruk. En klient som skickar för många förfrågningar för snabbt får besked om att lugna ner sig. Det är en förnuftig regel, och de flesta webbplatser har en variant av den i WAF:en, CDN:en eller applikationslagret.
Regeln skrevs inte med en AI-agent i åtanke. Den skrevs med ett scraping-skript, en botnätsangripare eller en överivrig användare som trycker F5 i åtanke. Tröskeln sätts gärna som ”ett rimligt antal sidor en människa skulle titta på per minut” – och det är precis där problemet börjar.
AI-crawlers hämtar i burst, inte i jämn takt
En människa som läser en webbplats klickar sig genom några sidor över några minuter. En AI-crawler som bygger kontext till ett svar, eller som följer upp en fan-out av delfrågor, kan hämta tio eller tjugo sidor från samma domän på några sekunder – därför att den försöker svara färdigt innan användaren tappar tålamodet. Det mönstret liknar mer en attack än en läsare, sett från en rate limit-regel som bara räknar förfrågningar per tidsenhet.
Resultatet är en logisk kortslutning: regeln fungerar precis som den ska, och stoppar precis den trafik den inte borde stoppa.
Varför de flesta AI-crawlers inte gör om försöket som Googlebot
Googlebot har under mer än två decennier byggt en adaptiv crawl-budget: möter den tröghet eller fel på en domän sänker den tempot och kommer tillbaka senare. Det är inbyggt tålamod, finjusterat över lång tid och över ett enormt antal domäner.
AI-crawlers som GPTBot, ClaudeBot och PerplexityBot är yngre produkter, byggda för ett annat syfte än klassisk indexering. Några av dem hämtar innehåll till träning i bakgrunden. Andra – som OAI-SearchBot eller ChatGPT-User – hämtar en sida där och då för att en användare väntar på svar i chatten. Inget av det förutsätter samma typ av långsiktig, adaptiv retry-logik som Googlebot har. Får en sådan crawler upprepade 429:or från en domän är det inte givet att den försöker igen om en timme. Den kan helt enkelt gå vidare och använda andra källor i sitt svar i stället.
Det är detta som gör 429 tyst. Ingen får se felmeddelandet. Ingen användare klagar. Webbplatsen försvinner bara gradvis ur svaren, utan att någon varningslampa blinkar i en vanlig analytics-dashboard.
| Kod | Betyder | Konsekvens för AI-crawlers |
|---|---|---|
| 200 | Innehåll levererat | Kan hämtas och citeras normalt. |
| 429 | Too Many Requests | Crawlern blockeras tillfälligt av dig själv – inte av ett medvetet val. |
| 503 | Service Unavailable | Sätts ofta av samma WAF-regel som 429 vid lastskydd – samma diagnos, annan kod. |
| 403 | Forbidden | Permanent avvisning. Ser identisk ut i loggen som en avsiktlig blockering, även när den inte är det. |
Retry-After är en rekommendation, inte en garanti
HTTP-standarden låter ett 429- eller 503-svar innehålla en Retry-After-header, som talar om för klienten hur länge den bör vänta innan den försöker igen. Detta är en rekommendation till klienten, inte ett påbjudet beteende, och hur konsekvent den följs varierar från crawler till crawler och förändras över tid i takt med att leverantörerna uppdaterar sina system.
Praktisk konsekvens: bygg inte en strategi på att Retry-After löser problemet åt dig. Sätt den till ett förnuftigt värde eftersom det inte kostar något, men lös själva tröskeln separat – för kända, verifierade AI-crawlers bör gränsen vara rymligare än för okänd trafik, inte identisk med den.
Var gränsen faktiskt sitter: WAF, CDN eller origin
Rate limiting kan sättas på tre olika ställen, och de beter sig olika när du felsöker efteråt:
WAF-nivå (Cloudflare, Akamai, en egen brandvägg framför applikationen). Detta är det vanligaste stället att lägga en generisk ”skydda mot missbruk”-regel på, och det ställe som oftast inte loggas i applikationens egen logg – förfrågan blockeras innan den ens når din kod.
CDN-nivå, ofta en egen throttling-regel per edge-nod, vilket kan ge en något annan bild beroende på vilken nod förfrågan träffade.
Origin-nivå, i själva applikationen eller webbservern (nginx, en API-gateway). Detta är det ställe som faktiskt syns i din serverlogg, men det är ofta inte där den strängaste regeln sitter.
Kollar du bara ett av de tre kan du dra slutsatsen att ”vi rate-limitar inte AI-crawlers” medan WAF:en tyst gör precis det, ett lager längre ut.
Så läser du 429 mot AI-crawlers i loggen
Självkoll. Hämta serverloggen eller WAF-loggen för de senaste 30 dagarna och filtrera på statuskod 429 (och 503, som ofta sätts av samma regel vid lastskydd) kombinerat med kända AI-user agent-strängar: GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Google-Extended och CCBot. Leta efter mönstret från tidigare i artikeln: en jämn ström av 200:or som plötsligt klumpar ihop sig i en serie 429:or över några sekunder. Det är signaturen på en burst som träffade en tröskel byggd för människor.
Går du igenom alla tre lagren – WAF, CDN och origin – och inte hittar någon 429 mot någon av user agent-strängarna ovan är tröskeln troligen rymlig nog redan. Hittar du dem är nästa steg en egen, rymligare regel för verifierade AI-crawlers, inte ett borttagande av rate limiting för alla.
Vanliga frågor
Varför försöker inte AI-crawlers igen så som Googlebot gör?
Bör jag ta bort rate limiting helt för att undvika att blockera AI?
Hur vet jag att det är rate limiting och inte något annat som stoppar crawlarna?
Respekterar AI-crawlers Retry-After-headern?
Var detta till hjälp?