If an AJAX-powered component repeats old output on a WordPress subdirectory installation, inspect the request that actually returned the stale value. The site homepage and WordPress installation can have different base paths. A cache exclusion written for only the root path may not cover the endpoint the component uses.
The specific WP Rocket change
WP Rocket 3.24 lists a fix for excluding admin-ajax.php from dynamic-resource caching on subdirectory installs. The upstream change also describes configurations where WP_SITEURL differs from WP_HOME. This is about a specific dynamic-resource exclusion, not proof that every stale form or failed AJAX request is a caching defect.
Check the installed version against the official changelog. Preserve a backup and use staging for configuration changes. Do not move the WordPress directory, change the public site address or edit an endpoint in JavaScript before collecting a failing request.
Find the actual endpoint
Open browser developer tools, select Network, and perform the affected action once using synthetic data. Capture the request URL, method, status, content type and a redacted response. Record the initiating script and whether the request really goes to admin-ajax.php. Some components use the REST API or a separate service, which puts them outside this specific fix.
The following are illustrative paths, not URLs to paste into a live form:
| Installation |
Possible endpoint path |
| WordPress at the root |
/wp-admin/admin-ajax.php |
| WordPress under /wp |
/wp/wp-admin/admin-ajax.php |
| Deeper installation |
/apps/site/wp-admin/admin-ajax.php |
Use the address emitted by the site's integration. Do not assume that adding /wp to a path fixes it. The WordPress Address, public Site Address and reverse-proxy routing must agree with the actual deployment.
Separate an HTTP request to the real WordPress admin endpoint from a stale static resource or CDN response. Explanatory example, not a customer test.
Separate stale content from application errors
A 200 response containing the homepage is not a successful JSON response. A 403, an expired nonce response, or an authorization failure needs its own investigation. Compare the expected response format with what the browser received before blaming a cache layer.
For an authorized staging test, choose a read-only operation with two distinct inputs and known outputs. Record input A and its response, then input B and its response. Repeat in a fresh session. Do not replay payments, registrations or email-triggering requests merely because a developer tool offers a replay button.
Check whether the request is being replaced by an optimized static resource or answered by an upstream cache. A repeated response body alone does not prove caching; the application may legitimately return identical data. Correlate it with cache headers, the request initiator and a controlled change in expected output.
Repair the matching layer
Test an update to a supported release containing the 3.24 fix. Rebuild the affected optimized resources through supported controls and invalidate the specific stale public assets where necessary. Keep a copy of the previous settings. Do not add broad exclusions for all PHP requests without understanding what they change.
If the correct endpoint still receives stale output, compare the host and CDN configuration with the plugin behavior. WP Rocket's exclusion does not automatically govern an independently configured proxy. Conversely, a cache bypass will not fix a missing action handler or PHP exception. If server errors differ between command-line and web execution, use the PHP runtime comparison guide.
A useful acceptance test
Run the original component in the logged-out state customers use. Test two inputs, validation failure, successful completion and a fresh return visit. Confirm that the intended backend result occurs exactly once where a state-changing operation is necessary. Keep those production checks limited and approved by the site owner.
Record the full endpoint path, plugin version, first failing response and final passing response with personal data removed. Leave temporary logging and debugging overrides off after the test. HandL WP troubleshooting can help when the request crosses plugin optimization, hosting rewrites and a CDN and the response owner is unclear.
Sources reviewed October 31, 2026. The suggested checks and diagrams are diagnostic aids, not claims of tests performed on your site.