WordPress REST API Returning 404

What this error means & how to recognize it

• Opening /wp-json/ returns an HTTP 404 page instead of the REST API index JSON.
• A JavaScript application, mobile app, REST client, editor, or integration reports 404 Not Found for a WordPress API request.
• The WordPress front end loads normally while REST requests fail.
• ?rest_route=/ works even though the pretty /wp-json/ path returns 404.
• The API index loads, but a plugin or custom endpoint returns 404.
• WordPress Site Health reports that the REST API is unavailable; the response body and status code still need to be checked to identify the source.

Root causes, ordered by likelihood

1. Stale or missing permalink rewrite rules. This is common after a migration, permalink change, server change, or incomplete deployment.
2. Web-server or proxy routing does not forward /wp-json/ to WordPress. Apache rewrite support, Nginx try_files routing, document-root mapping, or virtual-host settings may be incorrect.
3. A security, firewall, CDN, cache, or hosting rule is returning 404. Some controls hide blocked requests by returning not found rather than forbidden.
4. A plugin or theme changes REST behavior. It may remove routes, restrict access, or filter REST responses.
5. Only one custom or plugin endpoint is incorrect. The request may have the wrong namespace, route, version, HTTP method, or resource ID, or the route may not be registered.
6. The request targets the wrong installation path or site. Domain changes, subdirectory installs, redirects, stale application settings, and cached responses can leave clients using an outdated API base path.

How to fix it

1. Confirm the scope and source of the 404

Record the exact request path, HTTP status, response body, response headers, request method, and timestamp. Check whether the response appears to come from WordPress, the web server, a reverse proxy, a CDN, or a security layer. Do not include access tokens, cookies, passwords, or private response data in diagnostic records.

Test the REST API index at /wp-json/ from an appropriate client. If the index returns JSON but one endpoint returns 404, go directly to step 5. If the index itself returns 404, continue.

2. Refresh WordPress rewrite rules

In the WordPress dashboard, open Settings → Permalinks and click Save Changes without changing the selected permalink structure. This refreshes WordPress's rewrite configuration.

Test /wp-json/ again. If deployment automation or a hosting control panel manages server configuration, confirm that the rewrite settings are persisted and are not overwritten by the next deployment.

3. Compare the pretty path with the fallback route

Test the REST API using WordPress's query-parameter fallback: ?rest_route=/ appended to the site's normal home address. Use the actual scheme, hostname, and installation path. A subdirectory installation may require that path to remain part of the request.

• Fallback works but /wp-json/ fails: WordPress can process REST requests, so investigate pretty-URL rewrites, virtual-host settings, proxy routing, document-root mapping, and migration changes.
• Both fail: inspect security controls, server front-controller routing, WordPress and plugin behavior, and the configured site or installation path.
• Both index requests work but one custom route fails: diagnose that endpoint specifically in step 5.

4. Check web-server, proxy, and security routing

For Apache, have an authorized administrator verify that rewrite support is enabled for the WordPress directory and that the site's rewrite rules are present and permitted by the virtual-host configuration. For Nginx or a reverse proxy, verify that requests reach the WordPress front controller and that /wp-json/ is not being treated as a missing static file.

Review the relevant records in this order:

1. Web-server access and error logs for the failed request.
2. CDN, load-balancer, and reverse-proxy rules and cache entries.
3. WordPress security, firewall, login-protection, and REST-control plugins.
4. Hosting-level WAF rules that may classify the path, method, or request headers as blocked.

Make one controlled change at a time, record the original setting, and purge only the relevant cache after authorization. Do not broadly disable a production firewall or security plugin without an approved maintenance plan. If a security rule is responsible, allow the required REST path and methods narrowly rather than bypassing all protection.

5. Diagnose a single missing endpoint

Confirm the endpoint's exact namespace, route, version segment, HTTP method, trailing path, and resource identifier. Compare the request with the route documentation or registration code supplied by the plugin or application.

Verify that:

• The responsible plugin or theme is active in the environment being tested.
• Route registration runs during REST initialization.
• The route has the expected permission callback and is not conditionally omitted for the current request.
• The client uses the current site's API base path rather than an old domain, subdirectory, or cached application setting.
• The requested resource actually exists. A missing post, user, product, or other resource can produce a legitimate endpoint-level 404 even when the REST API is healthy.

Check the API index or route-discovery response where available. If the expected route is absent, investigate registration, plugin status, namespace, and environment-specific configuration rather than treating the issue as a general REST outage.

6. Recheck after each controlled change

Retest from a browser, an authorized API client, and, when relevant, the application that reported the error. Compare the status code, response headers, response body, and response origin before and after each change. Restore temporary diagnostic changes and document the final rewrite, firewall, cache, proxy, or plugin configuration.

Prevention & how to verify the fix

• Add a REST API smoke test for /wp-json/ and each business-critical custom route to migration and deployment checks.
• Keep the WordPress site URL, home URL, document root, and subdirectory configuration consistent across environments.
• Manage rewrite configuration, proxy rules, firewall policies, and cache behavior as documented deployment settings rather than undocumented server changes.
• Review security-plugin and WAF changes for effects on both authenticated and unauthenticated REST requests.
• Monitor response status and response origin for important API calls so a proxy-generated 404 can be distinguished from a WordPress-generated 404.
• Document custom namespaces, routes, supported methods, permission behavior, and the plugin or theme responsible for each endpoint.