A WordPress AJAX error is not a single diagnosis. Capture the failing request, its HTTP status, and its response body before changing plugins. A spinner can remain because no request was sent, because the server rejected it, or because the browser received a response it could not interpret.
Capture One Controlled Attempt
Open browser developer tools, select Network, and reproduce the problem once with non-sensitive test data. Filter to Fetch/XHR, but keep the full log available if the page navigates. Record the request URL, method, initiator, time, status, content type, and a redacted response excerpt.
Determine whether the integration uses WordPress admin-ajax.php or a REST endpoint. The WordPress AJAX handbook describes the admin-ajax action model; a REST request has different routing. Do not assume every background request belongs to the same system.
Use the Evidence to Pick the Next Check
| Observation |
Next check |
| No request appears |
Console error, missing script, or unbound click handler |
| Request goes to the wrong host |
Stale configuration, cached page, or hardcoded endpoint |
| 403 or a challenge page |
Nonce, user permission, and firewall evidence |
| 500 response |
PHP error at the matching time |
| 200 with HTML |
Login redirect, error template, proxy, or unexpected output |
| 200 with application error |
Read the JSON error, not only the transport status |
Statuses are clues, not verdicts. A security plugin can change the response format, and a successful HTTP response can still contain an unsuccessful operation.
Check the Action and Login Context
For admin-ajax requests, compare the submitted action value with the handler registered by the plugin. A missing action or unavailable callback can produce a minimal response that looks mysterious in the browser.
Guest requests use the wp_ajax_nopriv action hook. If a feature works for an administrator but not a visitor, review whether public access was intended and correctly implemented. Do not add a public handler to a privileged operation merely to remove an error.
Treat a Nonce as One Check, Not Authorization
Compare a freshly loaded page with a long-open or cached page. If only the older page fails, investigate token freshness, session changes, and cache behavior. WordPress nonce guidance makes clear that nonces are not a substitute for authentication or capability checks.
Do not remove nonce validation or globally allowlist admin-ajax.php. If a WAF rule blocks a legitimate request, record the exact rule and request context, then work on the narrowest justified correction.
Test sheet for wordpress ajax errors. Record your own evidence.
Retest the Business Result
After the correction, verify the expected stored record or changed state. One HTTP 200 is insufficient. Repeat as the intended user, with invalid input, and with a deliberate second click. Confirm that the operation does not create unintended duplicates or reveal protected data.
For lead delivery, follow the CRM trace beyond the browser. For an incident after a software change, use the plugin rollback guide. Send HandL WP a redacted request and matching error time, never a raw HAR file containing passwords, cookies, or customer submissions.
References checked September 28, 2026. Diagrams and worked examples are explanatory, not customer measurements.