An old version still showing after a deploy

1. Open the new deployment directly.

   In the host’s deployment list, select the completed deployment and open its own URL. Look for the identifying change. Compare it with your custom domain in a second tab. If both show the old content, inspect the source revision before blaming a cache.

2. Bypass the browser’s ordinary cache.

   On the custom-domain tab, open Chrome Inspect and select Network. With DevTools open, long-press the reload button and choose Empty Cache And Hard Reload. Compare the identifying text again.

3. Read the delivered response.

   Select the document request in Network and inspect Response for the old or new text. If the content comes from an API request, inspect that response instead. In Headers, read Cache-Control and any Age header present; record the values without assuming every host uses the same cache headers.

4. Compare a fresh visitor.

   Open the public address in an incognito window. Record which combination is stale: normal tab, fresh tab, custom domain or direct deployment URL. That comparison is the result of this check, even if a server-side cache needs a longer investigation.

WORKSThe intended public address and a fresh visit both show the identified new content.

BROKENA documented address or cache continues returning the older response.

Ranked in the order to investigate, not by claimed frequency.

1. The public domain still serves another deployment.

   Correct the production deployment or domain assignment in the host. Verify the expected source revision before changing cache rules; a cache purge cannot add code missing from the selected build.

2. The browser reused an older response.

   Review cache policy for the changed document and versioning for its assets. Use the hard reload as diagnosis, then fix how future visitors receive updates instead of requiring everyone to clear their browser.

3. A shared cache serves stale dynamic content.

   Inspect caching at the route that returns the old response. Choose freshness or no-store behavior appropriate to that data, and invalidate stale entries where the hosting system requires it.

• A service worker can also serve cached content. If the response still differs after a hard reload, ask for its cache behavior to be checked rather than repeatedly deleting all site data.
• Disabling cache on every image and script is not the recorded studio fix. Build Guard needed no-store specifically on sample routes that must show current results.

When to stop and hand it over

Stop when a fresh visitor and the deployment URL disagree but you cannot identify the cache or domain assignment involved. Provide the expected change, deployment id, response headers and the comparison results. Avoid erasing locally stored work as a troubleshooting shortcut.