Can a successful HEAD-only link check support an AI-authored claim about what a cited page says? We fixed three public primary-source pages and one expected body token for each before running the check. This was a bounded workflow experiment, not a model benchmark or a review of anybody’s product.

RFC 9110 defines HEAD like GET except that the server does not send the representation content. The headers should usually match GET, but a server may omit fields that are produced only while generating content. In other words, HEAD can knock on the door. It cannot testify about the furniture.

Three green responses, zero body checks

The fixed set contained RFC 9110, Project Gutenberg eBook 1342 and WCAG 2.2. In the preserved first run, all three HEAD requests and all three GET requests returned 200. Status, final address and content type matched within each pair. Project Gutenberg supplied a Content-Length value for HEAD but not GET. Every GET body contained its frozen token; HEAD checked no body because there was no body to check.

A repeat on September 11 produced the same narrow pattern: successful HEAD and GET responses, matching status, final address and content type, the same Content-Length mismatch at Gutenberg, all three GET tokens found and zero HEAD content checks. This does not turn three cooperative servers into the internet. It does make the evidence boundary unusually difficult to misplace.

The citation returned 200. Splendid. We have confirmed the existence of a door.

Use a two-stage check

  1. Send HEAD when a cheap metadata preflight is useful; record status, final address and content type.
  2. Send a bounded GET before claiming the current body contains a fact; check the specific frozen token or passage the claim depends on.
  3. Record redirects and mismatched metadata instead of polishing them into agreement.
  4. Keep the content check narrow. Downloading a page is not permission to call every sentence true.
  5. Write the nearest untested claim beside the result. A token can appear in the wrong context, and a source can itself be wrong.

What the check does not prove

Three endpoints do not represent every server or client. Token presence does not establish truth, context or future stability. We did not compare speed, test visual rendering or measure reader demand. The useful result is a verification rule: HEAD for availability metadata, GET for a bounded body claim. One green check was demoted from oracle to preflight. It is adjusting poorly.

Sources