Rolling out LSCache across many separate WordPress installs

Setting up caching on one site is a five minute job. Doing it across thirty separate WordPress installs is a different exercise, because the thing that costs you is not the setup but the inconsistency: two sites configured differently a year apart become two sites nobody can debug.

Decide the standard once

Before touching any site, write down the configuration you intend every site to have. It does not need to be elaborate. A workable baseline:

• Page caching on, with a stated time to live.
• The pages you always exclude, listed explicitly.
• Automatic purge on publish and on update.
• Whatever optimisation options you enable, chosen once and applied to all.

The point of writing it down is not ceremony. It is that in six months you will find one site behaving differently and you will need to know whether that is a mistake or a decision.

Roll it out in three waves

1. One site. Pick the least important. Apply the standard, confirm cache hits, browse it as a visitor and as a logged in user, and leave it a day.
2. A handful. Three or four sites that differ from each other: pick a shop, something with a busy form, and a plain publishing site. Differences surface here, not on the first site.
3. The rest. Only once the second wave has been quiet for a few days.

The temptation is to skip to step three because the first site worked. Resist it. The sites that break are the ones that differ, and the first site by definition does not differ from itself.

Exclusions are where networks diverge

Most inconsistency creeps in through exclusion rules added to fix one site and never reviewed. Two habits prevent it:

• Exclude the narrowest thing that works. Excluding a whole directory because one page misbehaved silently kills caching for everything under it.
• Record why. An exclusion with no note is an exclusion nobody will ever dare remove, even after the plugin that needed it is gone.

Cookies are the usual culprit

A page cannot be cached for everyone if the site sets a cookie that makes each visitor's page different. Consent banners, A/B testing scripts, analytics that write a cookie server side, and some security plugins all do this. The symptom is uniform: every request reports a miss and the cache never fills.

Because you likely installed the same consent or analytics stack on every site, this problem tends to appear on all of them at once. That is actually good news, since one fix applies everywhere.

Do not share a cache across sites

Each site's cache belongs to that site. Beyond correctness, this matters for a network built on separation: sites that answer on distinct addresses with their own nameservers should not be sharing state at the caching layer either. Keep the boundary complete.

Verify, then keep verifying

After the rollout, check a page on each site and confirm a cache hit on the second load. Then repeat that check periodically, because caching does not fail loudly. A plugin update or a new consent banner can quietly turn it off, and the only symptom is that the site becomes slower over weeks in a way nobody attributes to anything.

A short list of URLs to spot check, run monthly, is enough. The point is that the failure mode is silent, so the check has to be deliberate.

The configuration reference is at docs.litespeedtech.com. For a repeatable sequence when adding new sites to an existing network, see Launch Playbooks, and for managed WordPress with this already configured, WordPress hosting.