If you are seeing a weird spike in failed login attempts or your server is crawling for no apparent reason, it's probably time to disable xmlrpc and see if that clears things up. Honestly, for most modern WordPress users, this old feature is a bit like a dusty back door that you forgot to lock, and unfortunately, hackers are really good at finding those doors.
Back in the day, XML-RPC was actually a pretty big deal. It was the primary way WordPress communicated with external apps and services. If you wanted to post to your blog from your phone using the mobile app, or if you wanted to use a service like Pingbacks to see who was linking to you, XML-RPC was the engine under the hood making that happen. But things have changed. WordPress now uses the REST API for most of that stuff, which is way more secure and flexible. This leaves the older XML-RPC script sitting there, doing mostly nothing for you while providing a massive target for brute-force attacks.
Why this old file is a security nightmare
The biggest problem with keeping this enabled is how it handles authentication. See, every time you send a request via XML-RPC, you have to send your username and password along with it. There's no "handshake" or session token like we use today. This is a goldmine for anyone trying to guess your credentials.
But it gets worse. Hackers use a specific command called system.multicall. This is the part that really stings. Instead of trying one password, waiting for a "no," and then trying another—which is how a normal login form works—system.multicall lets an attacker try hundreds or even thousands of password combinations in a single request.
If your host has a limit on how many times someone can try to log in, they might think they're blocking an attacker after five failed attempts. But through XML-RPC, those five attempts could actually represent 5,000 password guesses. It's incredibly efficient for the bad guys and incredibly taxing on your server resources. Even if they don't get into your site, the sheer volume of requests can easily knock your site offline in a makeshift DDoS attack.
Using a plugin to get the job done
If you aren't the type of person who likes poking around in your site's "engine room," the easiest way to handle this is with a plugin. There are plenty of options out there, but you don't even necessarily need a dedicated "Disable XML-RPC" plugin.
Most of the heavy-hitter security plugins already have a toggle for this. If you're already using something like Wordfence or Sucuri, go check your settings. There's usually a checkbox tucked away in the hardening or firewall sections that says something like "Disable XML-RPC" or "Disable XML-RPC Authentication." Just check that box, hit save, and you're basically done.
If you don't use a massive security suite and want something lightweight, you can just search for "Disable XML-RPC-API" in the WordPress repository. There are several tiny plugins that do exactly one thing: they turn off the API. You install it, activate it, and forget it. It's a great "set it and forget it" solution for people who just want their site to be safe without learning how to code.
The .htaccess method (The clean way)
If you're comfortable using an FTP client or your hosting provider's File Manager, I'd actually recommend the .htaccess method over a plugin. Why? Because it stops the request before it even reaches WordPress.
When you use a plugin, the server still has to load WordPress and then let the plugin tell the server, "Hey, don't allow this." That still uses up a tiny bit of your server's memory and CPU. If you block it at the .htaccess level, the server just says "Access Denied" and moves on without waking up the rest of your site. It's a much more efficient way to save your resources during an attack.
To do this, you'll find your .htaccess file in the root folder of your WordPress installation. You might need to turn on "Show Hidden Files" to see it. Once you open it up, you can paste in a snippet of code like this:
<Files xmlrpc.php> Order Deny,Allow Deny from all </Files>
That's it. You're basically telling the server that if anyone tries to touch the xmlrpc.php file, they should be shown the door immediately. Just make sure you don't put this code inside the # BEGIN WordPress and # END WordPress blocks, because WordPress might overwrite it later. Put it right at the top or the bottom of the file.
What about the functions.php file?
Some people prefer to keep their changes within their theme. You can also disable xmlrpc by adding a simple filter to your theme's functions.php file. This is a solid middle ground, though keep in mind that if you change your theme, the protection goes away.
You'd just add this line: add_filter( 'xmlrpc_enabled', '__return_false' );
This tells WordPress to return "false" whenever a service asks if XML-RPC is active. It works, and it's better than doing nothing, but again, it's not quite as "hard" of a block as the .htaccess method. It's like putting a "Closed" sign on the door instead of just bricking the door shut.
Will this break my site?
This is the million-dollar question. Most of the time, the answer is no. Most people won't notice a single difference. However, there are a few specific cases where you might run into issues.
The biggest one is Jetpack. Jetpack is a massive plugin that does a hundred different things, and it relies heavily on XML-RPC to talk to the WordPress.com servers. If you disable the feature entirely, Jetpack might start throwing errors or stop syncing your data. If you're a die-hard Jetpack user, you might need to look for a more nuanced solution, like a plugin that only allows specific IP addresses (like those from Jetpack) to access the file while blocking everyone else.
Another potential issue is the WordPress mobile app. While the app has moved toward the REST API, some older versions or specific features might still lean on the old protocol. If you use the app to write your blog posts while you're on the bus, you might want to test things out after you disable it. If the app stops working, you'll know why.
Final thoughts on site hardening
At the end of the day, security is all about reducing your "attack surface." You want to give hackers as few targets as possible. Since XML-RPC is a legacy feature that most of us don't even use anymore, leaving it active is just unnecessary risk.
I've seen sites get hit by thousands of requests per hour, all targeting that one file. It drains the server, makes the site slow for actual visitors, and eventually, the host might even suspend the account because it's using too many resources. Taking five minutes to disable xmlrpc now can save you a massive headache later. Whether you choose the plugin route or the code route, just get it done. Your server—and your peace of mind—will thank you.