Clear and invalidate POM Cache
Invalidation removes generated origin files that may no longer match WordPress content. POM Cache keeps HTML pages and progressive JSON batches in separate stores, so the first decision is which response type became stale.
Choose the correct action
| Situation | HTML | Progressive JSON | CDN |
|---|---|---|---|
| Initial page shell is stale, later batches are current | Clear | Keep | Invalidate affected HTML viewer paths if cached |
| Initial shell is current, later archive batches are stale | Keep | Clear | Invalidate affected JSON viewer paths if cached |
| Global template or navigation changed everywhere | Clear | Clear if JSON contains it | Review a broad but controlled viewer-path scope |
| One public post changed and both automatic post switches are enabled | Cleared automatically | Cleared automatically | Still separate |
| A taxonomy term changed and both automatic term switches are enabled | Cleared automatically | Cleared automatically | Still separate |
| A POM Translate value changed and JSON translation purge is enabled | Not cleared by that JSON switch | Cleared automatically | Review localized paths |
POM Cache deletes origin files only. It does not send an invalidation request to CloudFront or another CDN.
Manual controls
POM Cache provides three distinct actions:
- Cache tools → Delete Cache removes static HTML for the current site.
- Progressive JSON tools → Delete Progressive JSON Cache removes progressive JSON for the current site.
- the administration-bar Delete Cache shortcut removes both stores for the current site.
The first two are on Settings → POM Cache → General. On multisite, POM Cache also exposes its settings through the network settings area for authorized administrators.
Read Clear caches from the administration bar or Clear caches from the tools screen before using the controls on a busy site.
Automatic invalidation is opt-in
POM Cache does not assume every site wants a full current-site purge on every edit. These settings default to Disabled:
Static HTML
- Purge HTML on post changes
- Purge HTML on term changes
They run only while static HTML Caching is enabled.
Progressive JSON
The JSON controls are Purge JSON on post changes, Purge JSON on term changes, and Purge JSON on translation changes.
They run only while Progressive JSON cache is enabled.
When a matching event occurs, POM Cache clears the complete relevant store for the current site. It does not attempt page-by-page dependency tracking.
Why site-wide invalidation is used
A single edit can affect more URLs than its permalink:
- home, archive, taxonomy, author, and paginated HTML;
- archive cards repeated in several contexts;
- navigation, counts, and ordering;
- split-by-term progressive batches;
- locale variants;
- next-page URLs and empty-state messages.
A broad current-site clear avoids leaving an indirect representation stale. The cost is that the next eligible request to each URL must regenerate its file.
Read Understand site-wide invalidation before enabling every automatic switch on an import-heavy site.
A reliable publishing sequence
For a change not already covered by the automatic settings:
publish source change
→ clear affected POM Cache store
→ request and verify corrected origin response
→ invalidate affected CDN viewer paths
→ verify public edge responseDo not invalidate the CDN first. It could refill from a stale origin file before you delete it.
Know what is not automatic
POM Cache has no age-based garbage collection and no built-in preload pass. A file remains until a content hook, a supported integration, or a manual action deletes it. After deletion, demand generates files again.
Global theme settings, custom metadata, direct database changes, external imports, and third-party rendering changes may require a manual clear unless their integration explicitly invalidates POM Cache.
Chapter map
- Clear caches from the administration bar: fastest current-site clear of both stores.
- Clear caches from the tools screen: separate HTML and JSON actions with status summaries.
- What happens when content changes: post lifecycle, assignment changes, and exclusions.
- What happens when taxonomy terms change: term lifecycle and the difference between terms and assignments.
- Understand site-wide invalidation: scope, regeneration, and bulk operations.
- Clear HTML and JSON independently: diagnose which response layer is stale.
- Clear one site safely on multisite: host/path isolation and current-site checks.
- Decide when the CDN must also be invalidated: origin versus edge freshness.
- Plan storage without automatic garbage collection: persistent files and maintenance cadence.
Verification standard
After any clear:
- Confirm the intended site and store were selected;
- Verify the relevant POM Cache count dropped;
- Request the affected URL directly from the origin;
- Confirm the first request contains current content;
- Confirm a new cache file is created when the response is eligible;
- Repeat the request and verify a hit;
- Verify the public CDN separately;
- Check that another multisite site was unaffected.
This proves both deletion and correct regeneration. A success message alone proves only that the deletion action was accepted.