How a faulty 304 response can hide your article correction from Google

Technical SEO · A controlled HTTP test

A revisit can leave the correction on your server

A successful request is not proof that the new HTML travelled. Test the version the returning client already has.

1. 304 normally saves a redundant downloadThe problem begins when the server calls a meaningfully changed page unchanged.
2. A newer date can conceal a broken ETag testOur controlled example returned the correction to a date-only request and no HTML to the request containing the old ETag.
3. Test template changes as well as article editsThe published HTML can change even when the article’s visible paragraphs remain untouched.

You correct a workshop announcement from 09:00 to 11:00. The page looks right in your browser. A crawler visits again. Yet that visit can end without a single byte of the corrected HTML leaving the server.

There is a mundane way to create this failure: keep sending the old version identifier after changing the content. It is worth testing because an ordinary page check can give reassuring results while a returning client follows a different path.

The empty response is usually doing useful work

An ETag is a server-supplied identifier for a representation of a resource. A returning client can send the saved value in If-None-Match. When the current version matches, the server can respond with 304 Not Modified, leaving the client to reuse its saved content. Google documents support for this mechanism and recommends ETag-based caching.

That is useful cooperation, particularly for unchanged pages. In Google’s status-code documentation, 304 tells the next processing system that the content is unchanged. Search may still recalculate other signals for the URL. An empty response is therefore neither an instruction to remove the page nor proof that all indexing activity stopped.

The question is whether “unchanged” was true. Looking only at the response code cannot establish that.

A date-only test passed while the correction stayed behind

We built a small local HTTP server and ran a controlled sequence on 6 September 2026. It served an invented workshop page, initially 150 bytes long, with an ETag of "post-42". A first request received 200 and the 09:00 announcement. A repeat with that saved tag correctly received 304 and zero body bytes.

We then changed the time to 11:00 and advanced Last-Modified from 5 to 6 September, but deliberately left the ETag unchanged. That faulty versioning rule produced the following results. This was our illustrative server, not a measurement of Googlebot or a defect found on PolymathDesk.

This difference follows a specific rule in RFC 9110: a recipient ignores If-Modified-Since when If-None-Match is present. Updating the date does not repair an incorrectly reused ETag. The request is not asking which of two signals looks newer; it has a defined order of evaluation.

For the comparison implementation, we calculated the tag from the HTML being served and obtained its own pre-edit baseline. Repeating the request with that saved tag after the correction returned 200, a different tag and the 150-byte corrected document. The complete experiment comprised eight requests, including those two initial baselines and the template-change check below.

An unchanged article field can still produce a changed page

We made one further change in the corrected implementation: the canonical link in the HTML head changed from the invented path /workshop/ to /workshops/. The announcement remained 11:00 and the stored modification date stayed the same. A request carrying the previous tag nevertheless received 200, a new tag and the revised 151-byte document.

This is the eighth request in the sequence, not an additional search experiment. It illustrates why a version identifier based only on an article field can miss output assembled elsewhere. A template, SEO setting or shared component may change the HTML without an editor rewriting the body.

The release test should ask whether the old page is still an acceptable answer, not merely whether someone pressed Update.

The HTTP standard distinguishes strong and weak validators. A strong validator changes when the representation data changes; a weak one can group acceptable equivalents. Neither gives a publisher a sensible reason to treat a wrong event time as interchangeable with its correction. Our small example uses a body hash for clarity, not as a complete caching implementation to paste into production.

Consider an HTML noindex tag as another release check. Google says it must access the page and extract the rule. If a faulty response prevents the newly added HTML from travelling, seeing the tag in your own fresh response does not demonstrate its receipt by a returning crawler. This example concerns an HTML tag; HTTP-header implementations need their own checks.

Carry the old validator into the release test

Ask the person responsible for caching to test an ordinary, non-personalised page in staging. Keep the URL and response variant fixed. The useful evidence is a before-and-after pair, not a screenshot of the latest page.

1. Save the baseline. Record the original body, ETag and Last-Modified value from a normal GET. Do not invent a validator or assume that a browser refresh sends the request you intend.
2. Make a meaningful correction. Change a fact with an unambiguous expected output. Repeat with the old tag, with the old date alone, and with both. Inspect the actual body whenever the response supplies one.
3. Exercise a second owner of the HTML. Test a relevant template or SEO-setting change while leaving the article text alone. Verify the response through the deployed delivery path, including any CDN, rather than assuming an origin result represents every layer.
4. Retain an unchanged control. A genuinely unchanged response should still be eligible for efficient reuse. Repair versioning rather than disabling useful caching indiscriminately.

Also keep delivery diagnoses separate. A soft 404 concerns what a fetched page says about its existence. A favicon change involves a declaration and a separate image resource. The AMP origin handoff concerns who serves the visit. Those checks complement this one; none substitutes for replaying the old validator against changed HTML.

A delivered correction still has a separate indexing journey

Receiving the right 200 response closes a delivery question. It does not prove Google has fetched that response, selected the URL for indexing or changed a search result. Google’s recrawl guidance describes a wait of days to weeks and no guarantee of immediate—or eventual—inclusion. Repeated requests for the same URL do not make crawling faster.

That boundary gives the investigation a useful stopping point. First establish that a returning client can receive the correction. Then investigate discovery and indexing with the appropriate evidence. Otherwise, another request to “crawl it again” may simply repeat the exchange that kept the correction out of the response.

Questions about 304 responses and article updates

Primary HTTP and Google documentation

Five primary documents checked on 6 September 2026

• Google Search Central — Crawling December HTTP caching, 9 December 2024.
• RFC 9110 — HTTP Semantics, especially sections 8.8.1, 13.1.2–13.1.3 and 15.4.5.
• Google — How HTTP status codes affect Google’s crawlers.
• Google Search Central — Block Search indexing with noindex.
• Google Search Central — Ask Google to recrawl your URLs.

Test method. Eight loopback GET requests, one invented HTML document and deliberately faulty versus body-derived validators. No browser cache, CDN, search engine or live-site configuration was part of the experiment. Counts are response-body bytes, not total network traffic. The simplified handler covers the exact requests described here, not the full HTTP standard.