Purpose-Built Templates

ZU2B Blueprints

Business in a Box

  • Purpose-built launch kits for local service businesses — website, copy, prompts, SEO, and more.
  • Local Launch Kits →

Website Widgets

  • Working features you install once and own outright — no plugin, no subscription.
  • Chat Widget — Coming Soon

Reference

ZU2B Pulse™

See what visitors experience before they leave — paste any public URL and get a plain-English performance report in seconds.

Scan Your URL Free

When a Staging Fix “Looks Fine” But Isn’t Actually Live

Field Note #175
🔬 Resolved 🔴 Advanced ⏱ 30 Minutes ✓ Observation from Experience

⚡ Quick Fix (TL;DR)

The Fix: 1. Confirm you're actually viewing staging — check the address bar, not just the page content, especially after following in-page navigation links rather than typing the URL directly.
2. Clear the full cache stack in order, not just the browser cache, before concluding a fix didn't work.
3. Audit any Custom HTML blocks (nav menus, footers, embedded links) for hardcoded absolute domain URLs. Convert same-domain links to relative paths (`/page-slug/` instead of `https://domain.com/page-slug/`) so the same code behaves correctly on both staging and live.
4. To positively confirm you're looking at a fresh, correct version of a page — not a stale cache and not the wrong environment — make a small, visually obvious test change (e.g., an oversized font on one element), save, and hard-refresh. If the obvious change doesn't appear, the problem is caching or environment, not the original fix.

Was this helpful? Thanks for the feedback!
The symptom
A Custom HTML nav block was updated on staging to fix a set of internal links. After hard-refreshing the page, the links still appeared to point to the live production URLs instead of staging.

Initial assumption
The first instinct was that the fix hadn’t actually saved, or that the wrong block instance had been edited.

Investigation
A hard refresh clears the browser’s own cache, but not necessarily what the server is handing out. Server-side caching (page cache plus a separate firewall/CDN cache layer) can continue serving a previously generated version of a page even after the underlying content changes and even after a client-side hard refresh.
 
Clearing the cache stack in order (page cache, then firewall/CDN cache) and refreshing again resolved the immediate symptom.
 
That would normally be the end of it — except a second, separate problem was hiding underneath the first.

The deeper issue
Before the cache explanation was confirmed, the page had already been checked once and looked correct. That earlier check turned out to be misleading: it had been done by clicking through the site’s own header navigation dropdown, which — unrelated to the cache issue — was pointing to hardcoded absolute production URLs (`https://zu2b.com/…`) instead of relative paths. Clicking that dropdown from staging silently navigated to the live site, which of course looked correct, because it was the live site.
 
The two problems together produced a confusing result: an early “it looks fine” check was actually looking at production, and a later “the fix isn’t showing up” symptom was actually a cache issue, not a code issue.

What to check

When a staging fix doesn’t appear to take effect:
1. Confirm you’re actually viewing staging — check the address bar, not just the page content, especially after following in-page navigation links rather than typing the URL directly.
2. Clear the full cache stack in order, not just the browser cache, before concluding a fix didn’t work.
3. Audit any Custom HTML blocks (nav menus, footers, embedded links) for hardcoded absolute domain URLs. Convert same-domain links to relative paths (`/page-slug/` instead of `https://domain.com/page-slug/`) so the same code behaves correctly on both staging and live.
4. To positively confirm you’re looking at a fresh, correct version of a page — not a stale cache and not the wrong environment — make a small, visually obvious test change (e.g., an oversized font on one element), save, and hard-refresh. If the obvious change doesn’t appear, the problem is caching or environment, not the original fix.

Troubleshooting lesson
Two independent problems can overlap and each make the other harder to diagnose. A confirmed “it looks right” check is only meaningful if you’re certain which environment you were actually looking at — and a confirmed “it’s still broken” check is only meaningful once caching has been fully ruled out first.

Tagged in :

More from the field