HTTP Methods Checker
Sends GET, HEAD, and OPTIONS to the same URL and compares status codes, redirects, and cache/indexing headers between them.
Based on: RFC 9110 — HTTP Semantics
About this validation
Compares GET, HEAD, and OPTIONS responses for the same URL against standard HTTP method semantics, including RFC 9110's requirement that HEAD return the same headers GET would.
- Protocol / standard:
- Rules reviewed:
- Sep 1, 2026
Standards and vendor-documented behavior can change. This reflects the source as last reviewed above, not a permanent guarantee.
What This Test Checks
A HEAD request is supposed to return exactly the headers a GET request would, without a body. This tool sends both (plus OPTIONS) and reports any difference in status, final redirect destination, Content-Type, Cache-Control, ETag, Last-Modified, or X-Robots-Tag -- the kind of mismatch that otherwise requires two separate curl commands to notice.
FAQ
Why compare GET and HEAD specifically?
Some crawlers, uptime monitors, and caches use HEAD to check a page without downloading it, and assume the response matches what GET would return. When they materially differ, those tools draw the wrong conclusion.
Is it a problem if OPTIONS isn't supported?
No. Most ordinary web pages have no reason to implement OPTIONS, and its absence is not treated as an SEO or technical problem here -- it's reported for completeness only.
What does a HEAD/GET status mismatch usually mean?
Often a server-side routing or bot-protection rule that treats methods differently, or a misconfigured cache/CDN rule keyed on method. This tool reports the observed difference, not the cause.