A WordPress REST API error in Site Health usually means the dashboard can load, but WordPress cannot complete a request to its REST endpoints. Start with the safe checks first: read the exact Site Health message, test the REST URL in your browser, refresh permalinks, then check security, caching, redirects, and server rules.
Read the exact Site Health message
Open Tools > Site Health > Status and expand the REST API issue. WordPress uses the Site Health screen to show critical issues and recommended improvements, and the expanded message often includes the failing URL, HTTP status code, or response text.
Use that detail to choose the next step:
404usually points to permalinks, rewrite rules, or server routing.401or403usually points to authentication, a security plugin, firewall, or blocked authorization header.500usually points to a PHP fatal error, plugin conflict, theme conflict, or server-side failure.- A timeout often points to hosting, DNS, SSL, firewall, proxy, or loopback restrictions.
The REST API is a normal WordPress feature. WordPress describes it as an interface for sending and receiving site data as JSON in the REST API Handbook, so a healthy site should not block it globally.
Test the REST API URL in your browser
Visit this URL, replacing example.com with your domain:
https://example.com/wp-json/A working endpoint usually shows JSON data, not a styled WordPress page.
If you see a 404 page, refresh permalinks next. If you see a login redirect, firewall screen, blank page, maintenance page, or HTML error document, keep that result in mind while checking security, caching, redirects, and hosting rules.
Also test the exact domain version saved in Settings > General under WordPress Address (URL) and Site Address (URL). If your site mixes www and non-www, or HTTP and HTTPS, REST requests may pass through redirects or rules that behave differently from normal page views.
Refresh permalinks
For many 404-style REST API errors, refresh WordPress rewrite rules first.
Go to Settings > Permalinks and click Save Changes without changing the permalink structure. This is usually safe, but it can update rewrite configuration, so avoid doing it during a fragile deployment or high-traffic change window.
After saving, test /wp-json/ again in your browser and refresh Tools > Site Health.
Check security plugins and firewall settings
Security plugins often include REST API restrictions. That can be useful when configured narrowly, but blocking all REST requests can break Site Health, the block editor, WooCommerce, forms, application passwords, mobile apps, and integrations.
Review settings with names like:
- Disable REST API
- Block REST API for non-logged-in users
- Protect
/wp-json/ - XML-RPC and REST hardening
- Firewall rules for JSON requests
- Bot protection or rate limiting
Do not permanently disable a security plugin just to clear Site Health. Instead, briefly pause the specific REST restriction, test /wp-json/ and Site Health, then re-enable protection with a narrower allow rule if that was the cause.
If the site uses Cloudflare, Sucuri, a host firewall, or another web application firewall, check whether /wp-json/ is being challenged, redirected, cached, or blocked.
Check login and authentication errors
A 401 or 403 REST API error can happen when WordPress receives the request but rejects it, or when authentication details are stripped before WordPress sees them.
Look in the Site Health details, browser response, and server logs for phrases such as:
rest_forbiddenrest_cookie_invalid_nonce- missing
Authorizationheader - “Sorry, you are not allowed to do that.”
- login redirects on
/wp-json/
This matters most for application passwords, headless front ends, mobile apps, custom integrations, membership sites, and plugins that call authenticated REST routes.
If the site uses Apache, Nginx, a reverse proxy, or managed hosting, ask the host whether Authorization headers are passed through to PHP. Avoid adding random .htaccess snippets unless your host confirms they match your server stack.
Rule out plugin or theme conflicts
If /wp-json/ returns a 500 error, malformed JSON, a blank page, or unexpected HTML, a plugin or theme may be causing a fatal error or sending output during REST requests.
Use a staging site if possible. If you must test on production, do it during a quiet period and change one thing at a time.
- Update WordPress core, plugins, and the active theme if those updates are already approved for the site.
- Temporarily deactivate the most likely plugin first: security, caching, optimization, membership, redirection, API, or custom code plugins.
- Test
/wp-json/and Site Health after each change. - Re-enable each plugin before moving to the next one.
If the REST API starts working after one plugin is disabled, keep it disabled only long enough to identify the setting, version, or conflict responsible. Then update, reconfigure, replace, or report the issue to the plugin vendor.
If plugins do not explain the error, briefly switch to a default WordPress theme on staging and test again. On a live site, only do this if you understand the visual impact or can put the site in maintenance mode.
Check caching, redirects, and proxy behavior
REST API responses should not be handled like normal public pages. Page cache, CDN cache, redirect plugins, maintenance mode, and reverse proxies can all cause REST requests to receive the wrong response.
Check whether /wp-json/ is:
- redirected to the homepage
- redirected to login
- cached as HTML
- blocked by bot protection
- forced between HTTP and HTTPS
- forced between
wwwand non-www - returning a maintenance-mode page
Purge caches after changing permalink, security, SSL, redirect, or CDN settings. If the problem only happens through the public domain and not inside the hosting environment, the CDN, proxy, or firewall layer is a strong suspect.
Optional WP-CLI check for SSH users
If you have SSH access and already use WP-CLI, you can refresh rewrite rules from the command line instead of using Settings > Permalinks:
wp rewrite flushWP-CLI documents this command in the wp rewrite flush reference.
If the command warns that rewrite rules are empty, check Settings > Permalinks, choose the intended structure, save it, then test /wp-json/ again. Do not keep flushing rewrite rules repeatedly; it will not fix a security plugin, firewall, PHP error, or proxy problem.
Ask your host or developer with the right details
Contact your host or developer when the REST endpoint still fails after permalinks, plugins, security rules, cache, redirects, and CDN settings have been checked.
Send the useful details:
- the failing REST URL, such as
https://example.com/wp-json/ - the HTTP status code shown in Site Health
- the visible error text
- whether the issue changes when security or cache rules are paused
- whether the site uses a CDN, WAF, reverse proxy, or custom server rules
Do not send full database exports, access tokens, cookies, or administrator passwords. Your host should be able to check web server logs, PHP errors, firewall events, and proxy rules without needing those.