Caching and page speedPro
WP Super Cache MCP: what an agent can reach when the config lives on disk
WP Super Cache MCP support is shaped by one file. The plugin's main configuration sits in wp-content/wp-cache-config.php, which GoBuildWP Pro does not rewrite, so an AI agent cannot switch caching modes from here. What it can do is purge the whole cache, a single URL or a single post through the plugin's own functions, measure whether pages come back cached, and edit the option rows the plugin does keep, such as CDN rewriting.
wp_super_cache- Layer
- page
- Declared purge scopes
allurlpost- Shared keys
- None
- Detected by
- plugin folder wp-super-cache
Installed class, method or listener checks and per-layer results determine whether a purge ran. Neither a declaration nor a returned ran flag proves public freshness.
- Edition
- Pro
- Abilities
- 16
- Requires
- WordPress 6.9+, PHP 8.0+
Before changing cache settings, inspect captured drivers and not_captured. After reverting, inspect restored, deleted, not_restored, verified and purged_layers. Use a separate cache-purge result when you need details for each layer. Storage verification checks captured values; it does not establish functional recovery or public freshness. Revert may overwrite later settings, and vendor configuration regeneration or a re-save can still be required.
Check each measurement run’s fetched_via before treating it as public-path evidence. cache-verify-in-browser supplies checks and does not operate a browser. Automatic purge coalesces targets within the request and runs on shutdown; it is not necessarily one immediate flush per call. Verify generated files, object/page/edge caches and actual visitor behavior separately.
Data model
A PHP config file, static HTML, and a few option prefixes
According to its developer documentation, WP Super Cache writes static HTML under wp-content/cache/supercache/ per hostname, serves it through an advanced-cache.php drop-in with WP_CACHE defined, and keeps its main configuration in wp-content/wp-cache-config.php. Its modes are Expert, which relies on mod_rewrite, Simple, and WP-Cache.
GoBuildWP classes it as a second-tier layer: detected by its plugin folder, purged through the shared bridge, and reachable at the option level only. The option names it may touch are those starting wpsc_, ossdl_, supercache_ or wp_cache_. That prefix list is the safety boundary; a key outside it is refused, and a prefix that matches nothing simply returns nothing.
The consequence for an agent is a clear line. Anything held in the PHP file is visible only in the plugin's screen. Anything held in those option rows, CDN rewriting and feed handling among them, can be read and written by name.
Option name prefixes
wpsc_ossdl_supercache_wp_cache_
Its main configuration lives in wp-content/wp-cache-config.php on disk, which GoBuildWP does not rewrite. The option rows it does keep ; CDN rewriting, feed handling ; are readable and writable by name.
Abilities
Cache abilities where the config is a file
| Ability | What it does here | Undo and limits |
|---|---|---|
cache-purgecache-warm | All, url and post scopes call wp_cache_clear_cache(), wpsc_delete_url_cache() and wpsc_delete_post_cache(), each only when the function exists on this install. Warming then requests the pages you name so they can be cached again. | No stored state to restore. |
cache-check-setupcache-measure-page | Setup reports the layer as purge-capable with native settings only, quotes the reason about wp-cache-config.php, and checks WP_CACHE and the drop-in. The measurement reads cache status headers and timing from the response. | Read-only. |
cache-get-settingscache-set-native | include_native lists the rows under the four prefixes; a write names one of them, and the value must read back before it is changed. | Confirm on every write. The ledger records the option row, so rollback-change restores it; nothing in the PHP file is touched either way. |
cache-set-settingscache-list-presetscache-apply-preset | No shared map exists for WP Super Cache, so every canonical key is unsupported and presets have nothing to set. | Use native rows or the plugin screen. |
cache-list-actionscache-run-action | No actions are declared; the plugin's preload and garbage collection stay in its own screen. | Nothing to run. |
cache-verify-in-browsercache-begin-experimentcache-revert-experiment | Browser checks work as on any page. An experiment captures the prefixed option rows only. | A revert cannot restore anything that lives in wp-cache-config.php. |
Reference: /docs/reference/cache
Shared cache module; do not add this count across drivers. Edition and effect labels describe the source catalogue. The installed schema, dependency versions, licence, WordPress capability, safety profile and per-ability policy determine availability; labels alone do not prove confirmation or recovery.
Limits
The file GoBuildWP leaves alone
- wp-cache-config.php is never rewritten, so caching mode and the other settings kept there change only in WP Super Cache's own screen.
- No preset, risk tier or cross-plugin key applies; each native write is judged on its own and needs confirm.
- Only one advanced-cache.php can exist, so a second page cache on the same site conflicts with this one.
- An explicit cache-purge invokes the available purge entry points in that call and has no undo. Automatic purges after eligible writes are queued and coalesced at request shutdown.
Worked example
Visitors still see yesterday's prices
Expected outcome to verify on the installed stack; this sequence has not been recorded as a runtime test.
The current prices are served from a fresh cached copy. If output is still stale, inspect the stored edit and every delivery layer; stale output does not establish who made the edit or which cache caused it.
Inspect the expected current price or content in the browser after purge and warm. Cache metrics alone cannot establish price freshness.
I updated the pricing page this morning and customers are still seeing the old numbers.
wppilot/cache-check-setupReadFinds WP Super Cache, the drop-in in place, whether automatic purge-after-write is on, and any edge layer.
wppilot/cache-purgeWriteScope post with the pricing page id calls wpsc_delete_post_cache() and reports that entry point.
wppilot/cache-warmWriteRequests the pricing page so the next visitor is not the one who rebuilds it.
wppilot/cache-measure-pageReadConfirms the response and its cache status after the rebuild.
A suggested sequence from the ability reference, not a recorded run.
Static files, missing headers and a name-based boundary
Reading a WP Super Cache measurement that shows no cache header
WP Super Cache MCP checks often surprise people at the first cache-measure-page call. The ability recognises a fixed list of status headers, from x-cache and cf-cache-status to x-litespeed-cache and age, and bases its verdict on them: a HIT is a pass, headers without a HIT are a warning, and no recognised header at all is only a recommendation. A page served from WP Super Cache's static files may carry none of those headers, so the verdict alone does not prove the page was uncached.
cache-warm's cache_hit relies on the same headers, so a false there means only that no header said HIT. Read three things together instead: time to first byte across the repeated runs compared with a run straight after a purge, the HTML comment the plugin's FAQ describes at the bottom of the source, and the page itself. If an edge such as Cloudflare sits in front, its header appears in the same measurement and describes the edge copy, not WP Super Cache.
What the wpsc_, ossdl_, supercache_ and wp_cache_ prefixes do and do not cover
GoBuildWP decides which options belong to WP Super Cache by name alone: anything starting wpsc_, ossdl_, supercache_ or wp_cache_ is treated as the plugin's. That boundary keeps cache-set-native away from unrelated options, but it is a name match, so a row another plugin happens to create under wp_cache_ would be listed too. Read the names in the native dump before approving a write.
For this plugin a native key is a whole option row and the write is a direct update_option, so the plugin's own settings handler does not run and write_path says option_direct. Where a row holds an array, send back the complete value with the one change in it. Nothing kept in wp-cache-config.php, the caching mode included, appears in that dump at all.
Splitting WP Super Cache work between the agent and its settings screen
The agent is the quicker route for three jobs: purging after content changes through wp_cache_clear_cache, wpsc_delete_url_cache or wpsc_delete_post_cache depending on the scope you ask for, measuring a handful of URLs, and reading or restoring the option rows. The caching mode and the other settings held in the config file, plus preload and garbage collection, stay in the plugin's screen.
Purges are writes, so the Read Only profile limits the agent to measuring and reading; Production Safe permits purges subject to per-ability and approval rules, and every native write still needs confirm. All of the cache abilities are part of GoBuildWP Pro, as Free vs Pro sets out.
- "Purge and warm the homepage, measure it, and tell me how you know whether WP Super Cache served it."
- "List every option under the WP Super Cache prefixes and flag any that do not look like the plugin's."
- "Clear the cache for the post I just edited and nothing else."
Questions
WP Super Cache questions
Can the agent switch WP Super Cache to Expert mode?
No. The mode is part of wp-cache-config.php, which GoBuildWP does not edit. Change it in the plugin's settings screen.
Does an edit the agent makes clear WP Super Cache automatically?
Yes, when purge-after-write is on. GoBuildWP collects the posts its writes touched and purges them once at the end of the request, through the same functions listed above.
How do I confirm a page came from WP Super Cache?
The plugin's FAQ suggests viewing the page source for its Cached page generated by WP-Super-Cache comment. The agent's measurement adds timing and header evidence alongside that.
Other plugins
Sharing the drop-in slot
- WP Fastest Cache's documentation names WP Super Cache among plugins to disable before using it, and NitroPack lists it among caches it cannot run beside.
- Jetpack Boost's cache does not activate when another cache system is detected, so the two page caches do not run together.
Where these facts come from
GoBuildWP behaviour is taken from the plugin source and the ability reference; third-party details from the vendor documentation below, checked by the GoBuildWP team.
WP Super Cache is a separate product; no partnership or endorsement is implied.