Fix WordPress AJAX and Admin Errors

Find the failed request behind an unresponsive button

A Save button that keeps spinning can hide a failed request between your browser and WordPress. The visible page alone does not show whether a login expired, a security rule intervened or the server encountered an error. This guide explains how to capture that failed action and use its response to choose the next check, without asking you to write JavaScript.

Chrome Network panel with request names on the left and the selected request Headers on the right — Select the request triggered by your failed action, then read its URL and Status Code in Headers. This unchanged Google example is a successful documentation-page request, not an admin-ajax.php failure. Your request's Response tab supplies the additional evidence discussed below. Credit: Chrome for Developers / Google, CC BY 4.0.

Protect unsaved work and refresh the session

Copy unsaved text into a private document before refreshing the editor. For a form or payment action, check whether it already completed before pressing the button again. Record the exact action, page and time, plus any visible error.

Open a new tab at your normal HTTPS dashboard address and sign in again if prompted. Return to a fresh copy of the affected screen and try with a test draft. WordPress uses time-limited request checks called nonces; an old open tab can submit a check that is no longer valid. Never remove that protection to make a request pass.

Try a private browser window with browser extensions disabled. If it works there, investigate that browser's extensions and site data first. If the problem remains, use the request check below or give the recorded action and time to support.

Find the failed request in Chrome

This inspection reads what the browser already sends; you do not need to write or paste code. Request details can contain private information, so do not share a full network export publicly.

Open the affected screen. In Chrome's menu choose More tools > Developer tools, then select the Network tab.
Select Fetch/XHR to focus on background requests. Clear the request list using its clear control, then reproduce the problem once with test data.
Look for the request created at that moment. Classic WordPress AJAX uses admin-ajax.php; other editor and plugin actions use addresses containing wp-json. Do not assume every admin failure uses the same endpoint.
Select the request and read Headers for its request address and status code, then Response for a short error message. Record only the path, status, error text and time, excluding cookies, tokens and customer details.

Use the response to choose the next step

A login page or a failed request-check message calls for the fresh-session test above. WordPress can return -1 when rejecting a nonce, but the specific plugin's handling must be checked.
For a 403 response, follow the forbidden-error guide. Have the host or firewall provider trace the exact request before creating an exception.
Investigate a 500 response through the matching PHP or server log. Follow the server-error guide, using private logging only when needed.
Status 200 means HTTP success, but the response can still contain an application error or unexpected page. Check the response and whether the intended save actually happened.
If no request appears, the button's browser code may have failed before sending anything. Record any red error in the Developer Tools Console tab and give the message to the plugin author; do not paste suggested console commands.

Test the component that owns the action

Take a backup and reproduce the fault on a staging copy. Follow the conflict guide, keeping the plugin responsible for the button or editor active. Removing that plugin also removes the action and cannot demonstrate a repair.

If a recent optimisation change is involved, record its settings and test reversing only that change on staging. Ask the caching provider to confirm dashboard pages and personalised requests are excluded from page caching. Purging public page caches alone does not correct a cached or redirected admin request.

After a domain or HTTPS change, compare the dashboard address with the configured WordPress address using the URL guide. Do not change working URLs without evidence or add a blanket cross-origin exception. The request can be failing because it points at the old domain.

Verify saved data, uploads and session recovery

Repeat the original action with a test draft, reload the screen and confirm the saved value persists. For a media problem, upload a small permitted test image, confirm it appears in the library and can be inserted into a draft, then remove the test item if no longer needed.

Test again after signing out and back in. Restore diagnostic changes that did not contribute to the repair and turn off temporary logs. Give support the isolated plugin combination and response details if the failure remains. Re-saving permalinks is not a general repair for admin-ajax.php, which is a direct PHP endpoint.

Reference material

Chrome's Network panel guide explains request inspection. WordPress documents nonces and the behaviour of AJAX request verification.

Get help with the next step

If saving or uploading still fails, ask BugShield to trace the admin error. The failed action, response status and recent changes give a developer a useful starting point without requiring you to debug PHP.

Questions answered

How to fix WordPress AJAX and admin errors FAQs

Does a spinning button mean nothing was saved?

No. The server can complete work before the browser fails to handle its response. Reload a separate view to check the saved result before repeating an action that creates records or payments.

What does a response containing -1 mean?

WordPress can return -1 when an AJAX nonce check fails. Start with a fresh login and newly loaded screen, then have the plugin's response handling checked if the error continues.

Is status 200 proof the action worked?

No. It describes the HTTP response. The body can contain an error or a login page, so verify the intended change was stored and remains after reloading.

Should I allow every request to admin-ajax.php?

No. That address serves many actions. Trace the specific blocked request and adjust only a confirmed incorrect rule while preserving authentication and request checks.

Why is there no admin-ajax.php request?

The action can use the WordPress REST API under wp-json, or its browser code can fail before sending a request. Inspect the request made at the failure time rather than filtering only one filename.

Keep troubleshooting

How to fix WordPress AJAX and admin errors