Read the conditional request and the suitable stored representation together, then compare a controlled current response before changing cache configuration.
HTTP 304 can appear while a page loads successfully. It is part of a conditional read: the responder says a previously stored representation can still be used, rather than sending that content again. Investigate the request and stored response together before calling the empty network body a missing page.
Imagine a fictional workshop website changing its opening hours. An editor sees the old hours and notices 304 in the browser’s Network panel. That status is evidence about one request, but it does not identify which version the editor stored, which layer answered or whether the visible hours came from that resource.
Identify the request that actually contains the disputed information
Record the exact URL, method and visible mismatch. Is the old text in the main page, a separately loaded data response or an image? A 304 for the site icon does not explain old opening hours. Start with the resource responsible for the disputed information, not the first unfamiliar status in the panel.
For the workshop, note the intended new hours and a harmless revision marker in a test environment. Ask which response should contain each. If the page shell and opening-hours data are separate, follow both requests without assuming they share one cache policy or update schedule.
The WordPress changes and cache guide covers locating cache layers and choosing scoped invalidation. This guide follows the narrower validation exchange and the stored representation it refers to.
Understand what 304 says and what it does not carry
RFC 9110 defines 304 for conditional GET or HEAD requests that would otherwise have produced 200. The condition allows the client to use an existing valid representation instead. The 304 response ends after its headers and cannot contain content or trailers; it is not a new page body or an instruction to visit another page URL.
The practical implication is to find the earlier content. For the workshop, compare the stored representation containing the old hours with the current request’s validation information. An empty 304 body is expected within that exchange, so its absence is not itself a content-generation failure.
Do not use one 304 as proof that every part of the site is current. It concerns the selected resource and condition at that point in the request chain. A successful validation decision can still be based on an unintended version selected upstream.
Compare the validator sent with the response that was stored
MDN’s 304 reference describes conditional requests using If-None-Match or If-Modified-Since. It also notes that developer tools can generate additional requests to expose cache behavior. Record the observed conditions instead of assuming every repeated entry represents a separate ordinary reader navigation.
Ask the authorized developer to capture the relevant request headers, response headers and previously stored body in a controlled environment. Keep the validator as an opaque comparison value unless the server’s documentation defines its meaning. Do not infer a release date or a reliable content checksum from how a tag happens to look.
For the workshop, the useful question is whether the validator associated with the stored old hours is being checked against the intended current representation. If the team cannot identify the stored response, it does not yet have enough evidence to conclude that the validation was correct or incorrect.
| Observed journey | Content evidence to locate | Question for the investigation |
|---|---|---|
| Stored content reused without a request | The previously saved representation | Which version was already available? |
| Conditional request receives 304 | Stored content plus validation headers | What representation was validated? |
| Full GET receives 200 | The returned representation body | Does this contain the intended revision? |
| Visible page still differs | Rendered text and its responsible resource | Is another resource or stage involved? |
Locate the layer answering the validation request
RFC 9111 describes cache validation and the selection of suitable stored responses for updating after 304. The retained content and new metadata work together. Reuse is not simply permission to attach any old body to any 304 that appears nearby.
Draw the workshop’s actual request path using the services the team operates: browser, any intermediary cache and application. Identify where the conditional request was answered, using available authorized logs and response information. Do not add an imagined CDN or proxy merely because it is a common website component.
Compare one layer at a time. If the application produces the new hours but an intermediary supplies an earlier representation, investigate that boundary. If the full application response itself still has the old hours, changing browser caching cannot repair the underlying publication or data problem.
Make a controlled current-versus-reused comparison
In a safe test environment, first obtain and retain the expected full representation. Repeat the relevant read with its actual validator and inspect the response outcome. Then make a harmless content change and repeat the comparison. Record both the body version and the validation decision, rather than only counting status codes.
The proposed result is consistency: unchanged content can be reused when validation permits it, while changed content must not be represented as the old body merely because a validator was mishandled. An implementation may choose a full response; the test should not require 304 for every unchanged navigation.
Use the HEAD-versus-GET diagnostic guide when body evidence is missing. A header-only inspection can help identify an exchange, but a controlled full GET is the relevant comparison for the actual page content.
Keep any correction limited to the failing boundary
Do not disable all entity tags or clear every cache as the opening move. Those changes can hide the observed sequence and affect resources unrelated to the workshop’s hours. Preserve the evidence, identify the incorrect version or validation decision, and choose the smallest correction that addresses it.
If several users receive different results, keep their authorized request contexts separate. The private-page cache guide covers personalized-response risks. This public-hours example does not justify merging account-specific content into one shared representation.
After a correction, repeat the previously failing journey with the intended resource. Check the visible hours as well as headers. A different status is not success when the page still presents the wrong information.
Close the issue with representation-level evidence
Keep the exact resource, stored body version, condition, responding layer and observed final page together. The checks described here are proposed; no live cache or deployment was measured for this article.
Close the issue when the selected representation and visible content match the intended revision, and repeat reads make consistent reuse or replacement decisions.304 is then understandable evidence of normal validation, rather than a status to remove simply because it contains no page body.
Sources and verification
Editorial review 2026-10-15. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- RFC 9110: 304 Not ModifiedChecked Conditional GET/HEAD semantics and a response without content.
Limits: The status alone does not prove the latest deployment was selected. - RFC 9111: cache validationChecked Validation and updating a suitable stored response.
Limits: A matching stored representation must be identified. - MDN: 304 Not ModifiedChecked Conditional validator headers and developer-tool request caveat.
Limits: A network-panel entry is not a complete cache or rendering diagnosis.