xSpeed Cache is officially live! Get 50% OFF during Launch Week — Lifetime starts at just $79Lifetime from $79 — 50% OFF, Launch Week! See Plans →

See Plans →
Features
xSpeed Hub Pricing Docs Blog Scan
Appearance
Get Plugin

Find out why WordPress pages are not cached with Manus

Finding out why pages are not cached with Manus means handing a general AI agent the investigation as a task, letting it read xSpeed health checks, benchmarks and recent activity through xSpeed Hub, and getting back a written report with the evidence.

list_sitesget_cache_statusget_healthrun_benchmarkget_benchmark_historyget_pro_audittoggle_cachecontact_support

Last updated: October 2026

Example session · Manus

You: Use xSpeed Hub to investigate why the hit ratio on shop keeps collapsing, and write me a short report with the evidence. Read only.

get_cache_status(site: shop) read-only
→ page cache on, 61 cached pages, hit ratio 38% in the last 24h, last purge 7 minutes ago

get_health(site: shop) read-only
→ all environment checks pass; hourly buckets: misses spike at the start of every hour; recent activity: full purge every hour

run_benchmark(site: shop) read-only
→ home page: 602 ms uncached, 64 ms cached, cached request was a hit

Manus: Report: caching works, but the whole page cache is purged at the start of every hour, so pages are rarely cached long enough to be hit. xSpeed purges on every post update, so look for an import or sync on shop that saves posts hourly. I changed nothing.

01

How Manus handles this

The hit ratio on shop looks fine one hour and poor the next, and you have no time to sit with it. Manus is built for that kind of handoff. You write the task once, mention xSpeed Hub so Manus uses the custom MCP server you added under Settings, Integrations, and ask for a report you can forward: what is wrong, the evidence, and what to change. Then you leave it to work.

Manus reads get_cache_status, then get_health, which carries the part a glance misses: 24 hourly hit and miss buckets and the site's recent activity. The pattern is a sawtooth. Hits climb, then collapse at the start of every hour, and the activity shows a full purge each time. run_benchmark confirms the cache itself works. Something on the site clears it hourly. xSpeed purges the whole page cache automatically whenever a post is published or updated, so the usual culprit is an import or a product sync that saves posts on a timer. Manus cannot see your cron jobs or your other plugins, so its report names the pattern and the likely kind of cause, and leaves finding the exact job to you.

Manus describes no per-tool approval setting for a custom MCP server, so the task wording and the token carry the weight. Every tool in this investigation only reads, which makes a connection token with Read-only everywhere on the right credential: the Hub refuses every write tool on it, and the report comes back the same. If you later want Manus to act on its own findings, give it that as a separate task, switch the token to allow writes for as long as it runs, and tell it to ask you before each change.

02

Set up Manus once

Already connected? Skip to the prompts. Alternatives and troubleshooting are on the Manus guide.

1Put your sites in xSpeed Hub

Sign in at app.xspeedcache.com with Google or email; the Hub is free and has no site cap. Then connect each WordPress site from its own dashboard: click Connect Hub in the xSpeed Cache top bar, then Connect via xSpeed Hub. Each site needs the free xSpeed Cache plugin.

2Copy the connection token from xSpeed Hub

Sign in at app.xspeedcache.com as the workspace owner, open Connect AI and copy the connection token. If Manus will only report, turn on Read-only everywhere so the Hub refuses every write tool on that token.

Text
xSpeed Hub  >  Connect AI  >  connection token

3Add xSpeed Hub as a custom MCP server

In Manus, open Settings, then Integrations, then Custom MCP Servers, and click Add Server. Name it xSpeed Hub, enter this as the server URL, and enter the connection token as the Bearer token in the authentication field.

Text
https://app.xspeedcache.com/xspeed/mcp

4Let Manus test it, then name it in a task

Manus checks that it can reach the server and read its list of tools. Then start a task that names xSpeed Hub, so Manus uses this server.

Text
Use xSpeed Hub to list my sites and tell me which ones have page caching turned off.
1 / 4

Full Manus setup, sign-in options and FAQ

Before you send a prompt that changes something

Reads change nothing on your sites, though contact_support emails xSpeed support. Writes run once your connection allows them, so your client's approval prompt and a read-only connection (the token's Read-only everywhere switch, or a Viewer sign-in) are the gates that matter. Manus's custom MCP documentation describes no per-tool approval setting for a custom server, and its scheduled tasks offer a skip confirmations option that lets Manus act without asking each time. xSpeed Hub has no confirmation step of its own, so a write runs as soon as Manus calls it and your connection allows writes. The Hub tells the agent to confirm the target site and to ask once before a write that touches every site, but that is an instruction. The firm stop is the token: with Read-only everywhere on, the Hub refuses every write tool. Keep it on for scheduled work, and leave skip confirmations off for any task that may write.

03

What do I ask?

Three prompts written for Manus. More for this job are below.

Prompt for Manus
Use xSpeed Hub to investigate why the hit ratio on shop keeps collapsing and write a one-page report with evidence. Read only, and do not contact support.
Prompt for Manus
With xSpeed Hub, compare the hourly hit and miss buckets for shop and blog and tell me which one is purged most often.
Prompt for Manus
Using xSpeed Hub, run the benchmark on every site and add any where the cached request missed to the report.
04

What happens, step by step

When a WordPress page is not served from cache, the cause is usually one of a few things: caching is off, the cache drop-in or the WP_CACHE constant is missing, another caching plugin is in the way, or the pages carry something that makes them uncacheable. Through xSpeed Hub an agent can read the cache status, run the site's full health diagnostics, time a cached request against an uncached one, and check which Pro features would help, all without changing anything.

01

Start with the quick summary

get_cache_status returns whether page caching is on, the stats (cached pages, size, hit ratio, last purge) and the web server xSpeed detected. It is a glance. If caching is off, or the hit ratio is far below what you expect, the agent moves on to the diagnostic.

02

Run the diagnostic

get_health is the tool for troubleshooting. It returns the environment checks with pass or warn tones (the advanced-cache.php drop-in, the WP_CACHE constant, rewrite rules, PHP and WordPress versions, caching plugin conflicts), the cache stats, 24 hourly hit and miss buckets and a 30-day hit-ratio series. The Hub tells the agent to use it, not get_cache_status, when you are troubleshooting rather than glancing.

03

Time cached against uncached

run_benchmark requests the home page once with the cache bypassed and once normally, after a warm-up request, and returns the timings. If the second request still is not a cache hit, the page cache is not serving the home page, and the result says so. It measures xSpeed's own response time. It does not return a Lighthouse score.

04

Read what the checks mean

A warn is a lead, not always a fault. A static-file rewrite warning, for example, can mean the nginx snippet is not in your server config yet, or that xSpeed could not verify it, which is not evidence the config is wrong. The agent reads the detail line and tells you which one it is.

05

Fix it or hand it over

If caching is simply off, toggle_cache turns it on. If another caching plugin owns the drop-in, the site refuses to enable xSpeed and says why; removing the other plugin is yours to do. If nothing explains it, contact_support emails xSpeed support with the agent's summary, after the agent has confirmed the message with you.

05

Reference

Quick checkget_cache_status (read): cache on or off, stats, detected web server
Diagnosticget_health (read): environment checks, 24 hourly buckets, 30-day hit-ratio series, recent activity
One site per callget_health does not accept site: "all"; call it for each site you care about
Benchmarkrun_benchmark (read): home page only, cache bypassed against cache served, timings in milliseconds
Benchmark on every siterun_benchmark accepts site: "all" or a list of handles, one result per site
Benchmark historyget_benchmark_history reads past runs and the settings changes on the same timeline
Pro suggestionsget_pro_audit (read): which Pro features would help this site, from its settings and stats
Hit ratio scopeCounts requests that reach your server; pages answered by a CDN or Cloudflare edge are not counted
Supportcontact_support emails xSpeed support with your account email and site list attached; classed read
Turning caching ontoggle_cache (write); refused by the site when another plugin owns the cache drop-in
06

Rules worth keeping

  • Diagnose with the read tools first. get_cache_status, get_health, run_benchmark and get_pro_audit change nothing on the site, so a read-only connection can run all of them. For clients that send the connection token, that means Read-only everywhere on; an OAuth sign-in gets the scopes the client asks for, unless the member is a Viewer.
  • Do not answer a PageSpeed question with run_benchmark. It measures cached against uncached response time and returns no Lighthouse score; for a score, use the speed test or scan jobs.
  • toggle_cache is a write. It runs as soon as your connection allows writes, and the Hub tells the agent to confirm the target site first. That is guidance to the agent, so your client's approval prompt is the gate that matters.
  • contact_support sends a real email. The Hub tells the agent to confirm the message with you before sending, but the tool is classed read, so even a read-only connection can send one.
  • The agent cannot edit your server configuration or another plugin's settings. When a check needs an nginx snippet or a conflicting plugin removed, it tells you what to do and you do it.

Good to know with Manus

Two Manus habits matter here. First, a long task tends to keep going. If the token allows writes, a model that decides the fix is to turn caching off and on again can do it, because xSpeed Hub has no confirmation step of its own and the Hub's instructions to the agent are guidance, not a lock. A read-only token closes that door. Second, contact_support is classed as a read, so even a read-only token lets Manus email xSpeed support if it concludes it is stuck. Say in the task that it must not contact support and that the report comes to you. If you turn the investigation into a scheduled task, leave skip confirmations off.

07

More prompts for this job

They work in any client connected to xSpeed Hub.

Prompt
Using xSpeed Hub, why is the cache hit ratio so low on shop? Run the full health check and tell me the most likely cause.
Prompt
Using xSpeed Hub, is page caching actually working on blog? Benchmark cached against uncached and tell me if the second request was a hit.
Prompt
xSpeed Hub's get_health on docs shows a warning about the static-file rewrite. What does it mean and do I need to act?
Prompt
Use xSpeed Hub to check whether another caching plugin is conflicting with xSpeed on shop.
Prompt
Caching looks off on the staging site. Use xSpeed Hub to turn it on and tell me if the site refuses.
Prompt
Using xSpeed Hub, which Pro features would help the shop site, based on how it is set up now?
Prompt
With xSpeed Hub, compare the last few benchmark runs on blog and tell me whether my settings changes helped.
08

Frequently asked questions

It can find the pattern. get_health returns hourly hit and miss buckets and recent activity, so Manus can show that the cache is purged on a timer. It cannot see your cron jobs or other plugins, so naming the exact culprit is a step for you.

A connection token with Read-only everywhere on. Every tool the investigation needs only reads, and the Hub refuses every write on that token. It does not stop contact_support, which the Hub classes as a read, so say in the task that Manus must not email support.

The common causes are that page caching is switched off, the advanced-cache.php drop-in or the WP_CACHE constant in wp-config.php is missing, another caching plugin owns the drop-in, or the pages set cookies or headers that make them uncacheable. An agent can read all of these from get_health through xSpeed Hub and tell you which one applies to your site.

get_cache_status is a quick summary: whether caching is on, the stats and the detected web server. get_health is the diagnostic. It adds the environment checks with pass or warn tones, 24 hourly hit and miss buckets and a 30-day hit-ratio series. The Hub tells the agent to use get_health when you are troubleshooting.

No. run_benchmark measures how fast your own cache answers compared with an uncached request for the home page. For a Lighthouse score, ask for a speed test or a speed scan instead.

Only partly. run_benchmark accepts every site in one call. get_cache_status and get_health take one site per call, and get_health does not accept site: "all", so for a fleet the agent calls them site by site or you use the Hub dashboard for the rollup.

Not with the diagnostic tools. They are read tools and change nothing. Changes only happen if the agent calls a write tool such as toggle_cache, which runs once your connection allows writes, so your AI client's approval prompt and a read-only connection (the connection token with Read-only everywhere on, or a Viewer sign-in) are the gates.

09

Keep going

Find out why pages are not cached with other agents

More with Manus

Documentation

From the blog

Find out why pages are not cached, from Manus.

xSpeed Hub is free and has no site cap. Connect your sites once and ask from the agent you already use.