Why it matters
XML-RPC let desktop editors and the early mobile apps publish before the REST API existed. It still answers at /xmlrpc.php on every install unless something stops it.
Check your site
Run the free check, or ask the URL yourself:
curl -s https://example.com/xmlrpc.php
If the answer is XML-RPC server accepts POST requests only., it is open. A 403, 404 or 410 means something already blocks it.
Fix it
nginx
Inside the server block of the site:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Then reload nginx. An exact-match location = wins over the regular PHP block, so it does not matter where it sits.
Apache
In the .htaccess file in the WordPress folder, above the WordPress rules:
<Files xmlrpc.php>
Require all denied
</Files>WordPress
In a small plugin of your own, or the theme's functions.php:
add_filter( 'xmlrpc_enabled', '__return_false' );Catch: this switches off the methods that need a login, including system.multicall guessing, but every request still reaches PHP and costs a WordPress boot. The check above will still print the same sentence, because the endpoint still answers; test with a login attempt over POST, or block the URL in the web server where you can.
Does anything still need it?
Jetpack talks to WordPress.com over XML-RPC; if you use Jetpack, allow its addresses or leave XML-RPC on. A few old desktop editors and remote-publishing tools also need it. The WordPress mobile apps use the REST API with application passwords and do not.
Questions
Does disabling XML-RPC break the WordPress REST API or the block editor?
No. The REST API and the block editor do not use XML-RPC.
Is the xmlrpc_enabled filter enough?
It stops the password-guessing methods, but every request still boots WordPress. Blocking the URL in the web server or at the edge also saves the load.
Will blocking it stop pingbacks?
Yes. Pingbacks arrive through xmlrpc.php, so blocking the URL stops incoming ones as well.
More guides
Last reviewed 2026-10-08