How to Disable xmlrpc.php in WordPress

xmlrpc.php is an old WordPress endpoint that lets apps and services publish to your site remotely. Bots hit it because it accepts login attempts and pingbacks, which makes password guessing and pingback abuse cheap. Most sites don't need it and can block it in about ten minutes.

Check if xmlrpc.php is enabled

Open https://your-site.com/xmlrpc.php in your browser. If you see "XML-RPC server accepts POST requests only.", it's enabled. A 403 or 404 means it's blocked. You can also run the free WordPress scan, which checks it with a single page request and never sends it anything.

Do you need it?

Keep it if you use Jetpack, the WordPress mobile app or another remote publishing tool. Jetpack says it relies on xmlrpc.php to talk to WordPress.com, and that blocking the file breaks the connection (Jetpack: Jetpack and XML-RPC). If you need it, keep it on and harden around it: strong unique passwords, two-factor login for every admin, and rate limiting from your host or firewall.

Block it: the complete fix

If nothing on your site needs it, block the file at the web server so WordPress never runs it.

Apache or LiteSpeed (.htaccess)

Add this to the .htaccess file in your WordPress root, outside the # BEGIN WordPress block:

# Block xmlrpc.php (Apache 2.4 / LiteSpeed)
<Files xmlrpc.php>
  Require all denied
</Files>

Nginx

# Block xmlrpc.php (Nginx, inside your server { } block)
location = /xmlrpc.php {
  deny all;
}

Test and reload Nginx after saving (sudo nginx -t && sudo systemctl reload nginx).

Managed hosting

Many managed WordPress hosts and firewalls have an XML-RPC toggle or rule. Use it if you can't edit the server config.

We tested both snippets on a WordPress 7.1 test site on Oct 20, 2026. After the change, /xmlrpc.php returned 403 on Apache and on Nginx, and the rest of the site loaded normally.

Why the xmlrpc_enabled filter alone isn't enough

You'll often see add_filter( 'xmlrpc_enabled', '__return_false' ); recommended. WordPress's own docs say this filter only turns off the XML-RPC methods that need a login. It doesn't control pingbacks or other methods that don't require authentication (developer.wordpress.org: xmlrpc_enabled). In our test with the filter on, the endpoint still answered and still listed pingback.ping. Blocking the file at the server is the complete fix.

Test and rescan

1. Open /xmlrpc.php again while logged out. You should get 403 or 404.
2. If you use Jetpack or the mobile app, confirm they still connect. If they don't, undo the block and harden instead.
3. Rescan your site to confirm the finding is gone.

Standard: CWE-307 (improper restriction of excessive authentication attempts).

Related guides

• WordPress security scan
• Fix WordPress user enumeration

FAQ

How do I check if xmlrpc.php is enabled?

Open your-site.com/xmlrpc.php in a browser. The message "XML-RPC server accepts POST requests only." means it's enabled. A 403 or 404 means it's blocked.

Will disabling xmlrpc.php break my site?

Not the site itself. It breaks tools that publish remotely, such as Jetpack and the WordPress mobile app. If you use them, keep it enabled and protect logins with strong passwords and two-factor login.

Is add_filter('xmlrpc_enabled', '__return_false') enough?

No. WordPress's docs say the filter only disables methods that need a login. Pingbacks still answer. Block the file at the web server for the complete fix.

Can Pro Logica check xmlrpc.php for me?

Yes. The free WordPress scan checks whether xmlrpc.php answers, using one ordinary page request. It never sends the endpoint any method calls.

Ready to see your score? Run the free check on your site. It detects WordPress automatically.