499 – statuskoden du aldri sender, men bør lese

499 er ikke en statuskode – det er en dagbokinnføring

HTTP-standarden har en fast, offisielt registrert liste over statuskoder. 499 står ikke på den listen. Den er en privat konvensjon fra nginx, brukt til å notere en hendelse som ellers ikke har noen god betegnelse: klienten ga opp og lukket forbindelsen før serveren rakk å sende et svar i det hele tatt.

Fordi forbindelsen allerede er lukket når nginx skriver linjen, er det ingenting å sende noe svar til. 499 går aldri over nettverket. Ingen nettleser viser den. Ingen bot mottar den. Den eneste plassen den noensinne dukker opp, er i din egen access-logg – en dagbokinnføring skrevet for deg selv, ikke en beskjed til noen andre.

Samme hendelse, andre navn: Apache og IIS

Bruker du ikke nginx, betyr ikke det at problemet forsvinner – det betyr bare at det er gjemt et annet sted. Apache skriver ikke en egen statuskode for en avbrutt klient; du finner det som en linje uten normal byte-størrelse i access.log, eller som en “Connection reset by peer”-melding i error.log. IIS gjør noe lignende: W3C-loggen kan vise en win32-statuskode i stedet for en vanlig HTTP-kode, der en verdi som 1236 betyr at forbindelsen ble avbrutt lokalt.

Leter du kun etter 4xx- og 5xx-koder i den vanlige statuskolonnen, går du rett forbi denne hendelsen på både Apache og IIS. Den er der – bare under et annet navn, i et annet felt.

Crawlerens tålmodighet er ikke den samme som Googlebots

Googlebot har hatt over to tiår på å bygge et adaptivt system som tåler treghet fra et domene og justerer seg over tid. Mange AI-crawlere er bygget for et helt annet bruksmønster. En crawler som henter innhold i bakgrunnen for trening kan i praksis ha romsligere tid til rådighet enn en crawler som må levere et svar til et menneske som venter i en chat akkurat nå – som OAI-SearchBot, ChatGPT-User eller Claude-User. De sistnevnte er bygget for lav ventetid fordi brukeren opplever hver ekstra tidels sekund direkte.

Konsekvensen: en side som svarer greit nok til at et menneske ikke legger merke til ventetiden, kan likevel være for treg for en crawler som må levere et ferdig svar før brukeren mister tålmodigheten. Grensen crawleren jobber mot, er strammere enn den du tester mot i din egen nettleser.

Hvor forsinkelsen faktisk oppstår: tunge SSR-sider og kalde cache-treff

Tiden til første byte (TTFB) er selve flaskehalsen. To mønstre står for de fleste av tilfellene:

Tung server-side rendering uten cache. Hver forespørsel bygger siden på nytt fra bunnen – henter data, kjører komponenttreet, serialiserer HTML – før et eneste byte kan sendes. Jo tyngre denne kjeden er, desto lengre venter crawleren i mørket.

Kalde cache-treff og kalde funksjonsstarter. Første forespørsel mot en side (eller mot en serverless-funksjon som ikke har kjørt nylig) betaler en oppstartskostnad de neste forespørslene slipper. Treffer en AI-crawler nettopp den kalde starten – noe som er statistisk mer sannsynlig for mindre besøkte sider, altså ofte akkurat de sidene som trenger synlighet mest – er sjansen for at forbindelsen ryker, høyere enn i din egen varme utviklingstest.

Fra 499 til utdatert AI-svar: hele kjeden

En enkelt 499 er ikke en katastrofe. Et gjentatt mønster er noe annet. Ser en crawler stadig at forbindelser til domenet ditt ryker før et svar kommer, er et rimelig utfall over tid at den nedprioriterer eller sjeldnere returnerer til nettopp de sidene – ikke fordi innholdet er dårlig, men fordi nettstedet fremstår upålitelig å hente fra.

Lavere hentefrekvens betyr at det som allerede ligger lagret om deg – riktig eller foreldet – blir stående lenger uten å bli oppdatert. En prisendring, en ny tjeneste, en rettet feil på siden: ingenting av det når frem til neste AI-svar før crawleren faktisk klarer å hente siden på nytt. Det er dette som gjør 499 stille på nøyaktig samme måte som resten av serien: ingen feilmelding vises for noen, og symptomet du til slutt legger merke til er et AI-svar som virker hakket bak virkeligheten.

Slik teller du 499 mot AI-crawlere i loggen

Selvsjekk. Hent access-loggen for de siste 30 dagene og grupper linjene på statuskode 499 (eller Apache/IIS-ekvivalenten fra tabellen over) kombinert med user-agent. Del resultatet i to grupper: kjente AI-user-agents (GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Google-Extended) og alt annet.

Er andelen 499 tydelig høyere for AI-botten enn for vanlig menneskelig trafikk på de samme sidene, er det ikke innholdet som er problemet – det er TTFB-en. Løsningen ligger da i caching, raskere rendering eller varme funksjonsstarter, ikke i å skrive om teksten. Er andelen omtrent lik på tvers av all trafikk, er det trolig en generell ytelsessak som rammer alle besøkende likt, og bør prioriteres deretter.