Understand site-wide invalidation

In POM Cache, “site-wide” means the complete selected cache tree for the current WordPress site. It is broader than one URL but narrower than a multisite network.

Actions that use this scope

Supported extensions can also request or suppress deletion through the public developer interfaces. A normal site owner should judge the result by the selected store and current site, not by an internal event name.

Why one edit causes a broad clear

WordPress content is highly connected. An edited product can change:

• its single page;
• a home-page module;
• post-type and taxonomy archives;
• sorting and pagination on later pages;
• a navigation count or featured list;
• several progressive archive batches;
• translated variants.

POM Cache does not build a dependency graph for every rendered occurrence. Clearing the full current-site tree provides a predictable freshness boundary.

The regeneration cost

Site-wide deletion removes warm files. POM Cache does not preload them, so the next eligible request to each URL becomes its generator:

full current-site clear
→ first page request renders HTML
→ first progressive batch request renders JSON
→ later matching requests reuse generated files

On a high-traffic site, many different URLs can regenerate at once. The impact depends on route diversity, not just total traffic.

Choose automatic purges deliberately

Enable automatic site-wide invalidation when:

• content freshness must follow normal editorial saves;
• edits are moderate compared with visitor traffic;
• an item can appear across many public responses;
• the origin can absorb demand-driven warm-up.

Consider a controlled manual end-of-batch clear when:

• imports update hundreds of posts or terms;
• translations are generated in a long batch;
• editors save many related records before publishing the final state;
• a deployment changes several global templates at once.

The goal is not to avoid invalidation. It is to clear once at the point when the source reaches a coherent final state.

Changes that need a manual decision

The post and term switches cover their documented WordPress events. They do not imply that every configuration change clears cache.

Review both stores after:

• global theme or template settings;
• navigation or footer changes rendered across pages;
• archive batch-size or grouping changes;
• custom fields changed outside normal post handling;
• direct database updates;
• external synchronization;
• public route, hostname, or locale-prefix changes;
• server rewrite changes.

Some compatible integrations can invalidate explicitly, but POM Cache does not enable a general “purge on every settings save” policy by default.

POM Tweaks Country pricing zones is one explicit integration. It clears current-site HTML when zones, canonical regional product prices, or cache-safety options change. Plugin activation, deactivation, WordPress-managed plugin or theme updates, relevant POM Tweaks settings saves, and theme switches first place the cache in a conservative pending state; the next anonymous public request that is otherwise eligible for shared HTML recalculates whether the universal contract and public proxy path are safe. WP-CLI, cron, administration, REST, AJAX, and authenticated requests cannot promote this persisted state to safe.

The automatic clear affects origin files only. Purge or invalidate matching CDN HTML after deploying a new POM Theme, POM Tweaks, or POM Cache integration version and after resolving an unsafe compatibility state.

Recover cleanly

After a broad clear:

1. Test the homepage and one representative inner page at the origin;
2. Test standard and split progressive archives if both exist;
3. Include each public locale;
4. Verify authenticated and commerce sessions still bypass early shared delivery;
5. Watch origin error rate and response time during warm-up;
6. Invalidate the required CDN viewer paths only after the origin is correct;
7. Confirm the public edge refills with current output.

If just one store was cleared, explicitly verify the preserved store remains present and current.

Multisite boundary

POM Cache resolves the deletion with the current blog ID and its site-specific directory. A site-wide purge is not a network-wide purge.

This safety depends on operating in the intended site context and on server rules mapping each host/path to the matching cache namespace. Read Clear one site safely on a multisite network before performing maintenance across several sites.