Google's crawlers do send HTTP request methods other than GET and POST, and the volume is tiny. Gary Illyes of Google wrote on LinkedIn that "HEAD, OPTIONS, PUT, PATCH, and DELETE account for less than 1.5% of the total number of requests all Google's crawlers send." Search Engine Roundtable reported the exchange on 7 August 2026. Illyes attributed those requests to JavaScript running on the pages being rendered, not to any deliberate crawling behaviour by Googlebot.
What Gary Illyes said
Illyes opened by explaining why he was posting at all. "For some reason I got a few questions the past few weeks about whether Google's crawlers send HTTP requests other than GET and POST," he wrote. The short answer was yes, with the under-1.5% figure attached to it.
On the cause he was blunter: "Basically it seems that some JavaScript nonsense is initiating these requests and rendering does its rendering things." Read literally, that puts the origin of the request inside the page. Client-side scripts fire during Google's rendering pass, and the renderer carries them out the way any browser would. Googlebot is not deciding to send a PATCH at your server. Your own front end is asking for one, and Google is executing the script that asks.
Where the requests come from, and where they do not
The source does not name particular scripts, libraries or frameworks, and Illyes did not publish a breakdown by method. What the post does establish is the direction of causation, which is the part that matters when you are staring at a log file. A HEAD or OPTIONS request arriving from a Google crawler is not evidence that Google is probing your endpoints. It is evidence that something on the rendered page made a request, and the renderer followed through.
That distinction changes who you talk to when the question comes up. It is a front-end question before it is a search question.
This is not a ranking story
Nothing in Search Engine Roundtable's 7 August 2026 report says these requests affect rankings, indexing or how a page is evaluated. Illyes was answering a narrow question about which HTTP methods Google's crawlers send and why. Treat it as a clarification about crawler behaviour, not as a signal to change anything about how pages are built or optimised.
What Illyes said, side by side
Here is the whole of the disclosure, taken from the LinkedIn post as reported on 7 August 2026.
| Point | What Gary Illyes said |
|---|---|
| Methods beyond GET and POST | Google's crawlers do send HEAD, OPTIONS, PUT, PATCH and DELETE |
| Share of all crawler requests | Less than 1.5% of the total sent by all Google's crawlers |
| Origin of the requests | JavaScript on the page, firing while rendering runs |
| What he ruled out | Deliberate crawling behaviour, he described it as rendering doing "its rendering things" |
| Why he posted | He had received a few questions on the subject over the previous weeks |
The report is on Search Engine Roundtable.
What this means for Thai marketers
Plenty of sites sit behind a CDN or a firewall rule set that blocks uncommon HTTP methods by default, because blocking PUT and DELETE at the edge is standard hardening advice and nobody usually goes back to check what it catches. If a JavaScript-heavy site is behaving oddly in rendering, the sequence Illyes described gives you somewhere specific to look: pull the server and WAF logs, filter for Google's crawlers, and see whether HEAD or OPTIONS requests are being refused. The source does not say this causes rendering problems. It does tell you that the requests exist and where they come from, which is enough to rule the theory in or out instead of guessing.
The 1.5% figure is also a useful reality check. If non-GET traffic from a Google crawler is showing up as a big share of your logs, the volume does not match what Google describes, and the more likely explanation is something else on the request path. That kind of log reading belongs in a technical SEO audit rather than in a rankings conversation, and it is one of the cheaper checks in an SEO programme because the data is already sitting on your own servers.
FAQ
Does this affect my rankings?
The source does not say it does. Illyes was answering a question about which HTTP methods Google's crawlers send, and Search Engine Roundtable's report makes no claim about rankings, indexing or page evaluation.
Is Googlebot trying to modify or delete things on my server?
No, on the account Illyes gave. He attributed the requests to JavaScript on the page firing during rendering rather than to deliberate crawling behaviour, describing the cause as "some JavaScript nonsense" initiating the calls while the renderer runs.
Should I unblock PUT and DELETE in my firewall?
The source gives no advice on firewall configuration, so this is a decision for your own security team. What Illyes provided is the cause: if a block is catching these requests, it is catching calls that your own page scripts initiated during Google's rendering pass.
How much traffic are we talking about?
Less than 1.5% of the total number of requests all of Google's crawlers send, across HEAD, OPTIONS, PUT, PATCH and DELETE combined. Illyes did not break that figure down by individual method.
Is this new behaviour?
The source does not say. Illyes described it as a question he had been asked a few times over the previous weeks, and gave no start date or history for it.
If your site is JavaScript-heavy and you have never checked what your edge rules do to Google's rendering requests, that check costs an afternoon of log reading. A technical SEO audit is where it usually turns up.
