How to Disable XML-RPC in WordPress Without a Plugin

Every WordPress installation ships with a small file called xmlrpc.php sitting in the site root. Most site owners never open it, never use it, and never even hear about it – until their security logs fill up with thousands of blocked requests hammering it. That file is a remote-publishing API from WordPress’s early days, and today it is one of the most abused entry points on the internet. The good news is that you can disable XML-RPC in WordPress without a plugin in under ten minutes, using either a tiny code snippet or a simple server rule. This guide shows you both methods, how to test that the fix worked, and the one situation where you should leave XML-RPC alone.

What Is XML-RPC and Why Do Attackers Target It?

XML-RPC is a protocol that lets outside software talk to your WordPress site. Long before the modern REST API existed, it was how desktop blogging apps and early mobile apps published posts, edited pages, and managed comments without opening the dashboard. It is enabled by default on every WordPress site, and the official XML-RPC API handbook on developer.wordpress.org still documents all of its methods.

Attackers love xmlrpc.php for two reasons. First, brute-force amplification: the system.multicall method lets an attacker test hundreds of username and password combinations inside a single HTTP request, which slips past simple per-request rate limiting on wp-login.php. Second, pingback abuse: the pingback feature can be tricked into making your server flood another site with requests, turning your blog into an unwilling participant in a DDoS attack. Wordfence has reported that most automated attacks attempt to log in through XML-RPC rather than the visible login page, which is why this single file deserves your attention.

If you publish only from the WordPress dashboard and do not use remote publishing tools, XML-RPC gives you zero benefit and real risk. That makes disabling it one of the highest-value security tweaks you can make.

First, Check Whether XML-RPC Is Active on Your Site

Open https://yoursite.com/xmlrpc.php in your browser (replace yoursite.com with your own domain). If you see the message “XML-RPC server accepts POST requests only.”, the API is live and accepting requests. Almost every stock WordPress install will show this message. After you apply one of the methods below, come back to this page – what you see there tells you the fix worked.

Method 1: Disable XML-RPC with a Code Snippet (Fastest)

The cleanest no-plugin approach is a one-line filter. It tells WordPress to refuse all XML-RPC requests while leaving the file in place, which keeps the change simple and reversible. This uses the same Code Snippets technique as our guide on limiting login attempts in WordPress without a plugin.

1. In your dashboard, go to Plugins and click Add New, then install and activate the free Code Snippets plugin. If you prefer editing files, add the code to your child theme’s functions.php instead – never the parent theme, or a theme update will erase it.
2. Go to Snippets and click Add New. Give the snippet a name like “Disable XML-RPC”.
3. Paste this code into the snippet editor:

add_filter( 'xmlrpc_enabled', '__return_false' );

1. Save and activate the snippet. XML-RPC requests are now refused by WordPress.

While you are here, you can also strip out the related leftovers. Pingbacks ride on top of XML-RPC, so disabling them closes the DDoS-abuse angle completely:

add_filter( 'xmlrpc_methods', 'vtg_remove_xmlrpc_methods' );
function vtg_remove_xmlrpc_methods( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
}

Finally, remove the RSD discovery link that WordPress prints in your site header, which advertises the XML-RPC endpoint to anyone viewing your page source:

remove_action( 'wp_head', 'rsd_link' );

Method 2: Block xmlrpc.php in .htaccess (Strongest)

If your site runs on Apache (most shared hosting does), you can stop requests before WordPress even loads by blocking the file at the server level. This is slightly stronger than the snippet because the request never reaches PHP.

1. Open your hosting file manager. In cPanel, go to Files and click File Manager, then navigate to your WordPress root folder. Turn on “Show Hidden Files” if you cannot see .htaccess.
2. Right-click .htaccess and choose Download first. This backup lets you restore instantly if anything goes wrong.
3. Open .htaccess for editing and add these lines at the very top:

<Files "xmlrpc.php">
    Require all denied
</Files>

1. Save the file. From now on, every request to xmlrpc.php gets a 403 Forbidden response.

On older Apache setups (version 2.2), use this syntax instead:

<Files xmlrpc.php>
    Order deny,allow
    Deny from all
</Files>

On Nginx there is no .htaccess. Add this inside your server block and reload Nginx:

location = /xmlrpc.php {
    deny all;
    access_log off;
}

Method 3: How to Test That XML-RPC Is Really Disabled

Do not assume the fix worked – verify it. Reload https://yoursite.com/xmlrpc.php in a private browser window. With the code snippet method, you should now see “XML-RPC services are disabled on this site.” With the .htaccess method, you should see a 403 Forbidden error page. Either result means attackers are locked out.

For a more technical check, run this from a terminal or your host’s SSH access:

curl -I https://yoursite.com/xmlrpc.php

Look for HTTP/2 403 in the response headers. If you still see HTTP/2 200, your rule is not active – double-check the file you edited and clear any server-side cache.

When You Should NOT Disable XML-RPC

Disabling XML-RPC is safe for the vast majority of sites, but a few tools genuinely need it. Jetpack is the big one: it uses XML-RPC to communicate with WordPress.com, so a full block will break Jetpack features like site stats, related posts, and downtime monitoring. Some older mobile apps and third-party publishing or automation tools also rely on it.

If you need Jetpack, do not apply the full block. Instead, allowlist only the IP addresses your service uses and block everyone else, or leave XML-RPC enabled and rely on Jetpack’s own brute-force protection. When in doubt, test first: disable XML-RPC, then check that your connected tools still work before calling it done. If something breaks, remove the rule and the feature returns immediately – both methods are fully reversible.

More No-Plugin Hardening to Do Next

Disabling XML-RPC closes one door; a few more minutes of work locks the rest. Pair this fix with our guide on limiting login attempts in WordPress without a plugin, which protects wp-login.php itself from password guessing. If you are already comfortable editing .htaccess, you can also enable gzip compression without a plugin to speed up page loads while you are there. And if you like this code-snippet approach, our tutorial on adding a WhatsApp chat button without a plugin follows the same lightweight philosophy.

Frequently Asked Questions

Will disabling XML-RPC break my WordPress site?

No. Your dashboard, themes, plugins, and the REST API all keep working normally. The only things that stop are remote-publishing features: XML-RPC clients, pingbacks, and tools like Jetpack that depend on the endpoint.

Does disabling XML-RPC stop all brute-force attacks?

No. Attackers can still target wp-login.php directly, so pair this with login protection such as limiting login attempts and using strong passwords or two-factor authentication.

I use Jetpack. Can I still disable XML-RPC?

A full block will break Jetpack’s connection to WordPress.com. Either leave XML-RPC enabled and rely on Jetpack’s built-in brute-force protection, or use a selective allowlist that blocks everyone except the services you trust.

Which method is better: the code snippet or .htaccess?

Both work. The .htaccess rule is stronger because it blocks requests at the server level before WordPress loads. The code snippet is easier to manage from the dashboard and simpler to reverse. Use .htaccess if you are comfortable editing server files; otherwise use the snippet.

XML-RPC is a leftover from an earlier era of WordPress that most sites no longer need. Ten minutes of work removes one of the most abused attack surfaces on your site, with zero plugins and zero ongoing maintenance. For your next hardening step, lock down the login page itself with our guide on limiting login attempts without a plugin.

Last updated: October 2026.