Published the change? Check the cached copy
MCP Abilities – Cache Enabler lets your AI client inspect the local page cache, clear the relevant copy and gather evidence for the next check.
WordPress can be current while the visitor sees yesterday’s page
Suppose you publish new opening hours at 18:00. WordPress contains the change, but a visitor still receives the HTML that Cache Enabler saved at 17:00. Refreshing the editor will not tell you which copy the visitor received.
Cache Enabler stores ready-made pages to reduce the work of building each response. That saved copy is useful until it outlives a change that readers need to see.
Start with the affected address. Confirm the change is published, inspect Cache Enabler’s status and cached files, then choose whether that copy needs to be cleared.
The illustration shows a newer source and an older saved copy. The visitor receives the saved copy.
Clear the page that changed
A URL purge removes the cached versions of one same-site address. A post purge selects a WordPress post or page by ID. Both give you a narrower starting point than clearing the whole cache.
For a change to one page’s opening hours, start with that page. For a menu or template used across the site, a wider purge may be appropriate. Choose the scope from where the change appears.
The other cached pages can remain available. Clearing a copy does not itself prove that a fresh copy has been built or that a visitor can see the change.
The selected page leaves the cache. Unrelated pages stay in place; the result still needs to be checked.
From a stale page to a checked result
1. Confirm the source
Name the exact site and URL. Open the published WordPress content and check the expected change before investigating the cache.
2. Inspect the local cache
Request Cache Enabler status and inspect cached files. Page diagnosis can report an HTTP response, cache headers and a marker, but uses no-cache request headers. It is not a measurement of a normal visitor request.
3. Clear the relevant scope
Purge the URL or post for a local change. Use the current-site or complete-cache operation only when the affected content justifies that wider scope.
4. Read the visitor’s page
Open the public address without an administrator session and look for the changed content. If it is still old, inspect any CDN, reverse proxy or browser cache separately.
Choose the scope before changing settings
Expired-cache cleanup removes expired entries. Current-site and complete-cache purges have a wider reach than a single URL. The add-on also provides settings previews, enable/disable controls and backend refresh.
Settings changes use a dry run by default. Review that preview before applying it. Emergency cache-directory deletion is a separate operation with explicit confirmation; routine stale-page work should start with the normal purge functions.
What you need
Use WordPress 6.9 or newer with its built-in Abilities API, PHP 8.0 or newer, Cache Enabler, and the WordPress MCP Adapter for your client connection. The connected WordPress account needs manage_options.
MCP Expose Abilities is optional. This add-on registers its own abilities. Cache Enabler owns the cached files; the add-on supplies the inspection and management operations.
These operations act on the local Cache Enabler cache. They do not clear a CDN or browser cache. Your MCP client supplies the AI connection.
Start with the page that looks out of date
Install the add-on and ask your client to inspect one affected URL. Clear the appropriate copy, then check the actual content your visitor receives.