Fix WordPress admin-ajax.php Errors (403/400/500)

If your WordPress dashboard has started throwing blank saves, a spinning "Loading..." that never finishes, or a red error banner mentioning admin-ajax.php, you're not looking at a broken site — you're looking at one broken request type. Menus, post editing, WooCommerce cart updates, live search, comment forms, and half the plugins on your site all lean on this one file. When it starts returning 400, 403, or 500, everything that depends on it quietly stops working while the rest of the site loads fine.

What admin-ajax.php Actually Does

wp-admin/admin-ajax.php is WordPress's built-in traffic cop for AJAX requests — the background calls a page makes without a full reload. A theme's "load more posts" button, a contact form's submit handler, WooCommerce's "add to cart" counter, autosave in the block editor — all of it routes through this one endpoint, tagged with an action parameter that tells WordPress which function to run. Because so much traffic funnels through a single file, it's also a magnet for security rules that don't know the difference between a legitimate AJAX call and a bot probing for weaknesses.

Symptom: What You'll Actually See

• Browser console shows a failed request to /wp-admin/admin-ajax.php with status 403, 400, or 500
• "Update failed" or a spinning save button in the block editor that never completes
• WooCommerce cart/checkout totals not refreshing, or "add to cart" doing nothing
• Contact form plugins (Contact Form 7, WPForms, Gravity Forms) failing silently on submit
• Front-end search-as-you-type or infinite scroll simply not returning results

Open your browser's DevTools (F12), go to the Network tab, reproduce the action, and look for the admin-ajax.php request. The status code there tells you which of the causes below you're dealing with.

Cause 1: A Firewall or Security Plugin Is Blocking the Request (403)

A 403 almost always means something between the browser and PHP decided the request looked suspicious. Common culprits:

• ModSecurity / WAF rules on the server flagging the POST body (this is common if the AJAX payload contains raw HTML, like a rich-text form field)
• Security plugins (Wordfence, All In One WP Security, iThemes) with "hide wp-admin" or brute-force protection rules that accidentally catch admin-ajax.php, which lives under /wp-admin/ even though it's used by logged-out visitors too
• .htaccess rules that restrict access to the wp-admin directory by IP, forgetting to whitelist this one file

Check /home/username/logs/domain.com-error_log or, in WHM/cPanel, Metrics > Errors around the timestamp of a failed request. A ModSecurity block usually logs an explicit rule ID.

Cause 2: Caching Is Serving a Stale or Broken Response (400/500)

AJAX responses should never be cached — they're meant to be dynamic. If a page cache plugin or a proxy in front of your site (Cloudflare, Varnish, LiteSpeed Cache) is caching POST requests or applying minification to the JS that builds the AJAX call, you'll get intermittent, hard-to-reproduce failures. This is the classic case where the error "goes away" after a hard refresh, then comes back an hour later.

Cause 3: PHP Memory, Timeout, or a Plugin Conflict (500)

A 500 from admin-ajax.php is a PHP fatal error, same as any other 500 — it's just happening inside an AJAX handler instead of a page load, so it's easy to miss. The usual suspects are identical to any WordPress fatal error:

• PHP memory limit exhausted mid-request (check wp-content/debug.log for "Allowed memory size... exhausted")
• Two plugins registering the same AJAX action hook and colliding
• A plugin calling a function that no longer exists after a WordPress or PHP version upgrade

The Fix: Isolate, Then Correct

Step 1 — Confirm it's not a permissions or missing-file issue. Run a direct check:

curl -I https://yourdomain.com/wp-admin/admin-ajax.php

A plain GET with no action parameter should return 200 with the text 0 in the body — that's WordPress correctly telling you "no valid action was requested." If you get a 403 or 500 on this bare request, the problem is server-side (firewall, permissions, or a fatal error on every load) and has nothing to do with the specific plugin triggering the real request.

Step 2 — If it's a 403, whitelist the file explicitly. In cPanel's ModSecurity Tools, find the rule ID from your error log and disable it for your domain only — don't disable ModSecurity site-wide. If a security plugin is the cause, check its firewall rule log (Wordfence: Wordfence > Tools > Live Traffic) for a blocked entry tied to admin-ajax.php and add an allow rule for that specific action.

Step 3 — If it's inconsistent (works, then fails), exclude AJAX from caching. Most cache plugins have this by default, but confirm:

Step 4 — If it's a 500, raise PHP's memory limit temporarily via MultiPHP INI Editor in cPanel and check wp-content/debug.log (enable it with WP_DEBUG_LOG in wp-config.php if it's not already on) for the exact fatal error and file. Deactivate plugins one at a time — starting with anything recently updated — until the error stops.

Prevention

Once it's fixed, a few habits keep it from coming back:

• Whenever you add a new security plugin or firewall rule, immediately test the block editor's "Update" button and your checkout flow before walking away — that's the fastest way to catch an over-eager rule
• Keep WP_DEBUG_LOG enabled on staging so plugin conflicts surface before they hit production
• Explicitly exclude admin-ajax.php from any new caching or CDN layer the moment you set it up, rather than waiting for a bug report
• Review ModSecurity audit logs after major plugin or theme updates — a new form field name or JS payload shape can trip a rule that was fine yesterday

Frequently Asked Questions

Why does admin-ajax.php get hit even when I'm logged out?

It's intentional. WordPress uses the same endpoint for both logged-in (wp_ajax_{action}) and logged-out (wp_ajax_nopriv_{action}) requests — things like a public search box or an add-to-cart button need it to work for visitors who've never logged in.

Is it safe to just block admin-ajax.php in .htaccess to stop attacks on it?

No — blocking it outright breaks any AJAX-dependent feature, including WooCommerce and most contact forms. Rate-limit or filter by request pattern instead, and only block if you've confirmed nothing on your site legitimately needs it, which is rare.

My error log shows thousands of POST requests to admin-ajax.php with no obvious cause. Is this an attack?

Possibly — admin-ajax.php is sometimes targeted directly by bots probing for known plugin action vulnerabilities. Check the action parameter value in your access logs; if it's not one your plugins actually use, it's noise you can block by pattern in ModSecurity or a firewall rule, separate from legitimate traffic.

Why does the request work in Chrome but fail in Firefox (or vice versa)?

This usually points to a browser extension or a caching difference, not the server. Test in an incognito/private window with extensions disabled first — it rules out client-side interference before you spend time on server configuration.

Can I move admin-ajax.php to a different filename to avoid all this?

Not reliably. Plenty of themes and plugins hardcode the path /wp-admin/admin-ajax.php in their JavaScript, so renaming it breaks more than it protects. Address the specific block or error instead of relocating the endpoint.