TL;DR
When the WordPress REST API is not working, identify the failing layer before disabling security. Most problems come from permalinks, rewrites, security plugins, authentication, CORS, cache, or server firewalls.
- Test /wp-json/ and a known route while logged out and logged in.
- Use the HTTP status code to separate 404 rewrite issues, 401 or 403 permission issues, and 500 PHP errors.
- Restrict sensitive routes carefully instead of blocking the full REST API without testing Gutenberg and plugins.
Start With a Baseline Test
Open the site root REST endpoint at /wp-json/. A healthy endpoint usually returns JSON listing namespaces and routes. Then test a known route such as /wp-json/wp/v2/posts. Record the HTTP status, response body, and whether the result changes when logged in or logged out.
A 404 often points to permalinks or rewrites. A 401 or 403 points to authentication, permissions, or security rules. A 500 points to PHP errors or a plugin callback. An HTML response instead of JSON may mean a firewall, cache, maintenance page, or host-level rule is intercepting the request.
Check Permalinks and Rewrite Rules
WordPress REST URLs depend on rewrite behavior. If permalinks are broken, the REST API may return 404 even when WordPress itself loads. In the admin, saving the permalink settings can flush rewrite rules. On Apache, confirm .htaccess is writable or correctly deployed. On Nginx, confirm the server block passes requests to WordPress correctly.
Do not fix a REST 404 by opening every path. Test normal posts, pages, admin URLs, and REST routes together. A rewrite change that fixes /wp-json/ but breaks pretty permalinks or static assets is not a real fix.
Review Security Plugin Restrictions
Security plugins often include REST API hardening. Some block all public REST access. Some block only user enumeration routes. Some require authentication for routes that were previously public. These settings can be useful, but they can also break editors, forms, payments, analytics dashboards, and mobile apps.
Temporarily disable REST restrictions on staging, then retest the failing workflow. If the API works, add restrictions back route by route. A safer policy is to restrict sensitive endpoints and leave required public routes available. Blanket blocking looks clean on a dashboard but can damage real functionality.
Separate Public Routes From Authenticated Routes
Some REST routes are public by design. Others require a logged-in user, a nonce, application passwords, OAuth, or a plugin-specific key. If a request works in the browser while logged in but fails from an external app, the problem is probably authentication rather than the API being disabled.
Check whether the external request sends credentials correctly. For browser requests, inspect the nonce and cookies. For external integrations, confirm the authentication method, HTTPS, user capability, and whether the user role can perform the action. A valid login with the wrong capability can still return a permission error.
Do Not Ignore CORS, Cache, and Firewalls
A same-site REST request can work while a cross-origin app fails because of CORS headers. A route can work for one user but fail for another because a cache stores the wrong response. A firewall can return a branded 403 page that looks like a WordPress permission problem until you inspect the response headers.
Clear page cache, object cache, CDN cache, and browser cache before retesting. Then check server logs for blocked requests. REST API troubleshooting is much faster when you compare the exact failing URL, method, headers, and response body rather than guessing from a frontend error message.
Safe Troubleshooting Checklist
- Test
/wp-json/and a known route while logged out and logged in. - Record status code, response body, headers, and server log entry.
- Check permalinks, .htaccess, Nginx rules, and hosting rewrites.
- Review security plugin REST restrictions one setting at a time.
- Confirm authentication, nonce, application password, and user capability.
- Clear cache layers before retesting.
- Restrict sensitive routes instead of disabling the whole API blindly.
Frequently Asked Questions
Can disabling REST API break Gutenberg?
Yes. The block editor uses REST requests for saving, previews, media, patterns, and plugin features. Test editor workflows before applying restrictions.
Is public REST API access always unsafe?
No. Public read routes are normal on many WordPress sites. The security question is whether sensitive data or write actions are exposed without proper permissions.
Why does /wp-json/ return HTML?
A firewall, cache, maintenance page, redirect, or server rule may be intercepting the request. Inspect headers and logs to find the layer producing the response.