For an editable public document, choose revalidation when readers should get current content while unchanged pages remain reusable. Choose no-store when your publishing requirement specifically excludes HTTP cache storage.

This guide is for someone managing a public document from a Mac desktop. The task is to choose a response policy, then check it in Terminal using a synthetic page containing only neutral text, such as “Shape guide, version one.” You need a test page and access to its hosting configuration, or a provider who can configure its response headers.

Which caching policy fits the document?

Start with the publishing requirement. Does the page need a check before every reuse, can an existing copy remain usable for a short period, or must HTTP caches avoid storing the response? These are different requirements under RFC 9111: HTTP Caching.

Publishing requirement Candidate response header Meaning for an HTTP cache
Check before every reuse Cache-Control: no-cache Storage is allowed; reuse requires successful validation.
Allow a short freshness window Cache-Control: max-age=300, must-revalidate Reuse is allowed while fresh; once stale, successful validation is required.
Exclude response storage Cache-Control: no-store The cache must not store the response or use it for another request.

The five-minute window is an illustrative choice, not a recommended default. Select it only if your document can tolerate that reuse interval. must-revalidate alone does not require a check while a response is fresh. These distinctions follow RFC 9111’s response directives.

For the synthetic shape guide, suppose a correction from “three examples” to “four examples” should be checked on the next retrieval. Start with no-cache and a working validator. If your requirement instead says that HTTP caches must not retain this document response, select no-store. Frequent editing, by itself, does not establish that storage must be excluded.

Write the requirement before changing settings: “Check the document before reuse,” for example. This gives you a concrete acceptance criterion and prevents a setting’s name from deciding the policy.

What makes revalidation work?

A validator identifies the version the client already received. An ETag supplies an entity tag; Last-Modified supplies a modification timestamp. RFC 9110 recommends sending available validators for successful document retrievals, preferring both a strong entity tag and a modification date. See HTTP Semantics, validators and 200 OK.

These are illustrative response-header fields, not server configuration code. They assume the response body is the synthetic shape guide:

Cache-Control: no-cache
ETag: "shape-guide-v1"

On a later request, a client can send If-None-Match: "shape-guide-v1". If that tag still matches the selected representation, the conditional GET receives 304 Not Modified, without a response body. If it no longer matches, normal processing can return the changed document. The rules appear in RFC 9110’s conditional-request section.

The implementation requirement is that the validator tracks the document version. Do not copy the illustrative tag into a permanent configuration and leave it unchanged after edits. Ask your hosting system to generate validators consistently and evaluate incoming conditions.

How much can an unchanged response avoid transferring?

Consider an explicitly illustrative calculation: a document body is 80,000 bytes, and a client retrieves it 100 times without any edits. One full response followed by 99 successful validations transfers 80,000 body bytes instead of 8,000,000 body bytes—a difference of 7,920,000 bytes.

That calculation excludes headers, compression, connection overhead and any application work. It describes body transfer only. Google’s HTTP caching explanation describes the same exchange: a matching validator permits a bodyless 304, and the client uses its previously received content. Actual savings depend on how often documents change and how clients make requests.

Where should you configure the policy?

Configure the HTTP response generated by your hosting service, server or content delivery layer. The header examples above describe the required result; they are not universal commands for a publishing platform.

If your editor only lets you change document text, a markup workaround does not provide equivalent control. The WHATWG HTML Standard does not define Cache-Control as a supported http-equiv pragma, and explains that these pragmas are largely separate from HTTP headers. See HTML Standard: Pragma directives.

The supported path is to use your host’s documented response-header configuration or ask the provider to implement it. Google’s crawler overview also directs publishers to their hosting or content management provider for HTTP caching implementation. A useful request names the document, chosen policy and validator behavior, then asks how to verify the delivered response.

Changing a JavaScript request option has a narrower scope. WHATWG defines a Fetch no-store cache mode that behaves as though there is no HTTP cache, while no-cache makes a conditional request when an appropriate cached response exists. These modes govern that request; setting one in a script does not configure the document’s server response policy. See the Fetch Standard’s cache modes.

How can you test revalidation from a Mac?

Use a synthetic public test document that you can edit. Before starting, make its content “Shape guide, version one” and arrange for the chosen response headers to be delivered. Keep this test separate from real document content so you can make an obvious, reversible change.

Open Terminal and run the following commands in the same session. They prompt for your actual test URL and the validator returned by that page; no example address is assumed. Stop after the first request if it fails, redirects, or returns something other than the intended document response.

printf '%s\n' 'Paste the full URL of your synthetic public test page:'
IFS= read -r page_url

curl --silent --show-error --connect-timeout 5 --max-time 20 \
  --dump-header - --output /dev/null --url "$page_url"

printf '%s\n' 'Paste its ETag value exactly, including quotes:'
IFS= read -r page_etag

check_page() {
  curl --silent --show-error --connect-timeout 5 --max-time 20 \
    --dump-header - --output /dev/null \
    --header "If-None-Match: $page_etag" --url "$page_url"
}

check_page

The commands make GET requests, display received headers and deliberately discard the response body. The timeouts bound connection and transfer time; errors remain visible. These options are documented in the curl manual. The first request should reveal your chosen Cache-Control value and an ETag. If no tag is present, do not enter a fabricated value: resolve validator support first.

Copy the complete tag value, including surrounding quotation marks and any W/ prefix. With an unchanged matching representation, the conditional request should return 304. A 304 cannot contain content and must include specified metadata that would accompany the equivalent 200 response, including ETag and Cache-Control when applicable. See RFC 9110: 304 Not Modified.

Test an edit while keeping the old validator

Change the synthetic document to “Shape guide, version two: four examples.” After the update reaches your test page, keep the old tag in the same Terminal session and run this continuation command:

check_page

For this deliberately changed document, expect the new body to be available through a normal successful response and an updated validator. Next, repeat the initial commands using the new tag and check the unchanged version again. This tests both branches: recognizing a change and recognizing no change.

Observation Next diagnostic step
Initial request returns a redirect Use the document’s final URL and restart the test.
Unchanged conditional request returns 200 Check that you copied the tag correctly and that conditional handling is enabled.
An intentional content edit still produces 304 with the old tag Investigate update delivery and validator generation before relying on revalidation.
Delivered policy differs from your configuration Inspect the hosting and delivery settings responsible for the final response.
Request times out or fails Resolve the retrieval failure before interpreting cache behavior.

These are diagnostic leads, not proof of a particular cause. The procedure tests the response and conditional exchange; it does not establish how every browser will behave. When evaluating no-store, inspect that response directive directly. A conditional request you construct manually is not a test of whether a browser stored a response.

What does this mean for Google Search?

Google’s current crawler documentation supports ETag with If-None-Match and Last-Modified with If-Modified-Since. It recommends ETag for Google’s crawlers and says that individual crawlers may use caching differently. See Overview of Google crawlers and fetchers.

That page also says other HTTP caching directives are unsupported, while separately suggesting max-age as a possible recrawl hint alongside Last-Modified. Given that documented boundary, do not assume your browser-oriented no-store or no-cache policy dictates Googlebot’s fetching schedule. Implement and test validators as the documented conditional-retrieval path.

Google explains that a 304 signals unchanged content to its processing systems; for Search, it otherwise has no effect on indexing. A successful 200 also does not guarantee indexing. These are documented in How HTTP status codes affect Google’s crawlers.

Choose the policy that matches your document requirement, then retain the test evidence: the initial response, an unchanged conditional response and a response after an intentional edit. For a public document that needs a check before reuse, revalidation is a practical starting point. Select no-store when excluding HTTP cache storage is itself the requirement.

Sources