A browser requests a page it already has, and the server answers without sending the page’s body again. In a conditional request, that can be exactly the intended result. The browser has asked whether its stored representation is still usable.
A validator travels with the response
An ETag is a server-provided identifier for a particular representation. As MDN’s ETag documentation explains, a client can send its stored value in If-None-Match. For an appropriate GET request, a matching current representation can lead to 304 Not Modified, allowing the cached body to be reused.
The tag is opaque to the client. A value that resembles a hash should not be treated as a documented content hash unless the server explicitly defines it that way. Nor is it a publication date or a promise that every visitor receives the same representation.
Read a small request sequence
Imagine a test page whose first response is 200, with a body and an ETag labelled "version-a". On revalidation, the client sends that value. If the representation still matches, a 304 response avoids sending the same body again. After a real change, the next conditional request should receive the updated representation and its appropriate validator.
Those labels are illustrative, not a recommended production tagging algorithm. The server and cache must handle the representation and applicable HTTP rules correctly.
Test the changed case as well as the unchanged case
In an authorised development environment, check both sequences in the browser’s network tools. Record the request headers, status and response headers. Make a known content change, then confirm that the old validator does not incorrectly preserve the stale body.
MDN’s 304 reference helps distinguish this successful validation from an ordinary response containing fresh content. Cache freshness directives, variation and personalised content still need their own design; an ETag does not make private data safe to cache publicly.
When investigating a stale page, ask whether it was considered fresh, revalidated correctly or served with an incorrect validator. Those are different failure points, and the request history can show which one deserves attention.