429 – rate limiting slår AI-crawlerne ud

429 er en besked lavet til mennesker og scripts, ikke til AI-crawlere

HTTP 429 – Too Many Requests – findes for at stoppe misbrug. En klient, der sender for mange forespørgsler for hurtigt, får besked om at falde til ro. Det er en fornuftig regel, og de fleste websteder har en variant af den i WAF'en, CDN'et eller applikationslaget.

Reglen blev ikke skrevet med en AI-agent for øje. Den blev skrevet med et scraping-script, en botnet-angriber eller en overivrig bruger, der trykker F5, for øje. Tærsklen sættes gerne som »et rimeligt antal sider, et menneske ville se på i minuttet« – og det er præcis dér, problemet starter.

AI-crawlere henter i burst, ikke i jævnt tempo

Et menneske, der læser et websted, klikker sig gennem nogle sider over nogle minutter. En AI-crawler, der opbygger kontekst til et svar, eller som følger op på en fan-out af underspørgsmål, kan hente ti eller tyve sider fra samme domæne i løbet af få sekunder – fordi den forsøger at blive færdig med svaret, før brugeren mister tålmodigheden. Det mønster ligner mere et angreb end en læser, set fra en rate limit-regel, der blot tæller forespørgsler pr. tidsenhed.

Resultatet er en logisk kortslutning: reglen fungerer præcis, som den skal, og stopper præcis den trafik, den ikke burde stoppe.

Hvorfor de fleste AI-crawlere ikke prøver igen som Googlebot

Googlebot har gennem mere end to årtier opbygget et adaptivt crawl-budget: møder den træghed eller fejl på et domæne, sænker den tempoet og kommer tilbage senere. Det er indbygget tålmodighed, finjusteret over lang tid og på et enormt antal domæner.

AI-crawlere som GPTBot, ClaudeBot og PerplexityBot er yngre produkter, bygget til et andet formål end klassisk indeksering. Nogle af dem henter indhold til træning i baggrunden. Andre – som OAI-SearchBot eller ChatGPT-User – henter en side her og nu, fordi en bruger venter på svar i chatten. Ingen af delene forudsætter samme type langsigtede, adaptive retry-logik, som Googlebot har. Får sådan en crawler gentagne 429'er fra et domæne, er det ikke givet, at den prøver igen om en time. Den kan simpelthen gå videre og bruge andre kilder i sit svar i stedet.

Det er dette, der gør 429 lydløs. Ingen får fejlmeddelelsen at se. Ingen bruger klager. Webstedet forsvinder bare gradvist fra svarene, uden at nogen advarselslampe blinker i et almindeligt analytics-dashboard.

Retry-After er en anbefaling, ikke en garanti

HTTP-standarden lader et 429- eller 503-svar indeholde en Retry-After-header, som fortæller klienten, hvor længe den bør vente, før den prøver igen. Dette er en anbefaling til klienten, ikke en påbudt adfærd, og hvor konsekvent den følges, varierer fra crawler til crawler og ændrer sig over tid, i takt med at leverandørerne opdaterer deres systemer.

Praktisk konsekvens: byg ikke en strategi på, at Retry-After løser problemet for dig. Sæt den til en fornuftig værdi, fordi det ikke koster noget, men løs selve tærsklen separat – for kendte, verificerede AI-crawlere bør grænsen være rummeligere end for ukendt trafik, ikke identisk med den.

Hvor grænsen faktisk sidder: WAF, CDN eller origin

Rate limiting kan sættes tre forskellige steder, og de opfører sig forskelligt, når du fejlfinder bagefter:

WAF-niveau (Cloudflare, Akamai, en selvstændig firewall foran applikationen). Dette er det mest almindelige sted at lægge en generisk »beskyt mod misbrug«-regel, og det sted, der oftest ikke logges i applikationens egen log – forespørgslen blokeres, før den overhovedet når din kode.

CDN-niveau, ofte en selvstændig throttling-regel pr. edge-node, hvilket kan give et lidt andet billede afhængigt af, hvilken node forespørgslen ramte.

Origin-niveau, i selve applikationen eller webserveren (nginx, en API-gateway). Dette er det sted, der faktisk vises i din serverlog, men det er ofte ikke der, den strengeste regel sidder.

Tjekker du kun ét af de tre, kan du konkludere, at »vi rate-limiter ikke AI-crawlere«, mens WAF'en lydløst gør præcis det, ét lag længere ude.

Sådan læser du 429 mod AI-crawlere i loggen

Selvtjek. Hent serverloggen eller WAF-loggen for de seneste 30 dage, og filtrér på statuskode 429 (og 503, som ofte sættes af samme regel under lastbeskyttelse) kombineret med kendte AI-user agent-strenge: GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Google-Extended og CCBot. Kig efter mønsteret fra tidligere i artiklen: en jævn strøm af 200'er, der pludselig klumper sig sammen i en serie 429'er over nogle sekunder. Det er signaturen på en burst, der ramte en tærskel bygget til mennesker.

Gennemgår du alle tre lag – WAF, CDN og origin – og ikke finder nogen 429 mod nogen af user agent-strengene ovenfor, er tærsklen sandsynligvis rummelig nok allerede. Finder du dem, er næste skridt en selvstændig, rummeligere regel for verificerede AI-crawlere, ikke en fjernelse af rate limiting for alle.