WordPress REST API Blocked: Safe Ways to Find and Fix the Cause

A WordPress REST API blocked message usually means WordPress or an external service cannot make an HTTP request to your site. The cause may be a firewall rule, maintenance mode, authentication requirement, SSL problem, plugin conflict, or hosting restriction.

This does not automatically mean your site is hacked. It does mean an important communication path is failing and should be diagnosed before you disable security features or make broad server changes.

What the WordPress REST API does

The REST API lets WordPress exchange structured data over HTTP. The block editor uses it to load and save content, while plugins and external services may use it for forms, analytics, backups, ecommerce features, and integrations.

WordPress also checks related HTTP communication in Tools → Site Health. Depending on your WordPress version, the warning may say that requests to your site are being blocked by a firewall or security rule. The exact wording can vary.

A site can still appear to load normally while REST API requests fail. Visitors may see pages, but administrators could encounter a broken editor, failed updates, missing previews, or integration errors.

Start with the exact Site Health result

Open Tools → Site Health → Status and expand the REST API or loopback-related test. Record the complete message, the URL involved if shown, and whether the test is marked as a recommendation or critical issue.

Do not rely only on the color of the warning. A failed test may affect one feature without taking down the entire website.

Check whether the problem is public or authenticated

• Open your homepage in a private browser window.
• Try the block editor while logged in.
• Test a REST endpoint such as https://example.com/wp-json/, replacing the domain with your own.
• Compare the result from your normal connection with a different network, such as mobile data.

The /wp-json/ URL should normally return JSON describing the available API routes. A login page, 403 response, 406 response, server error, redirect loop, or timeout gives you a useful direction.

Common reasons the REST API is blocked

1. A firewall or security plugin is denying the request

Web application firewalls, hosting security layers, CDN rules, and security plugins can block requests that look unusual. A rule may be triggered by the request method, user agent, IP reputation, rate limit, query string, or a false positive.

Review the security tool’s live traffic, blocked requests, or firewall log. Look for the time of the Site Health test and the path beginning with /wp-json/. If a rule is clearly responsible, allow the specific request or adjust the narrowest matching rule rather than turning off the entire firewall.

If Cloudflare or another proxy is in front of the site, inspect both the proxy firewall and the origin host firewall. A request may be accepted by one layer and rejected by another.

2. Basic authentication or maintenance protection is active

Staging sites and protected development environments often require a username and password before WordPress can be reached. WordPress cannot complete its own loopback or REST checks if the server returns an authentication prompt.

Check for hosting-level password protection, a staging lock, maintenance plugin, or security setting that restricts non-browser requests. If protection must remain enabled, ask the host whether internal requests can be permitted safely.

3. The site is redirecting the API request

Incorrect HTTPS settings, conflicting site URLs, or proxy configuration can redirect /wp-json/ repeatedly or send it between HTTP and HTTPS. This is especially common after moving hosts or changing CDN SSL modes.

Compare the WordPress and Site URLs under Settings → General, if the fields are available. They should use the correct protocol and domain. Do not edit these values casually on a live site; incorrect changes can lock you out.

For a redirect-specific diagnosis, see our guide to fixing WordPress redirect loops.

4. A plugin or theme is interfering

A plugin can disable REST routes, add authentication requirements, modify headers, or reject requests it does not recognize. A theme can also produce PHP warnings or fatal errors before the API response is completed.

Before troubleshooting on a busy production site, create a backup and use a staging copy when possible. Then temporarily deactivate plugins one at a time, testing the API after each change. If you cannot access the dashboard, use hosting tools or SFTP to rename the wp-content/plugins directory temporarily; this disables plugins as a group and should be treated as a diagnostic step.

When the REST API starts working, reactivate extensions individually until the failure returns. Update, replace, or reconfigure the extension that caused the conflict.

For a safer general conflict workflow, see how to troubleshoot WordPress behavior that changes for logged-in users.

5. The server returns an error before WordPress responds

PHP fatal errors, exhausted resources, invalid server rules, and damaged files can prevent a valid REST response. Check the hosting error log and WordPress recovery email, if one was sent.

A response containing an error instead of JSON may also appear as an editor message saying that the response is not valid JSON. That symptom has several possible causes, including REST API access, SSL, permalinks, and plugin output. See the guide to the “response is not a valid JSON response” error for a related diagnostic path.

Safe troubleshooting sequence

1. Back up first. Keep a current database and file backup before changing plugins, server rules, or URLs.
2. Test /wp-json/. Note the HTTP status, redirects, and response body.
3. Check security logs. Review WordPress security plugins, the CDN, and hosting firewall for a matching block.
4. Check authentication. Remove or temporarily bypass staging protection only in a controlled environment.
5. Test plugins and the theme. Use staging when possible and change one variable at a time.
6. Review SSL and URLs. Confirm that the domain, protocol, and proxy configuration agree.
7. Clear relevant caches. Purge page, object, CDN, and browser caches after a configuration change.
8. Retest Site Health and the editor. A successful browser request alone does not prove that WordPress’s internal request now works.

Use logs instead of guessing

The most useful evidence is usually the HTTP status code and the server log entry. Common clues include:

• 401 or 403: authentication, permissions, WAF rules, or security software.
• 406: a web application firewall may be rejecting the request format.
• 429: rate limiting or request throttling.
• 500 or 503: a PHP, server, resource, or maintenance failure.
• 301 or 302 repeatedly: a redirect or HTTPS configuration problem.
• Timeout: the host, firewall, DNS, or upstream service is not responding in time.

Ask your hosting provider to check the origin access and error logs for the exact REST request time. Include the URL, status code, response headers if available, and whether the request came through a CDN.

What not to do

• Do not permanently disable the firewall just to remove the Site Health warning.
• Do not add a broad allow rule for every IP address without understanding the security impact.
• Do not delete .htaccess, core files, or database entries as a first step.
• Do not install several security or REST-control plugins to test random fixes.
• Do not ignore a failed API check if the editor, updates, forms, or integrations are also failing.

If you recently found suspicious redirects, unknown administrator accounts, or modified files, treat the situation as a possible compromise instead of assuming it is only a firewall issue. Review the safe steps for a hacked WordPress site and avoid cleaning files while attackers may still have access.

When professional help is appropriate

Contact your host or a WordPress specialist when the request crosses several infrastructure layers, the firewall log is unclear, the site is business-critical, or changing one setting causes another failure. A specialist can compare origin and proxy responses, inspect logs, isolate plugin output, and make a narrow exception without weakening the whole site.

For ongoing updates, security monitoring, backups, and technical maintenance, review WP Fix It Care and Site Manager. If the problem is part of a wider outage or configuration failure, WordPress site repair may be more appropriate than a single plugin change.

Confirm the repair

After making a change, perform the same checks that revealed the issue:

• Open /wp-json/ and confirm it returns a valid JSON response.
• Run the REST API test again under Tools → Site Health.
• Create or edit a post in the block editor.
• Test any affected forms, ecommerce features, backups, or external integrations.
• Review firewall and server logs to ensure the request is allowed for the right reason.

For background on WordPress administration and troubleshooting, consult the official WordPress Documentation. The goal is not merely to make the warning disappear; it is to restore the specific communication path while keeping authentication, HTTPS, and firewall protections intact.