Googlebot stuurt ook HEAD, OPTIONS, PUT en DELETE

Googlebot stuurt niet alleen GET- en POST-verzoeken. Gary Illyes bevestigde op LinkedIn dat Google's crawlers ook HEAD, OPTIONS, PUT, PATCH en DELETE gebruiken, samen goed voor minder dan 1,5 procent van alle requests die Google verstuurt. De oorzaak is JavaScript. Twee dingen zijn het checken waard: je serverlogs en de regels van je firewall.

Wat Illyes precies schreef

De aanleiding was volgens hem dat hij de afgelopen weken meerdere keren de vraag kreeg of Google's crawlers ook andere methodes dan GET en POST versturen. Zijn korte antwoord: ja, dat doen ze, maar HEAD, OPTIONS, PUT, PATCH en DELETE zijn samen minder dan anderhalve procent van het totaal.

De verklaring is prozaïsch. Het is JavaScript dat die requests afvuurt terwijl de renderer zijn werk doet — Illyes noemt het zelf in wat minder vleiende bewoordingen. Er zit dus geen aparte Google-controle achter, geen nieuw crawlgedrag en geen verborgen signaal. Het is jouw eigen front-end die door Google wordt uitgevoerd. Barry Schwartz signaleerde de post op 7 augustus 2026.

Nee, dat is geen aanval op je site

Herkenbaar scenario: je securityplugin of hostingpartij slaat alarm over OPTIONS- of DELETE-requests vanaf Google-IP's, en iemand concludeert dat er iemand aan je site zit te morrelen. Dat verhaal kun je nu afsluiten.

Met één slag om de arm: controleer wel of het echt Googlebot is. Een user-agent is in drie seconden vervalst. Verifieer via een omgekeerde DNS-lookup of tegen de IP-lijsten die Google publiceert voordat je op basis van "het is Google toch" een regel versoepelt.

De echte valkuil zit in je WAF

Hier wordt het praktisch. Veel firewall-profielen en hardening-handleidingen staan standaard alleen GET, POST en HEAD toe en blokkeren de rest met een 403 of 405. Klinkt netjes, maar OPTIONS is de preflight van een cross-origin request. Haalt jouw pagina tijdens het laden data op van een ander (sub)domein of een API, dan gaat daar eerst een OPTIONS-verzoek overheen.

Blokkeer je dat, dan faalt die fetch in de renderer van Google. Jij ziet in je browser een volle pagina, Google krijgt een lege. Het symptoom is verraderlijk: content die voor bezoekers prima laadt maar niet terugkomt in de gerenderde HTML van de URL-inspectie in Search Console. Blijven zulke pagina's vervolgens hangen, dan zoek je de oorzaak al snel bij crawled – currently not indexed terwijl er technisch iets anders speelt.

Wat je juist niet moet doen

Dit is geen vrijbrief om PUT, PATCH en DELETE publiek open te zetten. Die methodes schrijven en verwijderen; ze horen achter authenticatie, punt. Dat Google's renderer ze afvuurt betekent alleen dat jouw JavaScript ze afvuurt, en een nette 405 daarop is precies goed. Er gaat niets kapot aan je indexering doordat een DELETE wordt geweigerd.

Alleen OPTIONS verdient een bewuste keuze, en alleen als je pagina's echt cross-origin data ophalen. Doet jouw site dat niet, dan verandert er niets en kun je alles laten staan zoals het staat.

In vijf minuten gecheckt

Filter je access-log op alles wat geen GET of POST is en groepeer op user-agent en statuscode. Zie je 403's of 405's op OPTIONS vanuit Google's ranges, dan heb je iets te onderzoeken. Zie je alleen HEAD-requests langskomen, dan is er niets aan de hand: dat is normale crawlerhygiëne.

Draai daarna één URL-inspectie in Search Console op een pagina die zwaar op JavaScript leunt, en leg de gerenderde HTML naast wat je in je browser ziet. Ontbreekt er een blok, dan weet je waar je moet kijken.

Kleine relativering tot slot, want anders wordt dit groter dan het is: bij minder dan anderhalve procent van de requests raakt dit de meeste sites nooit. Het speelt vooral bij zwaar client-side gerenderde pagina's met een strak dichtgetimmerde firewall. Draai je een gewone WordPress- of shopsite, dan ligt je winst eerder bij crawlcapaciteit en serversnelheid en bij het aantal routes dat naar je pagina's leidt — dat laatste is precies waar relevante plaatsingen hun werk doen.