To refresh a cached public page, publish the updated document, purge any shared cache that serves it, and verify the result in your Mac browser. If Google still shows old content, request a recrawl separately; refreshing your browser does not update Google’s index.

This guide is for someone maintaining a public document who needs readers to receive its revised content at the existing URL. The desktop steps use Chrome on macOS. A synthetic “Paper Shapes Guide,” changing from “Revision A: circles” to “Revision B: circles and squares,” provides a simple way to distinguish versions throughout the workflow.

Why doesn’t editing the source refresh every cached page?

HTTP invalidation removes a stored response or makes validation mandatory before reuse. RFC 9111 requires a cache to invalidate the target URI after a successful state-changing request passing through that cache, but explicitly says this does not invalidate copies globally. A publishing workflow therefore needs to account for caches beyond the editing request’s path. RFC 9111: Invalidating Stored Responses.

For the Paper Shapes Guide, make a short checklist of outputs affected by the edit. If the revised text also appears on a collection page, include that page. If only the guide changes, keep the checklist to that document. This dependency checklist is an editorial aid: start with the changed source and identify each published document that should now show something different.

Use the following sequence to choose your next action. Treat each result as a diagnostic clue rather than proof that every reader receives the same response.

What you observe What to check next
The publishing system still shows Revision A in its published output Confirm that Revision B was published or rebuilt successfully.
The published output is Revision B, but a browser network reload receives Revision A Investigate the shared cache or the document being served by the host.
A network reload shows Revision B, while an ordinary reload shows Revision A Investigate local browser caching and the response’s caching policy.
The public page shows Revision B, but Google’s indexed information remains old Use Search Console’s live test, then consider requesting indexing.

Google documents the distinction behind the last row: URL Inspection’s initial report describes the indexed version, while its live test fetches the current page. An old indexed report can therefore coexist with a corrected public document. URL Inspection tool.

Publish the changed document before purging its cache

First, record the exact public URL and the expected change. For this synthetic example, the expected sentence is “Revision B: circles and squares.” Use a distinctive sentence already appropriate for the document; the purpose is to recognize the new output without relying on how recently a tab was opened.

Publish the edit through your existing publishing system. If that system builds documents from source files, confirm that its published output includes the revised sentence. Saving source content and producing the public document are separate checkpoints in this workflow; follow your platform’s documented publishing procedure.

Then invalidate the shared cache, if one is present. The order matters: Cloudflare, for example, documents that requests after a purge fetch the resource from the origin and add it back to the CDN cache. Purging while the origin still serves the old document can refill the cache with that old document. Purge by single-file.

A documented dashboard example for Cloudflare

If your public page uses Cloudflare caching, its documented single-file purge provides a concrete browser-based path:

  1. Open the relevant site’s Cloudflare dashboard and go to Configuration.
  2. Under Purge Cache, select Custom Purge.
  3. Under Purge by, choose URL.
  4. Enter the exact public URL of each affected document.
  5. Review the entries and select Purge.

These labels and steps come from Cloudflare’s single-file purge instructions.

Check the documented boundaries before repeating a purge. Purging a redirect clears the redirect response, so purge the destination URL to refresh its content. Some custom cache keys cannot be cleared through the URL dashboard form; Cloudflare documents prefix or tag purging among the alternatives. Single-file purging also does not accept wildcards. Purge limitations and alternatives.

If you use another host or CDN, use that provider’s documented invalidation control. The Cloudflare procedure is a conditional example, not a universal interface. If your publishing service exposes no purge operation, check its documented cache lifetime and refresh behavior rather than inventing a purge URL or assuming a browser button controls its servers.

Verify the public response on your Mac

Open the page’s existing public URL in Chrome. Press Command–Option–I to open DevTools, then select Network. Chrome documents this Mac shortcut and distinguishes normal reloads, hard reloads, and cache-emptying reloads. Open Chrome DevTools.

With DevTools open, select Disable cache in the Network panel and reload the page. Chrome documents that this setting makes normal reloads avoid its cache. Keep DevTools open during the check. Reload with or without cache.

Select the main document request in the network list. Open Headers to inspect response headers and Response to examine the returned content. Look for the expected Revision B sentence in that document. Chrome’s network tutorial explains how to inspect individual requests, headers, and response content. Inspect network activity.

Record three observations: the requested URL, whether the returned document contains Revision B, and the caching headers supplied with it. This gives you a useful comparison after the purge. A successful dashboard operation is one checkpoint; receiving the intended document is the checkpoint that answers the reader’s immediate task.

Then turn off Disable cache and reload again. Compare the result with the network test. If the two disagree, retain both observations when reviewing the response policy. Repeatedly clearing the browser without recording the difference makes the cause harder to identify.

The WHATWG Fetch Standard explains why browser fetching modes matter. Its reload mode bypasses the browser HTTP cache on the way to the network and updates that cache from the response. Its no-cache mode makes a conditional request when a cached response exists. These are request behaviors, so neither constitutes a global purge of shared cached pages. Fetch Standard: request cache modes.

Choose a caching policy that fits future edits

For a public document that should be checked before each reuse, consider the response directive Cache-Control: no-cache. It permits storage but requires successful validation before reuse. Cache-Control: no-store prohibits storage. A response’s max-age specifies its freshness lifetime; must-revalidate applies after it becomes stale. These directives address different requirements. RFC 9111: Response Cache-Control Directives.

As an illustrative decision, suppose the Paper Shapes Guide changes occasionally and checking for updates on each visit is acceptable. Revalidation is a reasonable policy to discuss with the person configuring the host. If reuse without a network check is preferred, choose a freshness lifetime compatible with how long an old revision may remain acceptable, and retain a documented purge procedure for earlier updates.

Changing the policy on a newly published response cannot notify a browser that is still reusing an older fresh response without contacting the server. Existing cached copies therefore remain part of the transition. This follows from HTTP’s freshness and reuse rules; it is why a new header setting should accompany an explicit plan for existing copies. RFC 9111: Constructing Responses from Caches.

Make sure validation recognizes the revision

An ETag identifies a representation for validation. Last-Modified supplies its modification time. Have the server generate validators that reflect the published representation, including relevant changes in content assembled from other sources. RFC 9110 describes both validators and explains that entity tags can distinguish representations more reliably than modification dates in some circumstances. RFC 9110: Validator Fields.

A 304 Not Modified response tells the recipient to reuse a valid stored representation rather than transferring the document again. It is normal when the stored revision remains current. If you receive that result while still seeing Revision A after a confirmed content change, investigate which representation and validator the server evaluated. RFC 9110: 304 Not Modified.

Ask Google to revisit the corrected page

Once the public document consistently serves Revision B, inspect its complete URL in the appropriate Search Console property. Select Test live URL to examine the current page. Compare that result with the indexed report, which may describe an earlier crawl. The live test checks the current page; it does not itself establish that Google’s index has been updated. URL Inspection tool.

For an individual updated page, select Request indexing on its inspection result. You must be an owner or full user of the Search Console property. Google says crawling can take a few days to a few weeks, repeated requests do not accelerate it, and requesting a crawl does not guarantee inclusion in search results. Ask Google to recrawl your URLs.

For many updated pages, Google recommends submitting a sitemap. Keep its <lastmod> values accurate: Google says they should reflect significant changes, such as updates to the main content, rather than routine changes to a copyright date. A sitemap helps communicate changed documents; it does not purge browser or CDN copies. Build and Submit a Sitemap.

Finish with a small publication record: the affected URLs, the expected revision sentence, the published-output check, the shared-cache action, and the browser verification result. Track any Google recrawl request separately. This keeps the immediate objective—serving the revised public document—observable while leaving a clear next step wherever an older version still appears.

Sources