Every WordPress site ships with a file most owners never use and most attackers know by heart: xmlrpc.php. It sits quietly in your site’s root folder, answering requests from software that wants to talk to WordPress remotely. For a small number of sites, that is genuinely useful. For the rest, it is an open door that bots knock on thousands of times a day — and every one of those knocks costs your server a little time and attention.
Disabling XML-RPC is one of the simplest hardening steps you can take. It will not magically transform a slow site into a fast one, and anyone who promises that is overselling it. But if your server logs show xmlrpc.php getting hammered, turning it off removes a real source of wasted load and closes off a well-known brute-force vector at the same time. This guide explains what XML-RPC does, how to tell whether you actually need it, and three safe ways to switch it off.
What XML-RPC Actually Is
XML-RPC is an old remote-publishing protocol that WordPress has supported since its earliest days. In plain terms, it lets outside software send instructions to your site over HTTP: publish a post, edit a draft, upload a media file, fetch comments. Before WordPress had its modern REST API, this was how desktop blogging clients and mobile apps talked to your site.
A few legitimate tools still use it:
- The official WordPress mobile app used XML-RPC for years (it has largely moved to the REST API, but some setups still fall back to it).
- Jetpack relies on XML-RPC for its connection to WordPress.com, including features like downtime monitoring, brute-force protection, and stats.
- Older desktop editors and some automation tools (certain IFTTT and Zapier-style workflows, legacy publishing tools) still post through xmlrpc.php.
- Pingbacks and trackbacks — the notifications one blog sends another when it links to it — also travel through this file.
If none of that sounds like your setup, XML-RPC is probably doing nothing for you except answering bots.
How XML-RPC Slows Your Site Down
The performance problem is not the file itself; it is the traffic it attracts.
First, brute-force amplification. XML-RPC supports a method called system.multicall, which lets a single HTTP request bundle hundreds of login attempts together. An attacker can test hundreds of username and password combinations in one request instead of hundreds of separate ones. Even when every attempt fails, your server still runs the full WordPress bootstrap and password-checking code for each one. On a small shared hosting plan, that is enough to spike CPU usage and slow down real visitors.
Second, sheer volume. Automated scanners probe xmlrpc.php on every WordPress site they can find, whether or not they intend to break in. If you check your access logs, you may see bursts of POST requests to /xmlrpc.php from IP addresses all over the world. Each request is cheap on its own, but thousands of them add up — and they tend to arrive exactly when you least want extra load.
Third, the knock-on effects. When the server is busy answering junk requests, legitimate requests wait longer. That shows up as higher time to first byte and slower page loads, especially on budget hosting where resources are shared. If you have been chasing a high TTFB, it is worth checking whether xmlrpc.php traffic is part of the story — our guide to fixing high WordPress TTFB walks through the full diagnostic order.
None of this means XML-RPC is the main reason your site is slow. On a quiet site with no attack traffic, disabling it changes almost nothing measurable. Treat it as hygiene: one more piece of background noise removed, and one fewer way in for attackers.
First, Check Whether You Actually Need It
Before you disable anything, spend two minutes checking for dependencies. Turning XML-RPC off and then discovering that something you rely on broke is an avoidable annoyance.
- Do you use Jetpack? If Jetpack is active and connected, it needs XML-RPC. Disabling it will break the connection and Jetpack-powered features. Either keep XML-RPC on, or disconnect Jetpack first and replace the features you actually use.
- Do you publish from the WordPress mobile app? Modern versions mostly use the REST API, but if you rely on the app, test after disabling and re-enable if posting stops working.
- Do you use any desktop blogging client, old-school editor, or automation that posts to your site? Check its settings or documentation for “XML-RPC” before you switch it off.
- Do you want pingbacks and trackbacks? These are a minor feature for most sites, and many owners turn them off anyway because of spam. Losing them is rarely a real cost.
If you answered no to all of these, you can safely proceed. If Jetpack is the only yes, you have a genuine trade-off to weigh: Jetpack’s features against the attack surface. Many sites decide Jetpack is not worth it; that is a separate decision, and this guide will not make it for you.
Method 1: Disable XML-RPC With a Plugin
This is the easiest method and the one most site owners should use. It requires no code and is trivially reversible.
- In your WordPress dashboard, go to Plugins → Add New.
- Search for “Disable XML-RPC” (the long-standing free plugin by Philip Erb, or any well-maintained equivalent with recent updates and good reviews).
- Install and activate it.
- That is the whole setup. The plugin filters XML-RPC off for all requests, and there are no settings to configure.
The advantage here is safety: deactivating the plugin restores XML-RPC instantly, which makes troubleshooting painless. The small downside is one more plugin on your site — though a plugin this tiny has no measurable performance cost, and if you are worried about plugin bloat in general, our plugin performance audit guide shows how to measure what each plugin really costs.
Some security plugins, such as Wordfence and Sucuri, also include an XML-RPC disable option in their hardening settings. If you already run one of those, use its built-in toggle rather than adding another plugin.
Method 2: Disable XML-RPC With a Code Snippet
If you prefer not to add a plugin, a single line of code does the same job. Add it to your child theme’s functions.php file, or better, through a code snippets plugin (which survives theme changes):
add_filter( 'xmlrpc_enabled', '__return_false' );That filter tells WordPress to refuse all XML-RPC requests. For a more thorough cleanup, you can also remove the RSD link WordPress adds to your site’s header (it advertises the XML-RPC endpoint to anything that looks) and disable pingbacks:
remove_action( 'wp_head', 'rsd_link' );
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['pingback.ping'] );
return $methods;
} );A few warnings apply to all code-snippet advice. Never edit your active theme’s functions.php directly unless you are using a child theme — a theme update will wipe your change. Never paste code from a random website without understanding what it does. And always keep a backup before editing theme files, so a typo does not take your site down. If that sounds like more risk than you want, Method 1 is the better choice; the end result is identical.
Method 3: Block xmlrpc.php at the Server Level
Methods 1 and 2 stop WordPress from answering XML-RPC requests, but the request still reaches WordPress and runs the PHP bootstrap before being refused. Blocking at the server level is stricter: the web server rejects the request before WordPress ever wakes up, which saves the most server resources.
For Apache (including most shared hosting, via .htaccess in your site root):
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>For Nginx, add this inside your server block:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}After saving, test immediately. If your host uses a control panel that overwrites .htaccess or Nginx configuration, your rule may disappear on the next panel update — check after any hosting change. And if you use a security plugin or firewall that manages these files, let it manage the rule rather than editing by hand, to avoid conflicts.
Server-level blocking is the strongest option, but it is also the least forgiving: it blocks Jetpack and every other legitimate XML-RPC use with no per-feature exceptions. Use it when you are sure nothing you need depends on XML-RPC.
How to Verify XML-RPC Is Actually Off
Do not assume the change worked — verify it in under a minute.
The simplest check: visit yoursite.com/xmlrpc.php in a browser. Before disabling, that page shows the message “XML-RPC server accepts POST requests only.” After a successful plugin or code disable, you should see a blank page, an error, or a forbidden response, depending on the method. With server-level blocking, expect a 403 Forbidden.
A more precise check uses the command line, if you have terminal access:
curl -d "<methodCall><methodName>system.listMethods</methodName></methodCall>" https://yoursite.com/xmlrpc.phpA disabled endpoint returns nothing useful or a 403. An enabled one returns a long list of available methods.
Finally, confirm nothing you care about broke. Publish a test draft, check your contact form, and if you use Jetpack, confirm its connection status. If something stopped working, re-enable XML-RPC (deactivate the plugin, remove the snippet, or comment out the server rule) and investigate that specific dependency rather than leaving the site half-broken.
If Something Breaks, Re-enable and Reassess
Reversing any of these methods takes seconds, which is the point of choosing a reversible one. If a tool you forgot about turns out to need XML-RPC, you have two honest options: keep XML-RPC on and mitigate the risk instead (rate-limit xmlrpc.php at your firewall or CDN, enforce strong passwords and two-factor authentication, and block abusive IPs), or replace the tool with one that uses the REST API. What you should not do is leave XML-RPC half-disabled — for example, a plugin that blocks some methods but not others — without understanding exactly what is still exposed.
Do Not Confuse XML-RPC With the REST API
One common mistake deserves a clear warning: XML-RPC and the WordPress REST API are different things. The REST API is the modern interface that the block editor, the mobile app, and many plugins use every day. Disabling it will break core functionality, including editing posts in the block editor. This guide only covers XML-RPC. If a tutorial tells you to disable “xmlrpc and REST” in one breath, treat that advice with suspicion and check what each change actually affects.
The Bottom Line
Disabling XML-RPC is a small, reversible change with a clear payoff for most sites: fewer junk requests, less wasted server work, and one less brute-force channel for attackers. The right method depends on your comfort level — a plugin for most owners, a code snippet if you manage your own snippets, server-level blocking if you want the maximum resource saving and are certain nothing depends on it. Whichever method you choose, verify the result and confirm your site still works as expected. It is a five-minute job that quietly removes a whole category of background noise — and on a site that is being actively probed, that quiet is noticeable.
Related reading on this site: if high TTFB is your main symptom, start with our guide to fixing high WordPress TTFB (https://wpspeedaudits.site/wordpress-ttfb-too-high-fix/); if mystery requests are hammering your backend, our admin-ajax.php guide (https://wpspeedaudits.site/admin-ajax-php-slow-wordpress-fix/) covers a similar hunt; background tasks in general are covered in our WP-Cron guide (https://wpspeedaudits.site/disable-wp-cron-real-cron-job/); and if you are still unsure what is actually slowing the site down, our 15-minute diagnostic routine (https://wpspeedaudits.site/why-is-wordpress-site-so-slow/) is the place to start.
