72 % av trafikken vår er ikke en nettleser: det vi målte på en liten nettside

Det meste som skrives om bottrafikk er enten et leverandørsalg eller en krigshistorie fra et nettsted stort nok til å bli angrepet med vilje. Dette er ingen av delene. Det er ett lite byråsted, én Cloudflare-konto, og tallene vi fant da vi endelig så ordentlig etter.

Kortversjonen: 72,4 % av forespørslene til siden vår i løpet av 23 timer bar ingen gjenkjennelig nettleser-user-agent. Chrome sto for 19,7 %. Alle navngitte søkecrawlere til sammen, Googlebot og Bingbot og Applebot, sto for 3,5 %.

Det siste tallet er det som snudde tenkningen vår. Nesten hvert eneste argument du leser om crawler-håndtering handler om det navngitte mindretallet, og det navngitte mindretallet er en avrundingsfeil ved siden av alt det andre som banker på døra.

#Hva vi faktisk målte

Alle tall kommer fra Cloudflares GraphQL-analyse for vår egen sone, over et vindu på 23 timer i august 2026. Ingenting her er modellert eller ekstrapolert.

Over to fulle døgn lå forholdet mellom forespørsler og unike besøkende på 6,5 og 6,6. Et menneske som leser to eller tre sider genererer ikke seks og en halv forespørsel når ressursfiler er holdt utenfor, og det er den samme historien sett fra en annen vinkel.

Vi hadde sett en ekstrem utgave av dette tidligere samme måned. På én dag tredoblet forespørslene seg til 173 093, mens unike besøkende lå flatt på 7 527. Tredoblede forespørsler med flatt publikum er ikke vekst, det er et sveip, og fordelingen på stier bekreftet det: den enkelt-URL-en som ble truffet mest tok bare 677 forespørsler av totalen. Noe gikk gjennom hele korpuset.

#Ordet “boter” bærer for mye her

Vi kan bevise at disse klientene ikke opptrer som nettlesere. Vi kan ikke bevise hva de er, og det kan ingen andre som kjører samme spørring heller.

Den kategorien rommer oppetidsovervåking vi betaler for, lenkesjekkere, HTTP-biblioteker i et eller annet skript, sikkerhetsskannere, feed-lesere, AI-crawlere som bygger treningssett, og agenter som henter en side på vegne av en person som stilte et spørsmål. Noe av denne trafikken er nyttig for oss. Noe av den er likegyldig. Litt av den er fiendtlig.

Den ærlige overskriften er derfor ikke “72 % av trafikken vår er boter som angriper oss”. Den er 72 % av trafikken vår kjører ingen nettleser, og den forskjellen endrer hva du bør gjøre med det.

#Hva vi ikke fant

Vi lette etter et robots.txt-problem først, fordi det er det billigste å sjekke og en reelt vanlig feil: robots.txt serveres per protokoll og per subdomene, så http, www og apex kan stille og rolig være uenige med hverandre. Våre var identiske, byte for byte, alle med omdirigering til én kanonisk adresse.

Verdt å si rett ut, for et rent resultat er også et resultat. Hvis vi bare hadde publisert det vi fikset, ville du fått et forvrengt bilde av hvor mye av dette arbeidet som finner noe som helst.

Det andre som er verdt å slå fast: robots.txt reduserer ikke belastningen. Den er en anmodning om samarbeid fra klienter som leser den. Alt som ignorerer den kommer fortsatt fram til serveren din og bruker fortsatt alt som kjører i forespørselsløpet. Lagene som faktisk senker belastningen er de som evalueres før applikasjonskoden din kjører.

Denne teksten handler om det som når fram til serveren, altså laget som må utformes av en WordPress-utvikler.

#Funnet vi ikke ventet: cachen vår hadde aldri virket

Mens vi hentet disse tallene la vi merke til treffraten i edge-cachen: rundt 4 %, på et nettsted der hver side er forhåndsgenerert ved bygg. Det burde vært nesten det motsatte.

Hver side sender dette:

cache-control: public, max-age=60, s-maxage=3600, stale-while-revalidate=86400

Og hver side kom tilbake med cf-cache-status: DYNAMIC. Vi ba om en time med edge-caching og hadde aldri én eneste gang fått det.

To årsaker, og bare sammen forklarer de det.

Cloudflare cacher ikke HTML som standard. Standardnivået for caching dekker en liste over statiske filendelser, og HTML står ikke på den, uansett hva origin sier. Å sende s-maxage gjør ikke HTML cachbar; det gjør en cache-regel.

Vår egen funksjon blokkerte resten. Vi serverer en Markdown-representasjon av hver side til agenter som ber om det med Accept: text/markdown. Det betyr at én URL har to representasjoner. For at en cache skal være trygg må cache-nøkkelen inkludere Accept, og Cloudflares standard cache-nøkkel inkluderer bare Vary: Accept-Encoding. Å slå på caching naivt ville før eller siden gitt en agent en cachet HTML-side, eller gitt et menneske cachet Markdown, som er verre enn ingen cache i det hele tatt.

Dette er delen som er verdt å generalisere: kostnaden var usynlig fordi den tilhørte en funksjon vi var stolte av. Ingen reviderer prisen på sin egen gode idé.

Løsningen var en cache-regel betinget av forespørselsheaderen: cache sider, men bare når Accept ikke ber om Markdown. Da trenger cache-nøkkelen aldri å bære Accept, fordi de forhandlende forespørslene er helt utelatt fra caching. De er rundt hundre i døgnet mot titusener av vanlige sidevisninger.

Den kommer med en andre halvdel som ikke er valgfri: tøm cachen ved utrulling. Uten det etterlater hver utrulling opptil en time med utdaterte sider for en del av publikum, og det neste du hører er at en endring ikke er synlig. En cache-regel uten et tømmesteg er en felle du setter opp for deg selv.

#Hvorfor dette handler om robusthet, ikke hastighet

Med max-age=60 endrer edge-caching lite for et menneske som kommer tilbake. Det den endrer er hva som skjer når noe sveiper hele nettstedet ditt.

Sidene våre går gjennom en edge-funksjon ved hver HTML-forespørsel, og gratisnivået tillater 100 000 funksjonskall i døgnet. Mediandøgnet ligger nær 30 000. På dagen for det sveipet nådde det 131 255, som er over taket.

Cachen var derfor aldri en ytelsesluksus. Den var forskjellen mellom at en crawl er usynlig og at en crawl tar ned nettstedet. Den omrammingen ble først tilgjengelig da botandelen og cache-raten lå på samme side.

#Endepunktet som var ødelagt i ukevis

Vi har en egen teller for den maskinlesbare flaten, fordi nettleseranalyse ikke kan se den: en agent som henter en JSON-fil kjører ingen JavaScript, så et analyseverktøy basert på et JavaScript-kall rapporterer ingenting i det hele tatt.

Den telleren sier rundt 102 agentforespørsler i døgnet. Fordelingen overrasket oss: to tredeler går til MCP-endepunktet vårt, ikke til deklarative kort som agent.json eller llms.txt, som får all oppmerksomheten i samtalen om AI-synlighet.

Så fortalte den oss noe verre. Adressen uten skråstrek på slutten svarte 301. En omdirigering gjør en POST om til en GET og forkaster forespørselskroppen, så en JSON-RPC-klient får enten ingenting eller en parse-feil. Målt over et døgn: 29 ødelagte kall mot 2 som virket.

Vi hadde et offentlig endepunkt for agenter som, for en stor andel klienter, rett og slett var ødelagt, og vi ville ikke visst om det. Det dukker ikke opp i noe dashbord en markedsfører ser på. Det genererte ingen feilmelding noen så, fordi de det feilet for ikke var mennesker.

Tre forsøk på å fikse det i applikasjonen mislyktes, fordi plattformens normalisering av skråstrek på slutten skjer før applikasjonskoden kjører. Løsningen måtte ligge over årsaken, som en rewrite-regel i nettverkets edge. Dagen etter: 12 vellykkede POST-svar der det ikke hadde vært noen.

#Slik gjør du denne målingen selv

Ingenting her krevde et betalt verktøy. Cloudflares GraphQL-analyseendepunkt svarer på alt sammen, og hele øvelsen er én API-token og en håndfull spørringer.

To feller kostet oss tid, så de fortjener å nevnes.

Token-tillatelsen er ikke den åpenbare. Vår gamle API-token kunne rulle ut, tømme cachen og styre regler, og returnerte en tillatelsesfeil på hver eneste analysespørring. Analyse krever Zone / Analytics / Read spesifikt, og en token kan være fullt i stand til å endre nettstedet ditt uten å kunne fortelle deg noe som helst om det. Verre: en kontobasert token kan feile den vanlige /user/tokens/verify-sjekken mens den virker helt riktig for GraphQL, så test den med en ekte spørring i stedet for verifiseringsendepunktet.

Tidsvinduet har tak. På vår plan nekter datasettet for adaptive forespørsler enhver spørring som spenner over mer enn ett døgn, og beholder rundt tre døgn med historikk. Be om tretti dager og du får ikke et delvis svar, du får en feil. Løkke døgn for døgn og aggreger på klientsiden.

Formen på spørringen som ga user-agent-tabellen er liten:

{ viewer { zones(filter: {zoneTag: "YOUR_ZONE_ID"}) {
    httpRequestsAdaptiveGroups(
      limit: 12,
      filter: {datetime_geq: "2026-08-19T15:00:00Z"},
      orderBy: [count_DESC]
    ) { count dimensions { userAgentBrowser } }
} } }

Bytt ut userAgentBrowser med cacheStatus, edgeResponseStatus, clientRequestPath eller clientCountryName, så har du resten av bildet. For forespørsler mot unike besøkende bærer httpRequests1dGroups begge deler i én rad.

Ett forbehold som betyr noe når du leser dine egne tall: userAgentBrowser er Cloudflares klassifisering, ikke fasit. “Ugjenkjent” betyr at parseren deres ikke traff en kjent nettlesersignatur. En crawler som sender en Chrome-user-agent-streng telles som Chrome, så den reelle andelen uten nettleser er et gulv, ikke et tak.

#Hva vi valgte å ikke gjøre, og hvorfor

Det åpenbare neste trekket etter å ha funnet 72 % er å begynne å blokkere. Det gjorde vi ikke, og resonnementet er verdt mer enn beslutningen.

Vi la ikke til WAF-regler eller rate limiting. Begge ville virket, og begge ligger i riktig lag, før applikasjonskoden. Men vi hadde ingen bevis for skade. Ingenting var nede, ingenting var tregt for mennesker, og ingen kostnad ble betalt som en cache-regel ikke kunne fjerne billigere. Å blokkere trafikk du ikke har vist er skadelig bytter en reell risiko, å stenge ute noe du er avhengig av, mot en hypotetisk.

Vi jaget ikke en feil som holdt på å ordne seg selv. Midt i dette arbeidet fant vi 9 956 gateway-tidsavbrudd på ett døgn, spredt over hele nettstedet inkludert kontaktsider på alle språk. Det så ut som en krise. Så viste oppdelingen at hver eneste én bar en ugjenkjent user agent: null fra Chrome, Safari, Googlebot eller Bingbot. Ingen mennesker og ingen søkemotor så noen gang én. Vi skrev det ned og lot det ligge. Et døgn senere viste samme vindu tre. Hadde vi “fikset” det, ville vi ha fikset en annens crawler og rullet ut en endring i vår egen kodebase som ikke helbredet noe.

Vi finansierte ikke det dyre agentarbeidet. Den samme telleren som fant det ødelagte endepunktet priset også en oppgavekø for oss. Signerte identitetsdokumenter, attestasjoner fra tredjepart, en sandkasse, en maskinlesbar kontrakt: hvert av dem er uker med arbeid, og hvert av dem rettferdiggjøres av en antakelse om at kjøpende agenter leser de deklarative filene våre. Ved 26 forespørsler i døgnet til agent.json overlever ikke den antakelsen møtet med telleren. To uavhengige målinger med et døgns mellomrom var enige, så beslutningen hviler nå på måling og ikke på én avlesning.

Mønsteret i alle tre er det samme. Måling gir retten til å gjøre ingenting, og det er en bruk av data som får langt mindre anerkjennelse enn den fortjener. Det meste av verdien vi fikk ut av denne øvelsen var ikke de to rettelsene. Det var å vite hvilke av de urovekkende tallene som fortjente uka vår.

#Hva vi ville sagt til noen som gjør dette på sitt eget nettsted

Mål før du blokkerer noe som helst. Hent user-agent-fordelingen for et helt døgn. Forholdet mellom forespørsler og unike besøkende er den raskeste rimelighetssjekken, og hvis det ligger langt over to eller tre, se nærmere.

Sjekk cache-statusen din, ikke cache-headerne dine. cache-control er en forespørsel. cf-cache-status, eller tilsvarende hos din CDN, er svaret. Vi brukte lang tid på å tro på en header som aldri én eneste gang hadde hatt effekt.

Tell trafikken analysen din ikke kan se. Hvis synligheten din for AI-agenter betyr noe for deg i det hele tatt, er det eneste stedet den trafikken dukker opp server- eller edge-logger. Våre avdekket et ødelagt endepunkt som hadde feilet stille i ukevis.

Vær forsiktig med hva du kaller et angrep. Det meste av det vi fant var verken ondsinnet eller nyttig. Det var likegyldig. Det nyttige svaret på likegyldig trafikk er å gjøre den billig å levere, ikke å kjempe mot den.

Revider kostnaden ved dine egne funksjoner. Det dyreste vi fant var ikke en bot. Det var en funksjon vi bygde med vilje, priset til null, som hadde kostet oss hele HTML-edge-cachen vår.