Googlebot sender PUT og DELETE mod dine endpoints. Din egen JavaScript beder om det

Hvad Google faktisk har sagt

Gary Illyes fra Google svarede den 7. august 2026 på et tilbagevendende spørgsmål: sender Googles crawlere andet end GET og POST? Ja, gør de. HEAD, OPTIONS, PUT, PATCH og DELETE udgør tilsammen under 1,5 % af det samlede antal requests, alle Googles crawlere sender. Forklaringen var, at det er JavaScript på siderne, der sætter kaldene i gang, hvorefter renderingen gør sit arbejde. Udmeldingen kom på LinkedIn og blev refereret af Search Engine Roundtable samme dag.

Tre forbehold hører med, og de er lige så vigtige som tallet. Det er Googles eget tal, ikke en uafhængig måling. Det dækker alle Googles crawlere under ét — Googlebot, billedcrawleren, Google-Extended og resten — ikke Googlebot alene, så andelen på dit domæne kan se anderledes ud. Og forklaringen om JavaScript er en forklaring, ikke et måleresultat: Illyes fortæller, hvorfor requestene opstår, ikke hvor mange der rammer hvilke endpoints.

Hvorfor det sker: renderingen er en rigtig browser

Google beskriver selv processen i tre faser — crawling, rendering, indeksering — og skriver, at en headless Chromium renderer siden og udfører JavaScripten, når ressourcerne tillader det. Det er ikke en forsimplet parser. Det er en browser, der kører din kode.

Derfor gælder browserens regler også: hvis din frontend kalder fetch() mod dit eget API under mount, kalder Googles renderer det også. Hvis kaldet bruger PATCH, sender Google en PATCH. Google har dokumenteret et par grænser for, hvad renderingen ikke gør — den rydder Local Storage og Session Storage mellem sideindlæsninger, afviser tilladelsesanmodninger og understøtter hverken WebSockets eller WebRTC — men der står ingen steder, at den afholder sig fra bestemte HTTP-metoder. Den samme dokumentation siger også, at renderingen cacher aggressivt og kan ignorere dine cache-headers.

Metode-allowlisten i din WAF er blevet en SEO-indstilling

Standardrådet i enhver hærdningsguide er at afvise alt andet end GET, POST og HEAD på kanten. Det er stadig et fornuftigt udgangspunkt for de fleste sider. Men på en frontend, der henter data i browseren, er det ikke længere en ren sikkerhedsbeslutning. Afviser din WAF en OPTIONS-preflight, fejler CORS-kaldet bagved, og så bliver den del af siden aldrig renderet færdig for Google.

Det ubehagelige er, hvordan det ser ud udefra. Siden svarer 200 for crawleren, HTML'en er intakt, Search Console viser ingen fejl, og indholdet mangler bare. Det ligner til forveksling et rankingtab efter en opdatering — og der er altid en opdatering at pege på. Googles egen statusside viser, at spamopdateringen i august 2026 kørte fra 18. til 21. august. Jeg har set for mange fald blive tilskrevet en navngiven opdatering, hvor årsagen lå i et lag, ingen kiggede i.

Google kan ramme endpoints, du troede var private

Den anden halvdel er sværere at ignorere. Hvis din frontend kalder et endpoint, der ændrer tilstand — en PATCH på en kurv, en DELETE på en session, en PUT der gemmer en præference — så kan Googles renderer udføre kaldet. Ikke fordi Google leder efter API'er, men fordi din kode bad om det.

Antagelsen om, at "kun rigtige brugere rammer det endpoint, for det kaldes kun fra klienten", holder ikke. Klienten kan være Googles. Det er ikke et argument for at blokere Google. Det er et argument for, at autentificering og idempotens skal sidde i endpointet, ikke i en formodning om, hvem der kalder det. En renderer uden session bør få 401, ikke få lov at skrive.

HTTP QUERY er det næste, der flytter sig

Elleve dage senere, den 18. august 2026, svarede Illyes på et spørgsmål om HTTP QUERY — en metode, der kombinerer GET's sikkerhed og cachebarhed med POST's mulighed for at sende en struktureret body. Google Search vil understøtte den, når økosystemet er klar: webservere, CDN'er, reverse proxies og browsere skal opdatere deres netværkslag først, som Search Engine Roundtable refererede det.

Det er den rigtige løsning på facetteret navigation, hvor valget i dag står mellem uendelige query strings og POST-ruter, der hverken kan caches eller crawles. Men der er ingen dato, og det står ikke i Googles dokumentation. Det er et signal om retning, ikke noget at bygge på i dette kvartal.

Sådan finder du ud af, om det gælder dig

Det tager en formiddag, og du behøver ikke andet end adgangslogs.

1. Verificér Googlebot på omvendt DNS mod googlebot.com, ikke på user-agent-strengen. Alt andet måler du på støj.
2. Filtrér de verificerede requests på metode forskellig fra GET, og gruppér på endpoint og statuskode.
3. Enhver 403 eller 405 på et ikke-GET-kald fra verificeret Googlebot er din egen rendering, der bliver afvist af dit eget forsvar. Det er listen over sider, der ikke bliver renderet færdige.
4. Kryds de ramte endpoints med, om de ændrer tilstand. Dem der gør, skal have autentificering og idempotensnøgler, uanset hvem der kalder.
5. Ret rækkefølgen: først OPTIONS og HEAD igennem for verificeret Googlebot, så beskyttelsen på skriveendpoints, og først derefter en snak om, hvorvidt de data overhovedet skal hentes i browseren.

Den sidste er den, der giver mest. Indhold, der kommer med i HTML'en fra serveren, har ingen af de her problemer. Renderingen er en ekstra fase, Google kører når der er ressourcer til det — den er ikke gratis, og den er ikke garanteret. Google har selv gennemgået crawlingens grænser i 2026, blandt andet at hentningen af en HTML-side stopper ved 2 MB, uanset hvad der står derefter.