How to check if XML-RPC is enabled on your site
XML-RPC is a remote control interface that WordPress ships with, at /xmlrpc.php. It is on by default, there is no switch for it in the admin, and it is a long-standing attack target: the system.multicall method lets an attacker pack hundreds of login attempts into a single request, and pingback.ping has been used to bounce traffic at other sites. That is why many hosts and firewalls block the path outright. The check on this page tells you where your own server stands, because it requests /xmlrpc.php from outside and returns the status code and the final URL. Read that code carefully: 405 does not mean blocked, it means the opposite.
Check your site
-
Probe /xmlrpc.php from outside
Put the full path into the checker on this page, https://your-site.com/xmlrpc.php, and run it. That is a plain GET request from an external server, the same view a scanner has of your site. Two things in the answer matter: the HTTP status code and the URL the request finally landed on. Use the exact domain your visitors use, with https and the correct www or non-www form, otherwise you are testing a redirect rather than the endpoint itself.
-
Read the status code, and do not misread 405
405 Method Not Allowed is the normal answer from a live WordPress XML-RPC endpoint: the file exists, it is enabled, and it simply refuses GET because it only accepts POST. Most people read 405 as "blocked", which is backwards. A 200 together with the text "XML-RPC server accepts POST requests only" means the same thing, enabled; older WordPress versions answer that way without sending the 405 code. 403 Forbidden means something is blocking the path: a server rule, a security plugin, or a WAF in front of the site. Many hosts and CDNs block it by default, so a 403 often means there is nothing left for you to do. 404 Not Found means the file is not there, either because the site is not WordPress or because the file was removed or renamed.
-
Check the final URL before you trust the code
If the final URL is not the /xmlrpc.php you asked for, read the code against where the request ended up, not where it started. A redirect to the homepage or to a login page returning 200 is a block done by a plugin or a redirect rule, not an open endpoint. A jump from http to https, or between www and the bare domain, is just the site's canonical redirect: rerun the check on the final host for a clean answer. And treat 404 with mild suspicion, because some firewalls answer 404 on purpose to hide the endpoint. A 404 proves the path does not respond, not always that the file is gone.
-
Decide whether you need XML-RPC at all
It is only worth keeping if something actually uses it. In practice that means Jetpack, parts of which still talk to the site over XML-RPC, incoming pingbacks and trackbacks, and older remote publishing clients: legacy desktop editors, some third-party posting and syndication tools, and old mobile app versions. Current WordPress apps and most integrations use the REST API with application passwords instead. If none of that applies, the endpoint does nothing for you and is worth closing. Note that WordPress has no on/off setting for it: since version 3.5 it is enabled by default and can only be turned off with code, a plugin, or a server rule.
-
Turn it off in a way that actually holds
Three options, from weakest to most reliable. A security plugin: most have a single switch for XML-RPC, easy to undo, but it only runs after WordPress has loaded. A code filter: add_filter('xmlrpc_enabled', '__return_false'); this disables only the methods that require a login, and the file keeps responding, so pingback methods and the 405 answer stay in place. Blocking the path at the server or the edge: in .htaccess on Apache 2.4 or LiteSpeed use <Files "xmlrpc.php"> Require all denied </Files>, in nginx use location = /xmlrpc.php { deny all; }, or add a WAF rule at your CDN matching that URI path. On shared hosting you can add the .htaccess rule through the file manager in your hosting control panel. The server rule is the one that stops the request before PHP even starts, which is the whole point.
-
Test that nothing you rely on broke
After the change, open the admin and publish a test post, then check whatever you decided to keep. Jetpack surfaces a connection error fairly quickly when it can no longer reach the site, mobile and desktop publishing clients fail to log in, and automated posting or syndication tends to stop silently. If something you need breaks, either fall back to the plugin-level switch or allow that specific service in the rule instead of blocking the path for everyone. Do not delete or rename the core file xmlrpc.php: WordPress restores it on the next update, and missing core files break integrity checks.
How to verify the result
Run the check on this page again against https://your-site.com/xmlrpc.php. A 403 means the block holds and the request is refused before it reaches WordPress. A 404 means the path no longer resolves at all. If you still see 405, or 200 with "XML-RPC server accepts POST requests only", the endpoint is still open: either the change was made at plugin level only (the xmlrpc_enabled filter leaves the file answering 405 by design), or your rule went into the wrong file or sits after another rule that already handled the request. One legitimate exception: if your rule blocks POST requests only, an outside GET will still return 405, and the real test is whether an XML-RPC client can still log in.
Tip: A rule at a CDN or an external firewall only covers traffic that passes through it. If your origin IP is known, /xmlrpc.php can still be reached directly, so back an edge rule with a rule on the server itself, or restrict the origin to your CDN's addresses. And check Jetpack before you block anything: parts of it need this endpoint, and the connection can fail days later in a way that is easy to blame on something else.