# Managing Caching Across Client Sites With Claude in 2026: Every Flag Said Yes and One Site Served Nothing

> Nine WordPress sites read through one agent connection on 25 September 2026. Every cache flag returned true. One site had a 24-hour hit ratio of zero.

- Published: 2026-09-25
- Updated: 2026-10-04
- Author: xSpeed Cache Team
- Tags: MCP, Claude, Agencies, Caching, WordPress, xSpeed Hub, platform:wordpress, fix:hit-ratio
- Canonical: https://xspeedcache.com/blog/claude-manage-caching-client-sites/

---

Updated September 2026

On 25 September 2026 we read every site in a nine-site WordPress fleet we manage through one agent connection. Seven answered. On one of those seven the page cache reported enabled, reported serving, held 119 cached files, and returned a 24-hour hit ratio of **0**, against 0.9793 on the busiest site in the same fleet.

The question agencies expect to ask is how to connect an assistant to every client site, and that one is settled: four routes to a whole fleet are in [How to Connect Claude to Every WordPress Site You Own](https://xspeedcache.com/blog/connect-claude-to-every-wordpress-site/), and the setup for Claude and each other client is in [AI agents](https://xspeedcache.com/agent/). The more useful question is what to ask once you are connected, because a fleet-wide poll that reads switches reports every site healthy while one of them serves nothing. This covers auditing page-cache health across a fleet from one MCP connection: which four things to read, in what order, and which one carries the reason.

## Quick Summary: What to Read and in What Order

| If you want to know… | Read this | Why the previous read cannot tell you |
|:---|:---|:---|
| Is the cache on | The switch: `cache_enabled`, drop-in, `WP_CACHE` | Nothing. This is the first read |
| Is it serving | The counter: 24-hour hits, misses, ratio | A switch can be on while the serving path is off |
| Is this normal here | The trend: the 30-day daily ratio | Today's number has no baseline of its own |
| Why it changed | The cause: environment checks, and the one `warn` row | A counter reports the symptom, never the reason |

Jump to: [the counter](#read-the-counter-not-the-switch) · [the trend](#a-zero-is-not-always-a-cold-cache) · [the cause](#the-reason-lives-in-the-one-warn-row) · [drift](#settings-drift-is-the-disease-the-fleet-actually-has) · [at scale](#running-this-across-25-client-sites) · [FAQ](#frequently-asked-questions)

## The Four Reads, and What Each One Buys You

Ask an assistant whether caching works across your sites and it reaches for the one call that looks most like an answer. On every caching plugin we know of, that call returns a switch, the least informative thing available.

The four reads, in order, are the **fleet list** (which sites answer at all), the **cache status** (the switch and the counters), the **health checks** (the environment and any warning), and the **module settings** (what this site is configured to do). Each is blind to what the next one sees.

**The limitation, stated up front.** The reads tell you a site stopped serving and what the plugin believes the reason is. They cannot tell you whether the change was deliberate: a developer who turned a feature on last Tuesday for a good reason produces the same readings as an accident. Read all four, then ask.

![Four reads on one broken site, with each verdict](https://xspeedcache.com/images/blog/claude-manage-caching-client-sites-four-reads.webp)

Take read 1 literally. Two of our nine sites returned `unreachable`, and a request against one failed with a 401 saying it is not connected. Such a site is invisible downstream, and fan-out calls report partial success as success.

## Read the Counter, Not the Switch

Here is the fleet, read on 25 September 2026. Every reachable site reported `cache_enabled: true` and `page_cache_serving: true`, with no blocked reason given.

| Site | Cached files | Hits, 24h | Misses, 24h | Hit ratio |
|:---|---:|---:|---:|---:|
| notificationx.com | 10,434 | 23,215 | 490 | 0.9793 |
| embedpress.com | 58 | 8,617 | 241 | 0.9728 |
| schedulepress.com | 127 | 5,951 | 134 | 0.9780 |
| betterpayment.co | 196 | 1,210 | 40 | 0.9680 |
| flexia.pro | 82 | 876 | 37 | 0.9595 |
| storefaq.io | 114 | 665 | 13 | 0.9808 |
| trustsync.io | 119 | 0 | 93 | **0** |

Six sites land between 0.9595 and 0.9808. One reports zero hits against 93 misses while holding 119 cached files, from behind three green flags, with no switch set wrongly.

The counter is the first read that can disagree with the switch, and the only one that scales: seven numbers in a table make the outlier obvious in a way seven dashboards never do.

## A Zero Is Not Always a Cold Cache

The standard reading of a low hit ratio is a cold cache, and the remedy is to preload. Usually right; here it was wrong. The 30-day series settles it:

| Date | Hits | Misses | Ratio |
|:---|---:|---:|---:|
| 2026-09-21 | 688 | 93 | 0.8809 |
| 2026-09-22 | 123 | 73 | 0.6276 |
| 2026-09-23 | 5 | 59 | 0.0781 |
| 2026-09-24 | 0 | 97 | 0 |
| 2026-09-25 | 0 | 33 | 0 |

For the 26 days before 22 September this site ran between 0.5461 and 0.8809, then fell across three days and stopped. A cold cache has no 26-day history at 0.87, and it does not step down to zero while 119 files sit in the cache.

![Hit ratio falling from 88% to zero in three days](https://xspeedcache.com/images/blog/claude-manage-caching-client-sites-hit-ratio-collapse.webp)

Read the shape, not the value. A number that steps and one that decays are different faults, and that distinction, with the ways a counting change moves a ratio while the cache stays put, is worked through in [The Hit Rate Dropped Overnight and the Cache Never Changed](https://xspeedcache.com/blog/cache-hit-rate-dropped/).

## The Reason Lives in the One Warn Row

Switch and counter both refuse to explain themselves. The environment check does: of eleven rows on this site, ten returned `ok` or `info` and exactly one returned `warn`.

> Static-file rewrite (nginx server config): nginx detected, but the static rewrite is disabled because Separate Mobile Cache is on.

The module settings confirmed it: `mobile_separate` was `true` here, `false` on every healthy site. Separating the mobile cache means the server can no longer hand one stored file to every device, so the device-blind rewrite that produces fast hits is off by design. In xSpeed Cache that rewrite stamps the hit at web-server level and the counter reads its log, so files kept being stored and nothing served them.

The activity log dates the change to the day the ratio broke: caching enabled at 08:23 UTC on 22 September, a purge at 15:46, a ratio of 0.6276 that date against 0.8809 the day before. **It does not say which event flipped the setting, and this audit cannot tell you.** It gives you the day to ask about.

A site in this state is not broken. It serves from PHP with a warm cache nothing reads: slower than it was, faster than none, silent, because every boolean was true.

## Settings Drift Is the Disease the Fleet Actually Has

One site of seven had that setting because nobody set it deliberately fleet-wide. The cache module on three sites shows a house default and one that wandered off it.

| Setting | trustsync.io | schedulepress.com | embedpress.com |
|:---|:---:|:---:|:---:|
| Cache expiry | 24h | 168h | 168h |
| Separate mobile cache | on | off | off |
| Excluded URL rules | 28 | 16 | 17 |
| Excluded cookie rules | 8 | 20 | 20 |
| Purge on upgrade | on | on | on |

Two columns are identical and one differs on every row. That is drift, invisible from a single dashboard because every value is defensible alone: a 24-hour expiry is reasonable, 28 exclusions a reasonable accumulation, the mobile split a real feature some sites need.

Drift is a fleet-level observation, so finding it needs one connection reading every site at once. That is the case for an agent over twelve browser tabs, and what we built [xSpeed Hub](https://xspeedcache.com/xspeed-hub/) for. xSpeed Cache and xSpeed Hub are both ours, from WPDeveloper, and reading a fleet is free. Prompts for this audit are in [Debug page caching with Claude](https://xspeedcache.com/agent/claude/troubleshoot-cache/). Call names sit in the [MCP tool reference](https://xspeedcache.com/docs/mcp-tool-reference/); module names match the [object cache](https://xspeedcache.com/docs/object-cache/) panel.

None of this requires our plugin. Any caching plugin exposing a hit ratio, an environment check and its settings can be audited the same way.

## Running This Across 25 Client Sites

Four reads on nine sites is quick; at 25 the arithmetic is the reason to automate. The constraint worth knowing is where the command line stops.

`wp cache flush` is the obvious fleet tool and narrower than it looks. Per [WP-CLI's command documentation](https://developer.wordpress.org/cli/commands/cache/flush/), it "Flushes the object cache", not the page cache, and warns to "Beware of the performance impact when flushing the object cache in production". Every global parameter names one target: `--path`, `--url`, `--ssh`. An agent connection [returns a row per site from one question](https://xspeedcache.com/agent/claude/fleet/). Three rules keep it safe on live sites.

- 🔍 **Keep the audit read-only.** All four reads change nothing. Scope to read before widening.
- ✋ **Keep a person on the writes.** The [MCP specification](https://modelcontextprotocol.io/specification/2025-06-18/server/tools) states "there SHOULD always be a human in the loop with the ability to deny tool invocations", and a fan-out purge across 25 client sites is what that rule exists for.
- 📋 **Read the per-site result, never the summary.** A fan-out touching 23 of 25 sites reports success; the two it skipped are in the rows.

Confirm any fix from outside: the plugin reporting its own success is what failed here. The header check is in [How to Check Whether WordPress Caching Is Actually Working](https://xspeedcache.com/blog/check-wordpress-caching-working/), and xSpeed Scan, also ours, grades a URL free, no account needed.

## Common Mistakes Agencies Make

- **Polling the switch.** A green `cache_enabled` across 25 sites reports only that the plugin is installed.
- **Treating every low ratio as cold.** Check file count and trend first; a warm cache with zero hits is a serving fault.
- **Trusting a fan-out summary.** Read the rows, and the fleet list for `unreachable`.
- **Auditing without a baseline.** Drift shows only against a house default.
- **Fixing before asking.** The odd setting is sometimes deliberate.

## Frequently Asked Questions

### My hit ratio is 0% on one client site but the dashboard says caching is enabled. Where do I look?

The file count and the environment checks. If files are stored and nothing is served, a serving-path feature is off, and on nginx the check names it.

### I ran the preloader and the ratio stayed at zero. What did I miss?

The preloader fills the cache and does not serve from it. With the rewrite that reads those files disabled, preloading writes files nothing reads.

### Two of my sites show `unreachable` and my fan-out purge reported success. Is that a bug?

No. A fleet-wide call reports what it attempted; a site it cannot reach is skipped, not failed.

### I turned Separate Mobile Cache on deliberately for a site serving different mobile HTML. Should I turn it off?

No. Where markup genuinely differs by device the split is correct and the lower hit rate is its price.

### My ratio dropped gradually rather than overnight. Does that change what I check?

Yes. A step on a date points at a counting or configuration change; a gradual decline points at genuine misses accumulating.

### Can I do this audit without an MCP connection?

Yes, one site at a time from each dashboard, since all four reads exist in the admin panels. You lose the cross-site comparison.

### Do I need a paid tier to read a fleet this way?

No. The four reads are read-only and free at any fleet size, in xSpeed Hub and the plugin alike. [Free vs Pro](https://xspeedcache.com/free-vs-pro/) shows where the line falls.

### Does this work on a caching plugin that is not yours?

The four reads do, wherever it exposes them. The fleet-wide version needs an MCP server; we compared the two for caching in [xSpeed Cache MCP vs WP Rocket MCP](https://xspeedcache.com/blog/xspeed-cache-mcp-vs-wp-rocket-mcp/). WP Rocket's needs one connection per site, a real difference at 25 sites.

### How often should an agency run this?

Weekly catches drift and a ratio that breaks quietly.

### TTFB looks fine on the broken site. Does the cache still matter?

Less than the ratio suggests. Per [web.dev's TTFB guide](https://web.dev/articles/ttfb), "Good TTFB values are 0.8 seconds or less", and because TTFB "isn't a Core Web Vitals metric, it's not absolutely necessary that sites meet the good TTFB threshold".

## Conclusion: Read Four Things, in This Order

A fleet audit fails when it asks one question, because the cheapest returns the least useful answer. Six of our seven reachable sites were fine on every read. The seventh was fine on the first, wrong on the second, explained by the third.

**What to do this week:**

1. List your fleet and fix anything reading `unreachable` first.
2. Pull every site's 24-hour hit ratio into one table and find the outlier.
3. Read its 30-day trend before changing a setting.
4. Read the environment checks and note the one `warn` row.
5. Write down your house default for expiry, mobile split and exclusions, then diff every site against it.

Run the free scan on your own site: [xspeedcache.com/scan/](https://xspeedcache.com/scan/)

For client work the fleet read is worth automating, and the [agency use case](https://xspeedcache.com/use-cases/agencies/) covers how the Hub is licensed. xSpeed Cache is free on the [WordPress.org directory](https://wordpress.org/plugins/xspeed/) at 7,000+ installs and 5.0 from 14 ratings, queried 25 September 2026, Pro from $29/yr on [pricing](https://xspeedcache.com/pricing/). Read four things, not one.