Purging cache safely across many sites at once

Purging everything on every site is the reflex, and on a network it is the wrong one. A full purge across thirty sites empties every stored page at the same moment, so the next visitor to each of them pays the uncached price, and your own resource usage spikes precisely when you were trying to fix something.

Purge the smallest thing that is wrong

1. One URL. You edited one post and the change is not showing. Purge that page.
2. A group. You changed a template that affects one post type or one section. Purge that section.
3. One site. You changed something global on a single site: a theme file, a plugin, a site wide setting.
4. Everything, everywhere. Reserve this for a change that genuinely touched every site, such as a platform level configuration change.

Most of the time step one is enough, and the reflex to jump to step four comes from not knowing that steps one to three exist.

What automatic purging already covers

Publishing or updating a post normally purges that post plus the pages that list it: the front page, its category, its tags, the feed. If your workflow is publishing content, you should rarely need to purge by hand at all. Needing to means something is misconfigured, and repeatedly working around it by purging everything hides the real fault.

So if you find yourself purging manually after every publish, treat that as the bug rather than the routine.

Why a network wide purge costs more than it looks

Consider thirty sites with a few thousand pages between them. A full purge means every subsequent first request rebuilds from scratch: PHP runs, the database is queried, the page is assembled. If a crawler happens to be working through your sitemaps at that moment, it meets a cold cache on every site at once and generates exactly the sustained load your resource limits are there to contain.

The result is a slow network for an hour, resource faults in the log, and a suspicion that the platform is at fault when the cause was the purge. If a network wide purge is genuinely necessary, do it when traffic is lowest and, if you warm the cache afterwards, warm it gently.

Sequence for a change that really does affect everything

1. Make the change on one site and confirm it behaves.
2. Roll it out to the rest.
3. Purge site by site rather than all at once, so the rebuild load is spread out.
4. Spot check a page on each site for a cache hit on the second load.

Staggering step three is the whole trick. The work is identical; only the concurrency changes, and concurrency is what your limits actually govern.

Before you blame the cache

A change not appearing is not always a stale page. Work down this list before purging anything:

• Your browser. A hard reload rules it out in two seconds.
• A CDN or proxy in front. It holds its own copy with its own lifetime and its own purge.
• An optimisation cache. Combined or minified assets are stored separately from pages and expire on their own schedule.
• The change itself. Confirm it actually saved before concluding it is being hidden.

Purging is cheap on one page and expensive across a network, so it is worth thirty seconds of elimination first. If pages are missing rather than stale, that is the opposite problem and is covered in Speed and Caching.

Purge behaviour is documented by LiteSpeed. A cold cache pushes straight against the allowances described in Platform and Limits, and the wider routine lives in Running Your Estate.