Inicio - Documentación - POM Cache - 07 Clearing and invalidation - Clear one site safely on a multisite network

Clear one site safely on a multisite network

POM Cache isolates generated files by WordPress site. A manual or automatic “site” clear uses the current blog context; it does not intentionally delete every site's cache.

How sites are separated

HTML and JSON use independent trees, and each tree contains a site namespace derived from the public home host and, for a subdirectory installation, its path.

Conceptually:

cache/
├── pom-cache/
│   ├── site-a.example/...
│   └── site-b.example/...
└── pom-cache-json/
    ├── site-a.example/...
    └── site-b.example/...

A subdirectory site can look like:

example.com/site-b/...

This structure permits a network to share one physical Cache Location while keeping site operations scoped.

Safest both-store procedure for a subsite

  1. Open the frontend of the exact subsite.

  2. Confirm the browser hostname and site path;

  3. Confirm the administration bar belongs to your authorized user;

  4. Select Delete Cache in the toolbar;

  5. Wait for:

    HTML and JSON cache deleted for the current site.
  6. Request a page and a progressive batch on that subsite;

  7. Verify current output and regeneration;

  8. Visit a second site and confirm its warm responses remain available.

Using the toolbar from the target frontend makes the active site visually explicit.

Separate-store procedure

When only HTML or JSON is stale, use the target site's POM Cache General screen and the corresponding tool:

  • Cache tools → Delete Cache for HTML;
  • Progressive JSON tools → Delete Progressive JSON Cache for JSON.

On multisite, access to these settings is restricted to authorized network-level administrators. The settings can also appear under Network Admin → Settings → POM Cache. Before selecting a button, verify the current site represented by the request; a network screen is not a network-wide clear button.

Domain mapping

For a domain-mapped subsite, the site's configured home host defines its cache namespace. Verify:

  • WordPress Home URL is the public mapped domain;
  • requests reach the origin with the expected host;
  • direct Apache or Nginx rules use the same host-to-directory mapping;
  • the CDN forwards the host required by the origin configuration.

A mismatch can cause a cache miss. More seriously, an overly broad custom server rule can map to the wrong site's file. Keep generated server rules constrained and test every mapped domain before enabling direct delivery.

Subdirectory networks

In a path-based network, the site path is part of the namespace. Test:

https://example.com/
https://example.com/site-a/
https://example.com/site-b/

Do not assume the shared host alone identifies the cache target. Direct server mappings must preserve the subsite path just as POM Cache does.

Verify isolation

Use a non-destructive before-and-after check:

  1. Warm one known HTML URL and one JSON URL on site A;
  2. Do the same on site B;
  3. Record each site's two status summaries;
  4. Clear one store on site A;
  5. Confirm only site A's selected count returns to zero;
  6. Request site B's same URLs and confirm they remain hits;
  7. Regenerate site A and confirm its current hostname/path receives the new files.

Repeat for HTML and JSON because their mappings are separate.

CDN scope is also per viewer path

An origin current-site clear does not know how your CDN distribution groups hosts. If several sites share a CloudFront distribution, include the host and behavior design when selecting invalidation paths.

A viewer path such as /* may affect every host on a shared distribution depending on its cache key and invalidation semantics. Prefer reviewed, site-specific paths or separate behaviors where the CDN supports them.

Read Coordinate POM Cache clearing with CDN invalidation before invalidating a shared distribution.

Avoid filesystem-wide deletion

Do not manually delete the whole common cache root to clear one site. Use the current-site controls, which resolve and validate the intended namespace.

If the wrong site appears to be cleared, stop and review WordPress home URLs, blog context, cache location, domain mapping, and server rules before continuing across the network.