The official WordPress Browser Extension includes a cache-busting reload shortcut. A changed query can bypass one page-cache key while a CDN ignores the query, a service worker returns an older response, HTML still references an old hashed asset, or the application serves stale database content. Calling the page fresh after one reload can hide the actual owner of the stale result.
Use this for WordPress editors, agencies, support teams, headless frontends, CDNs, page-cache plugins, service workers, and sites with generated CSS or hashed JavaScript.
Quick answer
Capture the normal request and the extension reload request side by side. Record final URL, query, request cache mode, status, Age, Cache-Control, ETag, Last-Modified, Via, service-worker source, HTML hash, asset URLs, asset hashes, and visible content marker. Compare origin and edge only when authorized. The test passes when the changed layer is identified, not simply when the browser happens to show new pixels.
What to check first
- Record browser, extension version, login state, normal URL, cache-busting URL, and visible content marker.
- Capture request and response headers for HTML, generated CSS, JavaScript, images, API calls, and service-worker responses.
- Compare CDN Age, validator movement, content hash, asset hash, cache key, and query-string forwarding behavior.
- Test signed-out, signed-in, private window, another device, and a direct public fetch without reusing browser state.
- Purge or revalidate only the owning layer, then repeat the normal URL without the cache-busting query.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Capture ordinary and cache-busting requests before changing cache state. | Record browser, extension version, login state, normal URL, cache-busting URL, and visible content marker. | Clean and cache-busting requests produce explainable header and hash differences. |
| Identify the layer whose validators, hash, or content marker is stale. | Capture request and response headers for HTML, generated CSS, JavaScript, images, API calls, and service-worker responses. | The clean URL returns current content and current hashed assets. |
| Correct query forwarding, invalidation, service-worker, or asset-manifest behavior at that owner. | Compare CDN Age, validator movement, content hash, asset hash, cache key, and query-string forwarding behavior. | Signed-in and signed-out behavior matches the documented cache policy. |
| Purge only the affected URL and required assets. | Test signed-out, signed-in, private window, another device, and a direct public fetch without reusing browser state. | No test query or duplicate URL appears in canonical tags or the sitemap. |
Why this usually happens
- Different cache layers use different keys and query-string policies.
- A fresh HTML document can still point to an unavailable or stale asset hash.
- Signed-in bypass rules can make support results differ from visitor results.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
curl -sS -D normal.headers -o normal.html https://example.com/page
curl -sS -D bust.headers -o bust.html 'https://example.com/page?wp-cache-bust=fixture'
shasum -a 256 normal.html bust.html
rg -o 'src="[^"]+|href="[^"]+' normal.html
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Page cache | Query changes cache key | New HTML and stable canonical |
| CDN edge | Query ignored | Age and ETag expose stale object |
| Service worker | Response marked from worker | Updated worker returns current shell |
| Hashed asset | HTML points to old bundle | Current HTML references current hash |
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Capture ordinary and cache-busting requests before changing cache state.
- Identify the layer whose validators, hash, or content marker is stale.
- Correct query forwarding, invalidation, service-worker, or asset-manifest behavior at that owner.
- Purge only the affected URL and required assets.
- Verify the clean URL from signed-out browsers and direct public requests.
Decision rule
Declare the page fresh only when the clean URL, public HTML hash, current asset references, visible content, canonical, and intended cache headers agree without relying on the test query.
Production verification checklist
- Clean and cache-busting requests produce explainable header and hash differences.
- The clean URL returns current content and current hashed assets.
- Signed-in and signed-out behavior matches the documented cache policy.
- No test query or duplicate URL appears in canonical tags or the sitemap.
Field notes
- Preserve the canonical clean URL and never add test queries to the sitemap.
- Do not invalidate an entire distribution before identifying the stale layer.
- Retest from the ordinary URL after every repair.
Questions teams ask during testing
Can this be tested on staging?
Start on staging with production-like versions, roles, data volume, cache, browser behavior, and integrations. Finish with one controlled production fixture when the result depends on the real CDN, email provider, worker clock, crawler response, or browser storage.
What evidence should be retained?
Keep exact versions, stable IDs, UTC timestamps, sanitized requests or logs, expected result, actual result, decision, and final verification. Redact customer data, cookies, secrets, order keys, and full advertising identifiers.
When should the change be rolled back?
Roll back when a revenue, privacy, accessibility, security, publishing, or lead path fails and the cause cannot be isolated inside the approved maintenance window. Preserve the failed fixture before rollback.
Mistakes to avoid
- Do not change several production layers at once. Preserve the failing evidence and isolate one variable per test.
- Do not treat a successful request, quiet log, or correct screenshot as proof that the complete user outcome is correct.
- Do not leave debug logs, test records, broad credentials, temporary roles, or browser overrides active after verification.
- Do not close the work without recording versions, fixture IDs, UTC timestamps, owner, result, and rollback point.
What to tell the client or owner
Give the owner the affected versions, exact fixture, stable IDs, UTC timeline, before and after evidence, decision, rollback point, unresolved risks, and next review date.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, trace a stale WordPress page.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Map cache-bust queries through the CDN
Extend the header comparison with the WordPress Browser Extension CDN query-forwarding matrix so cache-key inclusion, origin forwarding, attribution parameters, signed URLs, and the final clean canonical object are explicit.
Helpful references