Caching and page speedPro

Jetpack Boost MCP: inspect page caching and local module settings

A Jetpack Boost MCP session through GoBuildWP can clear Boost's page cache and read or write the plugin's jetpack_boost_ option rows, but GoBuildWP's driver treats Boost's module toggles as possibly synchronised from the Jetpack cloud, so a local write may not last. This page covers where Boost keeps its cache and configuration, what each cache ability does to it, and how to confirm that a change you asked for actually held.

By GoBuildWPContent updated 13 October 2026How we check claims

Get GoBuildWP free See Pro pricing

Jetpack Boost driverjetpack_boost

Layer: page
Declared purge scopes: all
Shared keys: None
Detected by: plugin folder jetpack-boost

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

Boost's modules, its cache folder and the Jetpack connection

Boost relies on a Jetpack Connection to WordPress.com rather than on the full Jetpack plugin, and its features (critical CSS, deferred JavaScript, concatenation, the image CDN, the page cache) are switched on and off as modules. GoBuildWP's driver records that those toggles may be synchronised from the Jetpack cloud. Which toggles sync, and when, is not established here, so it treats any local write as provisional until a later read shows it kept.

The page cache is plain files. Jetpack's documentation puts cached pages under wp-content/boost-cache/, with a config.php in that folder and an advanced-cache.php drop-in armed by WP_CACHE. Lifetime comes from the JETPACK_BOOST_CACHE_DURATION constant, 3600 seconds unless changed, and bypass rules from the jetpack_boost_cache_bypass_patterns filter. None of those is an option row, so none is within reach of an ability.

What GoBuildWP can see is every option whose name begins with jetpack_boost_. Those come back from cache-get-settings with include_native under their stored names and types, untranslated: none is presented as a page_cache or css key from the shared vocabulary.

Option name prefixes

jetpack_boost_

The driver warns that module toggles may be synchronized from the Jetpack cloud. Which toggles sync depends on the installed module and hooks; read the local row and check Boost after a change.

Limits

Boost limits to know before changing anything

Local writes are not the source of truth. The driver's note warns that module toggles may come down from the Jetpack cloud, so treat a successful cache-set-native as written for now, not settled.
Jetpack's documentation says Boost's cache does not support plain permalinks; a site using them will see no page caching however the rows read.
Cache duration and bypass patterns are a constant and a filter, which need code rather than an ability call.
rollback-change covers native writes. Purges and warms are recorded as having no state to restore.

Worked example

Clear Boost after a header change and get the home page cached again

Expected outcome to verify on the installed stack; this sequence has not been recorded as a runtime test.

Check that the homepage contains the new header, then inspect cache ownership and response evidence before claiming it was rebuilt. If purge_scopes.all was false, use Boost's Clear Cache button instead. If a browser still shows the old header, a CDN or edge in front of the site may hold it, and cache-purge does not reach those.

Inspect the actual native module hook and persisted state after a toggle; cloud synchronization is hook-dependent. Request the URL and check its freshness without attributing a drop-in or generic cache header to Boost alone.

AI clientyour-site.comVerify site policy

I changed the header template. Clear Jetpack Boost's cache and make sure the home page gets cached again.

wppilot/cache-check-setupRead
Confirms jetpack_boost is active and whether purge_scopes.all is true, which means Boost has registered its clear-cache listener.
wppilot/cache-purgeWrite
Fires jetpack_boost_clear_page_cache and names it as the entry point in the layer result.
wppilot/cache-warmWrite
Requests the homepage; inspect the expected header and freshness, and verify which configured cache served the response.
wppilot/cache-verify-in-browserRead
Returns browser checks for the new header, such as a lazy-loaded logo or an image missing its dimensions.

Proposed sequence from source declarations; not a recorded task or proof of client compatibility. Inspect saved state and browser or provider results separately.

A suggested sequence from the ability reference, not a recorded run.

Abilities

Cache abilities against Jetpack Boost

Ability	What it does here	Undo and limits
`cache-check-setup`	Shows jetpack_boost as a page layer, detected from the jetpack-boost plugin folder, with settings_canonical false and the cloud-sync reason attached. page_cache_dropin tells you whether an advanced-cache.php is armed at all.	A conflicting page cache can prevent Boost's own page cache from running; on supported hosts, Boost can instead report the host's caching. An active Boost plugin or a running badge does not establish cache ownership.
`cache-purgecache-warm`	Purging fires the jetpack_boost_clear_page_cache action, but only after has_action() confirms something listens on it. A url or post request widens to that whole-cache clear. Warm then fetches pages so Boost can write fresh files.	If the installed Boost registers no listener, the layer result says nothing was purged rather than claiming it was.
`cache-get-settingscache-set-native`	Read and change jetpack_boost_ rows by exact name; each write coerces the value to the type already stored and requires confirm=true.	The write updates a local option. Whether native hooks or connected services reconcile it depends on the module and installed version; read back the row and check the selected feature in Boost's dashboard before reporting success.
`cache-set-settingscache-apply-presetcache-list-presets`	Do nothing useful on Boost: every canonical key reports unsupported and presets find no key they can set.	Boost's toggles carry no GoBuildWP risk classification.
`cache-list-actionscache-run-action`	List no Boost action, so regenerating critical CSS is not something an agent can trigger here.	Regenerate from Boost's own dashboard.
`cache-begin-experimentcache-revert-experimentrollback-change`	Put jetpack_boost_ rows back exactly as captured, and purge afterwards.	They restore local rows only; whatever the Jetpack cloud decided since is outside any undo.
`cache-measure-pagecache-verify-in-browser`	Timing and render checks run on Boost pages as on any other. The browser checks are the right follow-up when deferral or concatenation may have broken a script.	Boost marks a hit with an X-Jetpack-Boost-Cache header, which is not among the headers measure-page reads. Repeated timings cannot show which layer answered, so inspect that header in a browser's network panel to confirm a Boost hit.

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.

Other plugins

Boost beside other optimisers

When another plugin owns page caching, Boost's optimisation features can still be active. Identify the page-cache owner before choosing a purge target; Boost may also report supported host caching rather than its own cache.
NitroPack's support article names Jetpack Boost among plugins it cannot share a site with while page caching, lazy loading or CSS and JavaScript optimisation are enabled in both.
With Boost and a mapped page cache both active, cache-get-settings without a driver reads the mapped one. Pass driver jetpack_boost to see Boost's rows.

Is Boost actually caching?

Working out whether Jetpack Boost's page cache is in use at all

Before tuning anything, settle which layer serves cached pages, because on many sites it is not Boost. A conflicting page cache can prevent Boost's own cache from running, while supported hosts may be reported as already caching. Jetpack's documentation also excludes plain permalinks from Boost caching. cache-check-setup gives the evidence in one read: every active cache layer, whether WP_CACHE is on, and whether an advanced-cache.php drop-in is armed. If another page cache is listed, or no drop-in is present, Boost's front-end optimisations may be running while its page cache is idle.

That changes the right next step. With another plugin doing the caching, purge that plugin and leave Boost to its CSS, JavaScript and image work. With Boost as the only layer, check Boost's hit header in a browser's network panel; Boost marks its hits with a header measure-page does not read, and repeated timings on the same URL can suggest caching but cannot show which layer answered. Then decide what to keep: running Boost for optimisation alone beside a host or plugin page cache is a valid setup, as long as nobody expects a Boost purge to refresh pages it never stored.

After a redesign on a Boost site

Template and header changes touch two Boost features at once: the cached pages and the critical CSS Boost generated from the old layout. The agent can clear the page cache and warm the home page, but no action for critical CSS is declared, so ask the owner to check and regenerate it from Boost's dashboard. Then run cache-verify-in-browser on a few key templates, because stale critical CSS tends to show as a brief flash of the old layout rather than as an error.

Questions

Jetpack Boost questions

Why did a Jetpack Boost setting revert after the agent changed it?

Inspect the installed native module hook and persisted row. A hook-dependent synchronization can overwrite local module state; not every toggle is established to invoke cloud sync. If it keeps reverting, change the module in Boost's own dashboard.

Does clearing Boost through MCP also clear the image CDN?

The only call GoBuildWP makes is the jetpack_boost_clear_page_cache action. It sends nothing to the Jetpack image CDN.

Can the agent regenerate Boost's critical CSS?

Not through the cache abilities. No action is declared for Boost, so regeneration stays in its dashboard.

Do I need the full Jetpack plugin for GoBuildWP to work with Boost?

Boost itself needs only a Jetpack Connection, per its WordPress.org listing. GoBuildWP detects Boost from its own plugin folder being active.

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 29 September 2026 by the GoBuildWP team.

Jetpack Boost is a separate product; no partnership or endorsement is implied.

Try it on Jetpack Boost in Read Only first

Get GoBuildWP free See Pro pricing