What matters first: WordPress received the AJAX request but could not process it as a valid action. The request payload usually reveals whether the action, nonce or expected fields are missing.
What this symptom actually tells you
admin-ajax.php serves many unrelated features, so a 400 on one button does not mean AJAX is globally broken. The failing action name, payload and response distinguish plugin code from caching, security or request-size problems.
Capture evidence before changing anything
- Capture the request payload and locate the action parameter.
- Compare logged-in and logged-out behaviour because they use different hooks.
- Read the response body and any PHP log entry at the same timestamp.
- Check whether a cache, WAF or optimisation layer altered the POST body or nonce.
Most common causes
- Missing action hook: The plugin sent an action that is not registered for the current authentication state.
- Expired nonce: A cached admin or front-end page can submit a token WordPress no longer accepts.
- Malformed payload: JavaScript may omit required fields or send JSON where form data is expected.
- Security filtering: A WAF can remove or reject fields that look like code, URLs or SQL.
Safe diagnostic and repair sequence
- Reproduce with caches and script optimisation bypassed for your own session.
- Confirm the PHP hooks exist for wp_ajax_ and, where required, wp_ajax_nopriv_.
- Regenerate the nonce from an uncached page and verify the request sends it under the expected field name.
- Adjust only the proven WAF or request rule, then re-test the exact feature.
How to choose between the likely causes
Do not treat Missing action hook and Expired nonce as interchangeable. The plugin sent an action that is not registered for the current authentication state. By contrast, a cached admin or front-end page can submit a token WordPress no longer accepts. Use two checks to separate them: Capture the request payload and locate the action parameter; and compare logged-in and logged-out behaviour because they use different hooks. Those observations usually show whether the next safe move is to reproduce with caches and script optimisation bypassed for your own session or to preserve the current state and widen the investigation.
On a production WordPress site, repeat the failing request while checking a known-good page and the admin area. A fault isolated to one route calls for a narrower rollback than a failure affecting PHP, the database or every request. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not whitelist all requests to admin-ajax.php. That endpoint can perform privileged operations and should remain protected by capability and nonce checks.
How to verify the repair
- The original action returns the plugin’s intended response.
- Logged-in and logged-out access behave according to the feature’s design.
- Unrelated invalid AJAX actions remain rejected.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
WP REPAIR INCIDENT STANDARD
Safe intervention sequence
admin-ajax.php serves many unrelated features, so a 400 on one button does not mean AJAX is globally broken. The failing action name, payload and response distinguish plugin code from caching, security or request-size problems.
- Capture the request payload and locate the action parameter.
- Compare logged-in and logged-out behaviour because they use different hooks.
- Read the response body and any PHP log entry at the same timestamp.
- Check whether a cache, WAF or optimisation layer altered the POST body or nonce.
What must be verified
- The original action returns the plugin’s intended response.
- Logged-in and logged-out access behave according to the feature’s design.
- Unrelated invalid AJAX actions remain rejected.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
If one AJAX button returns a 400, does that mean AJAX is broken site-wide?+
No. admin-ajax.php handles many unrelated actions through a single endpoint, so a 400 on one feature does not indicate the others are affected. Check the specific action name in the failing request before assuming a global fault.
Why does the same feature work when logged in but fail for logged-out visitors?+
Logged-in and logged-out AJAX requests use different hooks — wp_ajax_ for authenticated users and wp_ajax_nopriv_ for everyone else. If only one hook is registered, the corresponding user state will get a 400 while the other works fine.
Should I just whitelist admin-ajax.php in my firewall to stop these errors?+
No. admin-ajax.php can perform privileged operations, so blanket whitelisting removes protection it needs. Instead, confirm which field or value the WAF is stripping or rejecting and adjust that specific rule.
I regenerated the page but the request still fails — what else could be wrong?+
A stale nonce from a cached page is a common cause, but a malformed payload — for example JavaScript sending JSON where WordPress expects form-encoded data — produces the same symptom. Capture the actual request payload and compare it against what the registered action expects.