How To Check XML RPC Is Disabled In WordPress

How to check XML RPC is disabled in WordPress

XML-RPC is an older WordPress API that still appears on many sites, even when it is not actively used.

If you need to confirm whether it is disabled, there are several reliable checks that reveal both plugin-level and server-level blocking.

This matters because XML-RPC can affect remote publishing, mobile app access, Jetpack connections, and certain brute-force attack patterns.

A quick test is useful, but the most accurate answer usually comes from combining browser, header, and server-side verification.

What XML-RPC does in WordPress

XML-RPC lets external applications communicate with WordPress using structured XML requests.

Historically, it supported remote post publishing, pingbacks, and app integrations before the REST API became the main modern interface.

Remote publishing: posting content from desktop editors or third-party tools.
Mobile access: older WordPress apps relied on XML-RPC heavily.
Jetpack and integrations: some features still use it for connectivity checks.
Pingbacks and trackbacks: legacy features that can be abused in attacks.

Because of its history, many site owners disable XML-RPC for security hardening, while others keep it enabled for compatibility.

Fastest browser test for XML-RPC

The simplest way to check is to visit the XML-RPC endpoint directly in a browser or use a basic HTTP request.

In WordPress, the endpoint is usually /xmlrpc.php on the site’s root domain.

If XML-RPC is disabled, common responses include:

403 Forbidden from a security plugin, firewall, or web server rule.
404 Not Found if the file is hidden or blocked by rewrite rules.
405 Method Not Allowed on some hardened configurations.

If it is enabled, you may see a response such as XML-RPC server accepts POST requests only.

That message does not mean the endpoint is fully open to all traffic, but it does indicate the file is reachable.

How to test with a browser

Open your site in a browser.
Append /xmlrpc.php to the domain.
Observe the status or response text.

A visible XML-RPC message usually means the endpoint is not fully blocked.

A denial response from the web server, WAF, or security plugin suggests it is disabled or effectively inaccessible.

Use curl to confirm the status

For a more accurate result, use curl from a terminal.

This method shows the real HTTP status code and avoids browser caching or redirects that can obscure the outcome.

curl -I https://example.com/xmlrpc.php

If you want to inspect the body as well, use:

curl -s https://example.com/xmlrpc.php

Look for these patterns:

200 OK with a message such as “XML-RPC server accepts POST requests only” means the endpoint exists and responds.
403, 404, or 405 generally means access is blocked or the endpoint is unavailable.
Connection resets or timeouts may indicate a firewall, CDN rule, or server policy is filtering the request.

If your hosting provider uses Cloudflare, Sucuri, Wordfence, or another WAF, the endpoint may be blocked before WordPress ever receives the request.

Check from the WordPress admin area

Some security plugins expose XML-RPC settings directly in the dashboard.

This is useful if you want to know whether the block is intentional and where it is enforced.

Look in places such as:

Security plugin settings: Wordfence, Solid Security, iThemes-style tools, or similar.
Jetpack connection status: if Jetpack features work, XML-RPC or related endpoints may still be accessible.
Plugin logs: some tools record blocked XML-RPC requests.

WordPress core itself does not provide a single “XML-RPC enabled/disabled” toggle in the admin.

If a plugin is blocking it, the plugin configuration is usually the source of truth.

Inspect server-level blocking rules

If browser and curl tests are inconclusive, check the web server configuration.

XML-RPC may be disabled by Apache, Nginx, LiteSpeed, or a host-level firewall.

Apache

In Apache environments, blocking may appear in .htaccess or virtual host rules.

Search for patterns that deny access to xmlrpc.php or return a 403 response.

<Files xmlrpc.php>
Require all denied
</Files>

Nginx

On Nginx, the block often appears in the site configuration file.

location = /xmlrpc.php {
    deny all;
}

CDN and firewall rules

Cloud-based protections can block XML-RPC by path, user agent, or rate-based rules.

Review firewall logs for requests to /xmlrpc.php and confirm whether they were challenged, blocked, or bypassed.

Check WordPress itself with a function or plugin

Developers can confirm XML-RPC availability from inside WordPress by checking whether the endpoint is being filtered.

The built-in xmlrpc_enabled filter can disable access without removing the file.

Search your codebase for snippets like:

add_filter('xmlrpc_enabled', '__return_false');

If you see this line in a theme, plugin, or mu-plugin, XML-RPC is intentionally disabled at the application layer.

That is different from server-level blocking, where the file may still exist but requests never reach WordPress.

You can also inspect active plugins for security modules that mention:

XML-RPC hardening
login protection
pingback disabling
attack surface reduction

How to tell disabled from partially blocked

Not every denial means XML-RPC is fully disabled.

A site can block certain methods while still allowing limited access.

Fully disabled: all requests to /xmlrpc.php return 403, 404, or similar denial codes.

Partially blocked: the endpoint loads, but specific methods such as pingback.ping are rejected.
Limited access: the endpoint is reachable for trusted integrations but protected against abuse.

The best way to distinguish these cases is to check both the status code and the response body, then review server and plugin rules together.

Common reasons XML-RPC appears disabled

Several layers can produce the same outcome, so it helps to identify the actual cause.

Security plugin: the most common reason on WordPress sites.
Hosting provider protection: managed WordPress hosts often block XML-RPC by default.
Manual configuration: a developer added a deny rule in Apache or Nginx.

Cloud firewall: Cloudflare or another WAF blocks the endpoint before WordPress loads.
Custom code: a plugin or mu-plugin disables XML-RPC via the xmlrpc_enabled filter.

Knowing which layer blocked the request matters because the fix or exception process is different in each case.

What to verify before re-enabling it

If you discover XML-RPC is disabled and need to turn it back on, confirm why it was blocked in the first place.

Re-enabling it without understanding the original control can expose login endpoints or trigger security alerts.

Review these items first:

Whether Jetpack, a mobile app, or a publishing tool still depends on XML-RPC.

Whether REST API alternatives can replace the old integration.
Whether rate limiting, MFA, or application passwords can cover the same use case.
Whether pingbacks should remain disabled even if XML-RPC is needed for publishing.

For many modern WordPress sites, the REST API and application passwords provide safer and more flexible integration options than XML-RPC.

Best verification workflow for site owners

If you want a dependable answer, use a layered check instead of relying on one result.

Test /xmlrpc.php in a browser.
Run a curl request to see the status code.
Check security plugins and hosting settings.
Inspect Apache, Nginx, or WAF rules.
Search for xmlrpc_enabled in code and mu-plugins.

When these checks agree, you can be confident about whether XML-RPC is disabled, blocked, or still available.

Table of Contents