You correct an important statement in an article. Your browser already shows the update, but you want to know whether a crawler can receive it on its next visit. An ordinary page request answers only part of that question. The server may respond differently to a visitor with no stored copy and a client asking, “Has anything changed since my last visit?”
That second request deserves a test. When the content is unchanged, 304 Not Modified is useful. After a meaningful revision, an incorrect confirmation can cause a client to keep using its old copy. The fault may sit in a content validator, a cache rule or the delivery path between your CMS and CDN.
The workflow below tests that delivery contract. Establishing whether Googlebot actually encountered a fault requires separate request evidence.
What a 304 response confirms
Among the HTTP status codes relevant to SEO, 304 has a specific job. For an appropriate conditional request, it confirms that an existing representation can be reused instead of transferring another body. The client therefore needs a previously stored response.
Google documents its support for ETag and Last-Modified in its explanation of HTTP caching for crawlers. This is an efficient retrieval mechanism. One 304 response does not establish an indexing fault or a ranking benefit.
You will usually encounter two header pairs:
| Server sends | Client sends on a later request | Question being tested |
|---|---|---|
ETag: "article-v1" | If-None-Match: "article-v1" | Is the stored representation still valid? |
Last-Modified: Wed, 21 Oct 2026 08:00:00 GMT | If-Modified-Since: Wed, 21 Oct 2026 08:00:00 GMT | Has this representation changed since that time? |
These values are examples. An ETag might be derived from a content revision. There is no single required generation algorithm. The W/ prefix marks a weak validator, which represents semantic equivalence rather than identical bytes. MDN explains the ETag variants.
That distinction matters when choosing your test. A changing technical timestamp can alter HTML bytes without changing the useful content. A corrected delivery condition, a new paragraph or an updated indexing instruction is a more informative test case.
When this check is worth doing
Test conditional delivery when an important revision is saved in the CMS but different retrieval paths appear to show different versions. A new CDN, revised cache rules or a deployment that changes content revision handling can also justify the check.
A stale search result alone does not establish this problem. Publication, crawling and processing an update are separate events. A test request can check delivery. It cannot force Google to revisit a URL or establish how Google will process it.
Keep crawl budget in proportion, too. Google's crawl-budget management guide is particularly relevant to large or frequently changing websites. On a small blog, correct caching is sensible technical maintenance. It does not automatically require a major optimization project.
Start before changing the page
Choose a public HTML page that you are allowed to edit. Use its final URL without a redirect. Record the language, hostname and time. Keep these conditions consistent across requests. A different hostname or language can mean you are comparing different representations.
The examples use the curl program. On Windows, use curl.exe explicitly if your shell assigns another meaning to curl. These are GET requests. A check using only HEAD gives you no response body in which to identify the actual content version.
1. Save the starting response and its ETag
bashcurl -sS -D before.headers -o before.html --etag-save before.etag -H "Accept-Encoding: identity" -w "%{http_code}\n" "https://example.com/guides/delivery-times"
Replace the example address with your page. Inspect the status, headers and saved HTML. For an ordinary public destination page, the starting point should be 200 with the actual article content. Resolve a login response, error page or redirect before running the cache test.
Check that before.etag contains a value. When the response has no ETag, curl can create an empty file. In that situation, this command has not prepared a valid ETag comparison. Check for a useful Last-Modified header instead, or discuss validator support with the developers. A missing ETag is not, by itself, an SEO error.
The curl documentation for ETag comparisons explains the file options. Keep before.etag unchanged. You will need that old value again after publishing the revision.
2. Send the same validator before editing
bashcurl -sS -D unchanged.headers -o unchanged.html --etag-compare before.etag -H "Accept-Encoding: identity" -w "%{http_code}\n" "https://example.com/guides/delivery-times"
If the representation has not changed and the server evaluates the condition accordingly, a bodyless 304 fits the expected behavior. A full 200 response may mean conditional delivery is not being used on this path. Investigate that separately from the question of whether updates are being missed.
Use different output files and always read the response status. The existence of an older HTML file does not establish which body, if any, the latest request transferred.
3. Publish an identifiable content change
Change a specific sentence that you can find in the subsequent HTTP response. In this hypothetical example, “Dispatch within two working days” becomes “Dispatch within five working days.” You are testing a meaningful revision rather than an invisible formatting adjustment.
After publication, first run an ordinary GET without the old validator. Is the revised sentence present in the delivered HTML? If it is absent, start with the publication and cache-invalidation path. A cache can serve outdated content with 200, too. That does not require a faulty 304 mechanism.
4. Send the old ETag after the update
bashcurl -sS -D after.headers -o after.html --etag-compare before.etag -H "Accept-Encoding: identity" -w "%{http_code}\n" "https://example.com/guides/delivery-times"
After a meaningful change to the representation, the old validator should no longer confirm reuse of the old version. For a successful ordinary destination page, expect 200 with the revised content. Locate the corrected sentence in the body and record the new ETag, if supplied.
A 304 now deserves investigation when you have established that the comparison concerns the same representation and a meaningful published change. Repeating the same request ten more times adds little. Save the conflicting responses and identify the layer responsible for them.
Test Last-Modified separately
If the starting response included a modification time, send that old value in a separate request:
bashcurl -sS -D modified.headers -o modified.html -H "If-Modified-Since: Wed, 21 Oct 2026 08:00:00 GMT" -H "Accept-Encoding: identity" -w "%{http_code}\n" "https://example.com/guides/delivery-times"
Copy the date from your own original response. The date above is illustrative, not a measured observation. Do not accidentally combine this test with the saved ETag if your aim is to isolate the timestamp logic. Under RFC 9110's conditional-request rules, If-None-Match takes precedence over If-Modified-Since.
Last-Modified needs to describe the selected representation meaningfully. A date that changes on every request can cause unnecessary transfers. A date that remains fixed through relevant edits can contribute to an incorrect confirmation. MDN describes this header and its limitations. If the page changes very frequently, developers should also review the time precision of the underlying modification logic.
Separate the CDN from the origin
Several systems may answer between the request and your CMS. Testing only the application can therefore miss the public behavior. For the same test case, compare the public response with an internally approved origin test. Developers can make that comparison without disabling the website's security controls.
Use the observed difference to choose the next investigation:
| Observation | What to investigate next |
|---|---|
| Even the ordinary public GET contains the old sentence | Publication, HTML caching and invalidation |
| Public GET is current, but the old ETag receives 304 | Validator generation and evaluation on that path |
| Origin returns the revision while the public URL returns the old version | CDN rules, cache keys and header forwarding |
| New HTML arrives, but the search result still appears outdated | Google's retrieval time and subsequent processing separately |
Adding a random query parameter is not sufficient counterevidence. It may request a different cache variant. A logged-in browser or preview cookie can also make a poor comparison for an anonymous crawler request. Keep the original retrieval path in view.
For a suspected CDN fault, also record any cache-status or age information supplied with the response. Available headers and their meanings depend on the provider and configuration. Such information can help identify the answering layer. It cannot replace checking the content actually delivered.
After a correction, repeat both test cases. Returning 200 for every request might deliver the revised page, but it does not establish correct reuse of an unchanged version. Likewise, a valid 304 before publication does not establish that changes will get through. The useful pair is unchanged content being reusable and meaningfully revised content being transferred again. Keep the hostname, URL and request conditions the same for both checks.
What this establishes about Googlebot
Your GET demonstrates what your test client received under the recorded conditions. Even a copied user-agent string does not prove that Googlebot visited. To investigate the actual event, you need appropriate server or CDN logs with the time, URL and response status. Identifying genuine Google requests also requires reliable bot verification.
You can then ask more useful questions. Did the request happen before or after publication? Which layer answered? Does the evidence identify a delivery fault, or does further indexing need investigation? “Crawled, currently not indexed” describes a different diagnostic problem from an inappropriate cache validator.
For a developer handoff, a small evidence package is enough: starting HTML and headers, the old validator, publication time and the response after the revision. Add the exact sentence that should have changed. This makes the fault reproducible instead of asking someone to infer a cause from an outdated search preview.
Include the result in your technical review process. Crawl Foundry's Site Audit area provides context for investigating the affected URL. Establish whether the caching correction works with the additional request sequence described here. Our article on prioritizing and verifying audit findings explains how individual checks fit into a team's work.
The test is complete when an unchanged representation can be reused correctly and a meaningful revision is delivered again to a client presenting the old validator. Whether and when that revision appears in search remains a separate observation.