How to disable XML-RPC in WordPress
/xmlrpc.php is an old remote-publishing endpoint that stays on by default and draws password-guessing traffic. Most sites can switch it off.
Check your own site
Runs this check and the other 192, free, in about 45 seconds.
Or run only this check with the free WordPress health check.
What it is
XML-RPC is the protocol WordPress used for remote publishing before the REST API existed. The endpoint lives at /xmlrpc.php and is on by default, even though most sites no longer use it.
Attackers use it for password guessing and for pingback abuse, so the file often draws more automated traffic than the login page. The Jetpack connection and a few older apps still depend on it.
OK looks like this: /xmlrpc.php answers 403 or 404, or you know exactly what still needs it and logins are rate-limited. getReport requests /xmlrpc.php once with GET and reports whether it answers as an enabled endpoint.
What a passing site looks like
- XML-RPC is switched off or blockedwarning · −1 ptseffort S
XML-RPC is switched on
Why it matters. XML-RPC is an old way to publish remotely that most sites no longer need. It is a favourite target for password guessing and pingback abuse, and it stays on by default.
- Turn it off with your security plugin's XML-RPC option, or block /xmlrpc.php in the server configuration.
- Keep it only if something you use still needs it, such as the Jetpack connection, and then rate-limit logins.
In a report the technical detail reads: /xmlrpc.php answers "XML-RPC server accepts POST requests only".
Questions people ask
How can I tell if XML-RPC is enabled on my site?
Open yoursite.com/xmlrpc.php in a browser. If it says "XML-RPC server accepts POST requests only", the endpoint is on. A 403 or 404 means it is blocked. getReport's WordPress checker runs the same test and shows the result as a yes or no.
Will disabling XML-RPC break anything?
For most sites nothing changes. Jetpack's connection, the old WordPress mobile app workflows and some remote-publishing tools use it, as do pingbacks. If you rely on one of those, keep it on and rate-limit login attempts instead of blocking the file.
Is blocking xmlrpc.php better than a plugin setting?
Blocking the file in the server configuration stops the request before PHP runs, which saves server work under an attack. A plugin setting is easier and survives a host move. Either is fine; the server rule is the stronger one.