XML-RPC is a remote communication protocol built into WordPress, used by things like the WordPress mobile app, the Jetpack plugin, and some third-party publishing tools to interact with a site without going through the normal web login form. It’s also a common target for brute-force and amplification attacks, since a single request to it can sometimes attempt multiple login combinations at once through the system.multicall method. If nothing on your site actually uses it, disabling it removes a real, commonly-targeted attack surface for no functional cost.
Check whether you actually use it first
Before disabling anything, confirm you’re not relying on XML-RPC for something that would break. You’re likely using it if you publish through the WordPress mobile app, use Jetpack (many of its features depend on XML-RPC specifically), or use a third-party blogging client that connects remotely rather than through the standard dashboard. If none of that applies, you’re almost certainly safe to disable it.
Method 1: a security plugin (the simplest option)
Most WordPress security plugins, including SecondGate’s free tier, include an XML-RPC toggle in their settings, a single checkbox that handles this correctly without touching any code directly. This is the recommended approach for most site owners, since it’s reversible with the same single click if something unexpectedly breaks.
Method 2: add a filter to your theme’s functions.php
If you’d rather not rely on a plugin for this specific setting, add the following to your active theme’s functions.php file, using WordPress’s own official xmlrpc_enabled filter hook, documented in the WordPress Developer Reference:
add_filter('xmlrpc_enabled', '__return_false');This is the officially supported way to disable XML-RPC without touching WordPress core, using a standard WordPress filter hook rather than deleting or renaming any core file. It’s clean, reversible (just remove the line to re-enable it), and survives a normal WordPress core update without issue.
Method 3: block it at the server level with .htaccess
For an Apache server, adding the following to your site’s .htaccess file blocks requests to xmlrpc.php before WordPress even processes them, which is a slightly stronger form of blocking than the PHP filter above, since the request never reaches WordPress’s own code at all. The <Files> directive used here is a standard Apache configuration directive, not WordPress-specific:
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>This method requires direct access to edit .htaccess, either through your hosting file manager or FTP/SFTP, and it’s specific to Apache-based hosting, an Nginx server would need an equivalent block added to its own server configuration instead, syntax for which varies by host.
Verify it worked
After disabling XML-RPC through whichever method you chose, visit yoursite.com/xmlrpc.php directly in a browser. Before disabling it, this typically returns an XML response saying “XML-RPC server accepts POST requests only.” After disabling it correctly, you should see either a 403 Forbidden error (if blocked at the server level) or a message indicating XML-RPC services are disabled on this site (if disabled via the filter). If you still see the original XML-RPC response, the change didn’t take effect, worth double-checking you edited the right file or that a caching plugin isn’t serving a stale cached version of the response.
What actually breaks if you get this wrong
If you disable XML-RPC while still relying on it, the most common symptom is the WordPress mobile app failing to connect or sync, or Jetpack features stopping working without an obvious error message pointing at the actual cause, Jetpack’s own documentation specifically confirms XML-RPC as a requirement for a range of its features, worth checking directly if you’re running Jetpack before disabling this. If you notice either of those after making this change, that’s the sign to re-enable it, or to switch specifically to a partial approach that still allows Jetpack’s own requests through while blocking general public access, a more advanced configuration most standard security plugins don’t offer directly.
Where this fits into a broader security setup
Disabling XML-RPC is one specific, narrow fix, and it’s worth treating it as part of a fuller approach rather than a complete solution on its own. For the complete picture, how to secure a WordPress site covers this alongside the rest of the checklist that actually closes off the majority of real-world WordPress compromise routes, updates, 2FA, backups, and the rest of what matters more broadly than this one setting alone.
