Practical guides on websites, online stores, and getting found on Google — written for business owners, not developers.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
XML-RPC still runs on most WordPress sites by default. See what it does, who still needs it, and a clear answer on when to disable it safely.
XML-RPC is a WordPress feature most site owners have never heard of, and most attackers know by heart.
It is a legacy API from before the REST API existed. It still runs by default on every WordPress site in 2026, whether anyone uses it or not.
On one of our client sites, the firewall logs made it obvious why that matters. The same rotating set of countries kept hitting /xmlrpc.php and /wp-login.php, hour after hour.
Most sites should disable it or restrict it. Here is what XML-RPC actually does, who still needs it, and how to turn it off correctly.
XML-RPC is a way for outside applications to talk to WordPress without going through the login screen. It sends and receives data using XML over HTTP, which is where the name comes from.
WordPress added it back in 2005, when people wrote posts in separate desktop programs and needed a way to publish straight to the site. It stayed off by default for years. That changed in 2012, when the WordPress mobile app needed XML-RPC to connect, and WordPress switched it on for everyone.
It has stayed on ever since. The file lives at yourdomain.com/xmlrpc.php, and unless you or your host have turned it off, it is sitting there right now, waiting for requests from anyone who knows where to look.
Jetpack is the big one. Despite what a lot of guides claim, Jetpack has not fully moved to the REST API. Jetpack's own documentation says it keeps XML-RPC running on purpose, so that sites on older versions of the plugin keep working without forcing an update. If you run Jetpack and block XML-RPC completely, the connection breaks. WP Engine even documents this directly. XML-RPC is blocked by default on their newer hosting plans, and Jetpack users have to manually allow it back in.
The official WordPress mobile app is a separate case worth naming too. It prefers the REST API when it can, but it still falls back to XML-RPC on self-hosted sites, particularly ones without Jetpack connected, to sync blog settings and stats. If your team publishes or checks the site from a phone, this is not automatically safe to remove.
A smaller group still needs it too. A few legacy desktop publishing apps, some remote-posting tools, and certain automation plugins still call XML-RPC methods behind the scenes. If none of that applies to you, which is true for most sites, there is nothing here worth keeping open.
XML-RPC gives attackers two things a normal login page does not.
The first is speed. WordPress has a method called system.multicall that lets one XML-RPC request bundle hundreds of login attempts together. A normal brute-force attack against wp-login.php tests one password per request, which is slow enough for basic rate limiting to catch. Through XML-RPC, an attacker can test five hundred passwords in a single request, and from your server's side, it looks like one visit, not five hundred.
The second is borrowed traffic. XML-RPC also powers pingbacks, the feature that notifies a site when someone links to it. Attackers can fake a pingback request and make a WordPress site send traffic to a completely different target, turning your site into an unwilling part of an attack on someone else.
We have seen the first kind up close. On one client's firewall logs, /xmlrpc.php and /wp-login.php were hit by the same rotating set of countries, day after day. That is not a one-off. It is what an open XML-RPC endpoint looks like from the inside, and just one door out of several attackers try first, covered in full in Why WordPress Websites Get Hacked.
Most articles treat disabling XML-RPC as the obvious answer. It is worth knowing that not everyone agrees.
Wordfence, one of the most widely used WordPress security plugins, has argued against disabling XML-RPC outright. Their position is that blocking a feature instead of monitoring it is security through obscurity. A properly configured firewall should catch bad requests no matter which door they come through.
That is a fair argument if you already run a plugin watching every request in real time. Most site owners do not have that kind of monitoring in place. For that reader, our recommendation stands. Disable or restrict XML-RPC rather than leave it open on the assumption something else is watching.
Here is the short version, based on what you actually use.
Not using Jetpack, the mobile app, or a legacy publishing tool? Disable XML-RPC completely. Nothing on your site depends on it, and there is no reason to leave it open.
Using Jetpack? Do not block it outright. Restrict it instead, so Jetpack's connection still works while random requests from everyone else get turned away.
Publish or manage your site from the WordPress mobile app? This is a separate case from Jetpack, and a common one. The app leans on the REST API where it can, but it still falls back to XML-RPC for self-hosted sites, especially ones not connected to Jetpack, to sync settings and stats. If you use the app regularly, restrict XML-RPC rather than fully disabling it, then open the app afterward and confirm it still connects.
Not sure what uses it? Check before you touch anything. The next section shows the one-line test.
Already running a security plugin like Wordfence or MalCare? Look for its built-in XML-RPC control first. You likely do not need a separate plugin on top of it.
Open a browser and go to yourdomain.com/xmlrpc.php.
If you see the message "XML-RPC server accepts POST requests only," XML-RPC is active on your site. That sentence looks like an error, but it means the file is live and listening.
If you see a 403 Forbidden or 404 Not Found instead, it is already blocked, and you do not need to do anything else.
You have four ways to do this, and which one fits depends on your setup.
If your host bundles WordPress tools into its dashboard, check there first. Hostinger, for example, has a Disable XML-RPC toggle sitting under Tools, no plugin required, one click.
If you already run a security plugin like Wordfence or MalCare, look for its own XML-RPC control before adding anything else. Most established security plugins have one, and it usually comes with smarter blocking than a flat on/off switch, including the option to restrict rather than fully disable if you use Jetpack or the mobile app.
Without either of those, a small code snippet does the job. Add this filter through a snippets plugin, not directly in your theme's functions.php, since a mistake there can take the whole site down:
add_filter( 'xmlrpc_enabled', '__return_false' );Developers comfortable editing server files can block the endpoint directly through .htaccess instead, which stops requests before WordPress even loads. That method carries more risk if the syntax is wrong, so back up the file first.
Whichever method you pick, confirm it actually worked before you move on.
Go back to the browser test from earlier and load yourdomain.com/xmlrpc.php again.
You want a 403 Forbidden or a 404 Not Found this time. If you still see "XML-RPC server accepts POST requests only," the fix did not take, and the endpoint is still live.
If you used the code snippet method and it is not working, check that the snippet plugin is active. If you used .htaccess, check that you saved the file in the right folder.
A lot of WordPress advice tells you to go to Settings, then Discussion, and uncheck "Attempt to notify any blogs linked to from the post." That stops your site from sending pingback notifications to other sites. It does not disable XML-RPC.
The xmlrpc.php file stays exactly as open as before. The brute-force risk through system.multicall does not go away, because that checkbox only controls outgoing notifications, not the endpoint itself. If you only did this step and stopped, your site is not protected. Use one of the methods above instead.
XML-RPC is one small setting, but it is exactly the kind of thing that gets missed until a firewall log shows it being hit all day. It was one small piece of what we found while working through a full site recovery on a client's site. If you are not sure what else on your site might be exposed the same way, a proper security audit will find it before an attacker does.
No. It has nothing to do with how Google indexes or ranks your site.
For most sites, no. Check first if you use Jetpack, the WordPress mobile app, or any remote-publishing tool, since those may need it restricted rather than fully blocked.
No. The REST API, added in 2016, handles what XML-RPC used to do for almost every modern use case. XML-RPC ships on by default anyway, mostly for backward compatibility.
Generally yes. It has no equivalent to system.multicall, so it cannot be used to bundle hundreds of login attempts into one request the way XML-RPC can.
No. It is a core WordPress file, and the next WordPress update will simply put it back. Use one of the disable methods above instead of touching the file itself.
Disabling turns the endpoint off completely. Restricting keeps it open only for specific tools, like Jetpack or the mobile app, while blocking everyone else. Restrict if something you use depends on it, disable if nothing does.
No. It closes one specific door. Weak passwords, outdated plugins, and other login points still need their own protection, which is why this is one step in a larger security setup, not the whole thing.
Check your firewall or access logs for repeated requests to /xmlrpc.php from unfamiliar IP addresses or countries, especially in short bursts. A security plugin's activity log usually shows this without you needing to dig through raw server logs. If you're seeing signs of an actual break-in rather than just probing, our guide to investigating a hacked WordPress site walks through building the full timeline before you clean anything.
SEO & Security Expert, AppDeel
Azizul Hakim is an SEO and website security specialist at AppDeel, the agency he founded and where he still handles client work himself. For more than ten years he has helped business owners and eCommerce brands get found in search and keep their websites secure.
Read more posts by Md Azizul Hakim →Japanese characters showing up in your Google results? Here is how to confirm the Japanese keyword hack, clean it properly, and get the spam pages deindexed.
Your WordPress site is redirecting to spam for visitors but looks fine to you. Here is how to prove it, find where the code hides, remove it, and confirm it is gone.
Most landing page advice assumes you bought the traffic. Where the button goes, what it says, and how much to explain first, when nobody clicked an ad.
A complete free method to scan and clean WordPress malware by hand. No security plugin, no paid scanner, no AI. Includes the SSH path and the cPanel-only path.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.