ETag: Has Your Page Really Changed?
Key takeaways
- An ETag is an HTTP response header used as a resource-version validator.
- A client can send a previously received ETag in an If-None-Match request header.
- For a matching conditional GET, the server can return 304 Not Modified without resending the body.
- Google's crawling infrastructure supports ETag and If-None-Match.
- Correct caching is a technical foundation, not a promise of rankings or AI citations.
What does an ETag actually tell a crawler?
An ETag gives a client a validator for a particular version of a resource. It is not an editorial quality score, a publication timestamp or an indexing receipt.
As MDN's ETag documentation explains, the server supplies the identifier and the client can use it to make a later conditional request. When the relevant representation changes, the validator needs to reflect that change according to the implementation's validation rules.
The business distinction matters. “Our server says this is unchanged” and “a search engine has processed our latest page” describe different events. A response header cannot certify the second one.
How do ETag, If-None-Match and 304 fit together?
They form a conditional-request exchange that can avoid sending an unchanged resource again. The client first receives an ETag, then can send that value back using If-None-Match.
For a matching conditional GET, the server returns 304 Not Modified without a response body, telling the client that its cached representation remains usable. This is the behaviour described in MDN's conditional-caching explanation.
A 304 is not a redirect. Nor does it mean a page is missing. It answers a particular conditional request, so it cannot be interpreted properly without the request headers that preceded it.
Our recommendation is to keep the request and response together in an investigation. A spreadsheet of status codes with the request context removed can make normal caching look like a failure, or hide a genuine validation problem.
Does Google support ETag validation?
Yes: Google's crawling documentation states that its infrastructure supports ETag and If-None-Match under the HTTP caching standard. See the HTTP caching section of Google's crawler overview.
That support does not mean every Google request will contain a validator or that a particular URL will be recrawled on your timetable. Do not turn a supported mechanism into a service-level promise.
For a business with changing service information, the useful question is narrower: does the response accurately represent whether the page has changed? If you are also investigating server availability, our HTTP 429 guide addresses a separate issue. Rate limiting and cache validation should not be diagnosed as the same problem.
What should an ETag investigation check?
Check the actual response, its validator and the result of a matching conditional request before proposing a configuration change. Start with a representative public URL, not a site-wide switch.
A review brief should ask the technical owner to:
- Capture a normal GET response, including its ETag and the returned content.
- Repeat the GET with the received validator in If-None-Match.
- Check whether the response correctly describes the resource as changed or unchanged.
- In a controlled test environment, change meaningful content and repeat the comparison.
- Compare the application response with the publicly served response if a delivery layer sits between them.
This is a proposed diagnostic sequence, not a report that those tests have been run on your site. The important evidence is agreement between what the visitor receives and what the validator claims.
Our judgement is to investigate a genuinely stale answer before celebrating a high proportion of 304 responses. Fewer transferred bytes are not useful if the system is confidently reusing the wrong version.
Does a correct ETag improve AI visibility?
A correct ETag does not, by itself, establish eligibility for an AI answer or guarantee a citation. It concerns resource validation, not editorial selection.
Google says a page must be indexed and eligible to appear in Search with a snippet to be eligible as a supporting link in AI Overviews or AI Mode. Its AI features guidance also says there are no additional special optimisations required for those features.
Keep technical access, indexing and answer selection as separate questions. Our canonical-tags guide covers another distinct layer: which URL signals the preferred version of duplicated content. A validator does not replace that decision either.
Limitations
This article explains documented protocol behaviour and proposes an investigation. It does not diagnose a live site's cache, prescribe a universal header configuration or quantify traffic gains. Google guidance does not establish the behaviour of every other search engine or AI service. Images are conceptual illustrations, not software screenshots or test results.
What should you bring to a SAGEO discussion?
Bring the affected public URLs, examples of the content change and paired request-and-response captures to a SAGEO discussion. Ask for an evidence-led diagnosis before agreeing any live change.
Any proposed cache change should name the exact target, existing behaviour, intended effect, verification and rollback. The objective is accurate delivery of current content, not simply a more attractive status-code chart.