If you’ve ever run a WordPress security scan and seen a warning about XML-RPC, you’re not alone. A lot of small business owners spot it, shrug, and move on. Fair enough. It sounds obscure. Kinda dusty. But XML-RPC is still hanging around on loads of WordPress sites, and attackers still poke at it every single day.
Sometimes it’s harmless. Sometimes it’s a back door bots use to hammer your login page without even touching the normal login form. And sometimes, disabling it is the easiest win you’ll get all month.
Let’s make this simple.
So what is XML-RPC, really?
XML-RPC is an old remote access feature in WordPress. It lets other apps talk to your site and do stuff without logging in through the usual wp-admin screen.
Back in the day, this mattered more. People used desktop blogging tools, mobile apps were clunkier, and remote publishing needed a standard way to connect. XML-RPC handled that. It uses a file called xmlrpc.php, usually sitting in the root of your WordPress install.
That file can accept requests like:
- publish a post remotely
- check comments
- authenticate a user
- talk to services like Jetpack on some setups
None of that sounds scary on its own. The problem is how it gets abused.
Why bots love XML-RPC
Because it’s efficient. Annoyingly efficient.
Most people think brute force attacks hit /wp-login.php over and over. That’s true. But XML-RPC gives bots another route, and in some cases a nastier one. Attackers can use the system.multicall function to bundle loads of login attempts into a single request. So instead of 500 obvious login tries showing up one by one, they can cram a pile of guesses into fewer hits.
Less noise. Faster guessing. More pain for you.
I’ve seen site owners look at their logs and say, “But I barely had any login requests.” Then you check xmlrpc.php and there it is – a little traffic funnel full of garbage username and password attempts.
This is also why a green checkmark from a plugin doesn’t always mean you’re fine. That false sense of safety is exactly the trap described in The “install Wordfence and forget it” trap. Security tools help, sure. Forgetting to configure them properly? Big mistake.
And XML-RPC isn’t only used for password guessing. Bots also test it to:
- discover whether your site is WordPress
- probe for weak usernames
- amplify denial-of-service style traffic in older attack patterns
- look for sites with poor hardening and neglected setups
Small business sites get swept up in this stuff constantly. Not because someone hates your plumbing company or hair salon. You’re just there, online, answering the door.
How to tell if XML-RPC is being hit
You don’t need to become a server nerd. You’re just looking for clues.
Common signs include repeated requests to /xmlrpc.php in your logs, alerts from a security plugin, or sudden spikes in bot traffic with no obvious reason. Sometimes your host flags it. Sometimes they don’t. Honestly, hosts often notify you late, after the ugly part has already started. That’s why this article on why your hosting’s “malware detected” email often arrives too late rings true for so many owners.
If you use a security plugin with logging, check whether requests to xmlrpc.php are frequent. If your site has no reason to use XML-RPC and that file is still getting hammered, that’s not normal background noise. That’s bots rattling the handle.
Can you disable it safely?
Usually, yes.
For most small business sites, XML-RPC serves no useful purpose anymore. If you update the site through the normal WordPress dashboard, don’t use remote publishing tools, and aren’t relying on a service that needs it, you can probably switch it off without anyone noticing. Except the bots. They’ll notice. And sulk.
Here are the cases where disabling XML-RPC is generally safe:
- You only log in through wp-admin
- You don’t use the WordPress mobile app to manage the site
- You don’t use Jetpack features that depend on XML-RPC
- Your developer hasn’t built some odd custom integration around it
That’s the key bit right there. If your site has custom glue holding things together, check first. Some old systems do weird things. A booking setup from 2018, a battered app connection, a legacy content tool – those are the kinds of surprises that come back to bite.
But for the average brochure site, local service business, consultant, clinic, or small webshop? Disabling XML-RPC is often a clean and sensible move.
When you should leave it on
Not every site should kill it immediately.
If you actively use the WordPress mobile app, Jetpack, or a third-party tool that still connects through XML-RPC, disabling it can break features quietly. That’s the annoying part. Your site might still load fine, but publishing fails, syncing stops, or some background process just… dies.
So test, don’t guess.
If you’re not sure what your site depends on, ask whoever built it. Or better yet, get a proper maintenance person to check the setup before making changes. That’s exactly the kind of thing a solid WordPress maintenance service should help with, because random hardening changes without context can create their own mess.
The easiest ways to disable or restrict XML-RPC
You don’t need to edit five config files by candlelight. There are simpler options.
Option 1 – Use a security plugin or hardening feature.
This is the easiest route for most people. Some tools let you disable XML-RPC completely or limit risky methods without touching code. If you want a quick hardening option, a tool like one-click hardening is the practical choice. Flip the setting, test the site, done.
Option 2 – Block access at the server level.
Your host or developer can block requests to xmlrpc.php in Apache or Nginx. That’s tidy and effective. It also keeps junk traffic from hitting WordPress in the first place, which I prefer.
Option 3 – Disable only the dangerous parts.
If you still need XML-RPC for something specific, you may be able to block system.multicall or add stricter controls instead of turning the whole thing off. Bit more fiddly. Usually developer territory.
And whatever you do, test after the change. Log in. Submit your contact form. Publish a draft. Check any connected tools. Take five minutes now or spend two hours later wondering why something stopped working. Your choice.
Don’t treat this like a magic fix
Disabling XML-RPC helps, but it’s not some superhero move that suddenly makes a weak site safe.
If your admin password is flimsy, your plugins are outdated, your PHP version is ancient, and you’ve got three forgotten admin accounts floating around, turning off XML-RPC won’t save you. It just removes one attack route. A useful one, yes. Still just one.
A better approach looks like this:
- disable XML-RPC if you don’t need it
- use strong passwords and two-factor auth
- keep WordPress, plugins, and themes updated
- remove abandoned plugins and old admin accounts
- review logs and unusual traffic now and then
That’s the boring boring stuff that actually works.
My honest take
If you run a normal small business WordPress site and you’re not sure whether you need XML-RPC, you probably don’t. That’s not a universal law, but it’s true alot of the time. Old feature, modern risk, very little upside for most owners.
So yes, check first. But don’t overthink it for three weeks.
If nothing on your site depends on XML-RPC, disable it safely and move on to the next thing. Your update routine, backups, admin accounts, plugin cleanup – those will matter too. Maybe more.
Still, this is one of those rare hardening tweaks that’s usually low drama and actually worth doing. Short job. Real benefit. I like those.