429 – rate limiting slår ut AI-crawlerne

429 er en beskjed laget for mennesker og skript, ikke for AI-crawlere

HTTP 429 – Too Many Requests – finnes for å stoppe misbruk. En klient som sender for mange forespørsler for raskt, får beskjed om å roe ned. Det er en fornuftig regel, og de fleste nettsteder har en variant av den i WAF-en, CDN-en eller applikasjonslaget.

Regelen ble ikke skrevet med en AI-agent i tankene. Den ble skrevet med et scraping-skript, en botnett-angriper eller en overivrig bruker som trykker F5 i tankene. Terskelen settes gjerne som «et rimelig antall sider et menneske ville sett på i minuttet» – og det er akkurat der problemet starter.

AI-crawlere henter i burst, ikke i jevn takt

Et menneske som leser et nettsted, klikker seg gjennom noen sider over noen minutter. En AI-crawler som bygger kontekst til et svar, eller som følger opp et fan-out av underspørsmål, kan hente ti eller tjue sider fra samme domene i løpet av få sekunder – fordi den prøver å svare ferdig før brukeren mister tålmodigheten. Det mønsteret ligner mer på et angrep enn på en leser, sett fra en rate-limit-regel som bare teller forespørsler per tidsenhet.

Resultatet er en logisk kortslutning: regelen fungerer akkurat som den skal, og stopper akkurat den trafikken den ikke burde stoppe.

Hvorfor de fleste AI-crawlere ikke retry-er som Googlebot

Googlebot har over to tiår bygget et adaptivt crawl-budsjett: treffer den treghet eller feil på et domene, senker den tempoet og kommer tilbake senere. Det er innebygd tålmodighet, finjustert over lang tid og på et enormt antall domener.

AI-crawlere som GPTBot, ClaudeBot og PerplexityBot er yngre produkter, bygget for et annet formål enn klassisk indeksering. Noen av dem henter innhold til trening i bakgrunnen. Andre – som OAI-SearchBot eller ChatGPT-User – henter en side der og da fordi en bruker venter på svar i chatten. Ingen av delene forutsetter samme type langsiktig, adaptiv retry-logikk som Googlebot har. Får en slik crawler gjentatte 429-er fra et domene, er det ikke gitt at den prøver igjen om en time. Den kan rett og slett gå videre og bruke andre kilder i svaret sitt i stedet.

Det er dette som gjør 429 stille. Ingen får se feilmeldingen. Ingen bruker klager. Nettstedet forsvinner bare gradvis fra svarene, uten at noe varsellys blinker i et vanlig analytics-dashbord.

Retry-After er en anbefaling, ikke en garanti

HTTP-standarden lar en 429- eller 503-respons inkludere en Retry-After-header, som forteller klienten hvor lenge den bør vente før den prøver igjen. Dette er en anbefaling til klienten, ikke en pålagt oppførsel, og hvor konsekvent den følges varierer fra crawler til crawler og endrer seg over tid etter hvert som leverandørene oppdaterer sine systemer.

Praktisk konsekvens: ikke bygg en strategi på at Retry-After løser problemet for deg. Sett den med en fornuftig verdi fordi det koster ingenting, men løs selve terskelen separat – for kjente, verifiserte AI-crawlere bør grensen være romsligere enn for ukjent trafikk, ikke identisk med den.

Hvor grensen faktisk sitter: WAF, CDN eller origin

Rate limiting kan settes på tre forskjellige steder, og de oppfører seg ulikt når du feilsøker etterpå:

WAF-nivå (Cloudflare, Akamai, en egen brannmur foran applikasjonen). Dette er det vanligste stedet en generisk «beskytt mot misbruk»-regel legges, og det stedet som oftest ikke logges i applikasjonens egen logg – forespørselen blokkeres før den når koden din i det hele tatt.

CDN-nivå, ofte en egen throttling-regel per edge-node, som kan gi et litt annet bilde avhengig av hvilken node forespørselen traff.

Origin-nivå, i selve applikasjonen eller webserveren (nginx, en API-gateway). Dette er stedet som faktisk vises i serverloggen din, men det er ofte ikke der den strengeste regelen sitter.

Sjekker du bare én av de tre, kan du konkludere med at «vi rate-limiter ikke AI-crawlere» mens WAF-en stille gjør akkurat det, ett lag lenger ute.

Slik leser du 429 mot AI-crawlere i loggen

Selvsjekk. Hent serverloggen eller WAF-loggen for de siste 30 dagene, og filtrer på statuskode 429 (og 503, som ofte settes av samme regel under lastvern) kombinert med kjente AI-user-agent-strenger: GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Google-Extended og CCBot. Se etter mønsteret fra tidligere i artikkelen: en jevn strøm av 200-er som plutselig klumper seg i en serie 429-er over noen sekunder. Det er signaturen på en burst som traff en terskel bygget for mennesker.

Går du gjennom alle tre lagene – WAF, CDN og origin – og finner ingen 429 mot noen av user-agent-strengene over, er terskelen trolig romslig nok allerede. Finner du dem, er neste steg en egen, romsligere regel for verifiserte AI-crawlere, ikke en fjerning av rate limiting for alle.