The official WordPress Browser Extension can reload with a cache-busting query. CDNs may include all queries in the key, forward but ignore them, strip them, whitelist only marketing parameters, normalize their order, or cache the resulting URL separately. A successful fresh screen can hide duplicate edge objects, unnecessary origin requests, tracking pollution, or a clean URL that remains stale.
Use this for WordPress sites behind CloudFront, Cloudflare, Fastly, hosting caches, reverse proxies, service workers, or headless application shells.
Quick answer
Create a policy table for ordinary URL, extension cache-bust query, UTM query, unknown query, duplicate query, reordered query, and signed URL. For each, record viewer URL, cache key, forwarded parameters, origin URL, cache status, Age, ETag, HTML hash, canonical, analytics page location, and the next clean reload. The clean canonical URL must become current without leaving the test query in the sitemap, canonical, internal links, or analytics reports.
What to check first
- Record CDN cache policy, origin request policy, query allowlist, normalization, TTLs, service worker, and extension version.
- Test clean, cache-bust, UTM, unknown, duplicate, reordered, empty, encoded, and signed query fixtures.
- Capture edge status, Age, ETag, Last-Modified, origin request count, viewer and origin URL, HTML hash, and asset hashes.
- Inspect canonical, hreflang, Open Graph URL, sitemap, internal links, analytics page location, and server logs for query leakage.
- After any repair, invalidate only required paths and prove the ordinary clean URL is current from a signed-out browser.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Document query purpose before changing cache behavior. | Record CDN cache policy, origin request policy, query allowlist, normalization, TTLs, service worker, and extension version. | Viewer, edge, and origin query behavior matches the written matrix. |
| Separate cache-key inclusion from origin forwarding for every supported query. | Test clean, cache-bust, UTM, unknown, duplicate, reordered, empty, encoded, and signed query fixtures. | The clean canonical URL returns the current HTML and assets. |
| Preserve marketing attribution without fragmenting public HTML unnecessarily. | Capture edge status, Age, ETag, Last-Modified, origin request count, viewer and origin URL, HTML hash, and asset hashes. | Marketing parameters survive attribution without multiplying edge objects. |
| Keep signed and stateful queries isolated from shared cache behavior. | Inspect canonical, hreflang, Open Graph URL, sitemap, internal links, analytics page location, and server logs for query leakage. | No cache-bust URL appears in sitemap, canonical, internal links, or indexed reports. |
Why this usually happens
- Cache-key and origin-forwarding policies are separate controls.
- Marketing queries and technical cache-bust queries have different business purposes.
- A test query can create a fresh edge object while the clean canonical object remains unchanged.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
query,keyed,forwarded,edge,age,origin,html_hash,canonical,analytics,result
none,yes,none,hit,840,0,a91c,clean,clean,baseline
wp-bust,yes,yes,miss,0,1,b74e,clean,clean,pass
utm_source,no,yes,hit,842,0,a91c,clean,preserved,pass
unknown,no,no,hit,845,0,a91c,clean,clean,pass
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 |
|---|
| Bust included in key | Forwarded to origin | Fresh object without canonical duplication |
| Bust ignored in key | Forwarded or stripped | Policy is documented and clean object is current |
| UTM parameters | Excluded from cache key | Attribution preserved without cache fragmentation |
| Signed query | Exact forwarding required | Never normalized or shared incorrectly |
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.
- Document query purpose before changing cache behavior.
- Separate cache-key inclusion from origin forwarding for every supported query.
- Preserve marketing attribution without fragmenting public HTML unnecessarily.
- Keep signed and stateful queries isolated from shared cache behavior.
- Invalidate the clean object when needed and verify canonical, analytics, and origin evidence.
Decision rule
Approve the policy when each query class has an intentional key and forwarding rule, the clean URL returns current HTML, attribution remains accurate, signed routes stay isolated, and test queries create no canonical or indexable duplicates.
Production verification checklist
- Viewer, edge, and origin query behavior matches the written matrix.
- The clean canonical URL returns the current HTML and assets.
- Marketing parameters survive attribution without multiplying edge objects.
- No cache-bust URL appears in sitemap, canonical, internal links, or indexed reports.
Field notes
- Do not add the cache-bust URL to links, canonicals, or sitemaps.
- Measure edge-object growth before allowing all query strings into the key.
- Finish every test on the clean URL in a signed-out session.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only confirmation and a narrow synthetic fixture. Perform destructive, version, cache-policy, queue, or schema changes on staging first, then promote the smallest proven change.
What evidence should be kept?
Keep versions, fixture IDs, UTC timestamps, request or export evidence, expected and actual results, the decision owner, rollback point, and the final clean verification. Redact personal data.
When is the work finished?
Finish when the canonical user path passes, downstream records reconcile, failure cases are understood, monitoring is in place, and an established page links to the new guide with useful context.
Mistakes to avoid
- Changing production before preserving a reproducible fixture, timestamps, and the current result.
- Treating one successful screen, request, or export as proof that every downstream system agrees.
- Removing logs, identifiers, or rollback evidence before the owner and failure boundary are known.
- Testing only an administrator session instead of the roles, devices, consent states, and failure paths users actually have.
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 WordPress CDN cache mismatch.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references