HEAD says a page works but GET fails: compare the request readers actually use

Write down what each check is supposed to prove

Separate three questions: did the request receive an acceptable response, did it retrieve the expected page content, and could a visitor complete the intended task? Decide which question the monitor answers before treating its result as a statement about the entire site.

For the workshop page, a header probe may be useful as one observation, but the acceptance condition should include the public workshop title, relevant details and a functioning route to the booking information. If the page is intended to be public, an authenticated administrator view is not an equivalent acceptance check.

The uptime monitoring guide covers monitoring purpose and alert ownership. Here the narrower job is to explain why two request methods, or two different request contexts, produce apparently conflicting evidence.

Understand the body evidence that HEAD leaves out

RFC 9110 defines HEAD as like GET except that the server must not send response content. It recommends the corresponding GET header fields while allowing omissions for fields determined during content generation. Do not interpret that recommendation as a guarantee of identical implementation behavior.

The practical limit is straightforward: a body that was never received cannot be inspected by that check. A positive status alone does not show whether the workshop description is present, whether the content is an account screen, or whether the page contains an application error message.

Keep a header result in the evidence record rather than discarding it. It can still help compare destination, content type or another observed field. Label its scope precisely so a later reviewer does not mistake it for a captured public page.

Read metadata without turning absence into a diagnosis

MDN’s HEAD reference explains that a Content-Length field, when supplied, describes the corresponding GET body rather than a body sent with HEAD. Its absence is not enough to conclude that the page is empty or broken.

Record observed values rather than requiring every response to match an invented template. If a field differs, ask whether it is relevant to the specific failure and whether the compared requests reached the same representation. A collection of unrelated header differences can distract from an obvious wrong destination or unexpected body.

For the workshop page, content type and final destination may be more immediately informative than a missing size field. Preserve the full authorized diagnostic privately when needed, but put only necessary, non-sensitive observations into a public issue or shared ticket.

Inspect the retrieved representation

MDN defines GET as requesting a representation of a resource. Receiving that representation is evidence about retrieval; it does not automatically prove successful rendering, loaded dependencies or a completed interaction.

Compare the returned content with a few distinctive expectations. For the workshop, use its title and a meaningful sentence from the details rather than a generic word such as Welcome. Check whether the body is the intended document, an access page, a redirect explanation or an error presented inside an otherwise successful response.

If the original reference is wrong, use the broken-link audit guide to decide how to correct it. Do not delete a useful reference just because one diagnostic method behaves differently; establish the intended destination and reader result first.

Follow the browser journey separately

Open the same public address in the appropriate anonymous browser context and inspect the affected task. A correct initial document does not close an issue where an essential resource fails or a button cannot complete its next step. Record the first point where the observed journey diverges from the expected one.

Use desktop and mobile views when the failure depends on navigation layout or responsive behavior. Keep browser observations separate from server-request evidence. A screenshot supports what was visible at that moment; it does not replace the request details needed to diagnose a method-specific difference.

The HTTP 405 method guide applies when a method is refused. Do not enable every method as a shortcut. Correct the contract for the intended endpoint while preserving the distinction between a read check and an action that changes records.

Close the discrepancy with evidence for the intended claim

Propose a before-and-after comparison of the same address, methods and access context. Keep the header-only result, the expected GET body observations and the browser task outcome as separate entries. Include any unresolved difference instead of describing one successful check as proof that everything is fixed.

These are proposed exercises, not tests performed on a reader’s website. The investigation is complete when the chosen monitor has a clearly stated purpose and the actual public journey meets its own acceptance conditions. Agreement between two status codes alone is a smaller claim.