A plugin update goes fine, the site loads, and then things start breaking in ways that don't quite make sense: the block editor won't save, a contact form times out on submit, WooCommerce checkout hangs on "processing," or a page builder just shows a blank canvas. Nine times out of ten, when we pull up the browser console on a ticket like this, we find the same culprit: a failing request to /wp-json/. WordPress's REST API is quietly running the show behind half the modern editor and plugin ecosystem, and when it's blocked, the front end usually still loads fine while everything that depends on AJAX-style calls quietly falls apart.
The Symptom
You won't usually see an obvious error message pointing at "REST API." Instead you'll see side effects:
- Gutenberg shows "Updating failed" or "The response is not a valid JSON response" when you try to save a post.
- Contact Form 7, WPForms, or Gravity Forms submissions spin forever or fail silently.
- WooCommerce cart/checkout AJAX calls return errors, or the cart total won't update.
- A page builder (Elementor, Divi, Beaver Builder) loses its editing panel or won't load the live preview.
- Mobile apps or headless front ends connecting to your WordPress backend get 403 or 404 responses instead of JSON.
The quickest way to confirm it's the REST API and not something else is to hit the endpoint directly.
curl -I https://yourdomain.com/wp-json/A healthy site returns HTTP/1.1 200 OK with a JSON body when you drop the -I. If you get a 403, 404, 406, or a 500 instead, you've found your problem — now it's a matter of narrowing down which layer is blocking it.
What's Actually Going Wrong
The REST API can get blocked at several different layers, often stacked on top of each other, which is why "just deactivate one plugin" doesn't always fix it. The usual suspects, roughly in order of how often we see them:
- A security plugin's firewall rules. Wordfence, Solid Security (formerly iThemes), All In One WP Security, and similar plugins ship with options to "disable REST API for non-logged-in users" or firewall rules that treat POST requests to
/wp-json/as suspicious. - A broken or missing permalink structure. If permalinks are set to "Plain," or the rewrite rules got wiped during a migration,
/wp-json/URLs 404 because there's no rewrite rule routing them toindex.php. - ModSecurity / WAF rules at the server level. cPanel servers running ModSecurity with OWASP or vendor rule sets sometimes flag JSON POST bodies or certain query strings as SQL injection attempts and return a 403 before WordPress even sees the request.
- A caching layer serving a stale or cached error. Some full-page cache plugins or Cloudflare page rules cache the 403/404 response itself, so even after you fix the root cause, you keep seeing the old error until the cache clears.
- A malformed
.htaccessfile. A stray rewrite rule from a security hardening guide (or a previous "harden your site" pass) can accidentally block any URL containingwp-json, thinking it's blocking XML-RPC.
Diagnosing Which Layer Is Blocking It
Work through this in order — it's the fastest way to isolate the cause without guessing:
1. Check the response code directly
curl -sI https://yourdomain.com/wp-json/wp/v2/postsA 401 is normal for some endpoints if authentication is required — that's not a problem. A 403 or 406 usually means something is actively blocking the request. A 404 usually means routing is broken.
2. Temporarily disable security plugins
Rename the plugin's folder over SFTP or via cPanel File Manager rather than deactivating through wp-admin — if the REST API is broken, wp-admin's own AJAX calls might be affected too. Go to wp-content/plugins/ and rename the suspect folder (e.g. wordfence to wordfence-off), then retest the curl command above.
3. Reset permalinks
In wp-admin, go to Settings → Permalinks and click Save Changes without changing anything. This rewrites the rules in .htaccess and often fixes 404s on /wp-json/ without any other change.
4. Check .htaccess for stray rewrite rules
Open .htaccess in cPanel File Manager and search for wp-json or xmlrpc. A block like this is a common leftover from over-aggressive hardening:
<IfModule mod_rewrite.c>
RewriteCond %{REQUEST_URI} wp-json [NC]
RewriteRule .* - [F,L]
</IfModule>That rule 403s anything containing "wp-json," which is exactly the endpoint you need. Remove or comment it out, save, and retest.
5. Check ModSecurity in cPanel
If you have access to WHM or a ModSecurity toggle in cPanel's Security section, check the ModSecurity Tools log for hits matching your domain around the time of the failed requests. If you find rule IDs firing on /wp-json/ POST requests, you (or your host) can disable that specific rule ID for your domain instead of disabling ModSecurity entirely — ask your hosting provider's support team to whitelist the rule ID for your account if you don't have WHM access yourself.
The Fix, Once You've Found the Layer
| Cause | Fix |
|---|---|
| Security plugin blocking REST API | Find the specific setting (usually under Firewall or Advanced settings) and allow REST API traffic, or exclude /wp-json/ from the firewall rule instead of disabling the whole plugin |
| Broken permalinks | Settings → Permalinks → Save Changes to flush rewrite rules |
| Bad .htaccess rule | Remove the rule blocking wp-json, keep everything else intact |
| ModSecurity false positive | Ask hosting support to exclude the specific rule ID for your domain |
| Stale cache serving old error | Purge object cache, page cache, and any CDN/Cloudflare cache, then retest |
After applying a fix, always retest with the curl command from earlier before moving on to the next possible cause — it's easy to "fix" three things and never confirm which one actually mattered, which makes the next incident harder to diagnose.
Prevention
- Whenever you install a new security plugin, specifically check its REST API settings before going live — most have a dedicated section, not just a general firewall toggle.
- Keep a copy of your working
.htaccessfile saved somewhere outside the site (locally, or in a private note) so you can compare it if something changes unexpectedly after a plugin update. - If you manage a headless front end or mobile app that depends on the REST API, add a scheduled uptime check against
/wp-json/itself, not just the homepage — the homepage can return 200 while the API is fully blocked. - Document any ModSecurity rule exclusions your host applies for you, including the rule ID, so a future migration or new hosting account doesn't silently reintroduce the same block.
Frequently Asked Questions
Is it safe to disable the REST API entirely?
Only if you're certain nothing on your site depends on it, which is rare on a modern WordPress install. The block editor, most page builders, the WordPress mobile app, and many form plugins all use it internally. Disabling it wholesale usually causes more breakage than it prevents.
Does disabling XML-RPC also affect the REST API?
No — they're separate systems. XML-RPC lives at /xmlrpc.php and the REST API lives at /wp-json/. It's common for hardening guides to lump them together, but blocking one doesn't require blocking the other, and blocking the REST API by mistake while trying to lock down XML-RPC is exactly the scenario covered above.
Why does the REST API work when I'm logged in but not when logged out?
Some security plugins specifically restrict REST API access for unauthenticated (logged-out) visitors, which breaks anything public-facing — like a contact form on the front end — while admin-only functionality keeps working. Check for a setting like "Disable REST API for non-logged-in users" if this matches your symptoms.
I fixed the underlying cause but the error still shows — why?
A caching layer, whether a WordPress caching plugin, server-level page cache, or Cloudflare, may have cached the failed response itself. Purge all layers of cache (plugin cache, any object cache, and CDN cache) and retest with a cache-busting query string or an incognito window.
Can a hosting-level firewall block the REST API even if WordPress itself is configured correctly?
Yes. ModSecurity, Cloudflare's WAF, and similar tools sit in front of WordPress and can reject a request before it ever reaches PHP. If you've ruled out plugins, permalinks, and .htaccess and you're still seeing 403s, this is the next place to check — usually with help from your host's support team.
