Yes, disable XML-RPC if you are not using Jetpack, the WordPress mobile app, or a legacy remote publishing tool. The safest default is a server-level block when you have hosting access, since it stops requests before they ever reach PHP; a trusted plugin is the better fallback on shared hosting. Whichever route you pick, test the result right after and keep an eye on your logs for a few days.
TL;DR:
- Using a server-level rule is the most resource-efficient method, but it requires access to server files like .htaccess or Nginx config.
- Plugin options are easiest for shared hosting users or those uncomfortable editing code, with plugins like Disable XML-RPC or Simple Disable XML-RPC taking effect immediately after activation.
- Code snippets in a child theme or must-use plugin disable authenticated methods with the
xmlrpc_enabledfilter but may require additional filters to completely block all endpoints and pingbacks.- Disabling XML-RPC will break remote features such as Jetpack, the official mobile app, pingbacks, and certain remote publishing tools.
- Always test changes on staging sites, back up beforehand, and confirm the endpoint is disabled via tools or requests, watching server logs for ongoing activity.
Table of Contents
- Which method should you choose: server, plugin, or code?
- How do you disable XML-RPC with a plugin?
- Can you disable XML-RPC with a code snippet instead?
- How do you block xmlrpc.php at the server level?
- How do you confirm XML-RPC is actually disabled?
- What breaks if you disable XML-RPC?
- What's the checklist for rolling back if something breaks?
- What hosting-side help actually makes this safer?
- A pragmatic rule of thumb for XML-RPC
- How InSave Hosting supports safe XML-RPC changes
- FAQ
- Sources
Which method should you choose: server, plugin, or code?
Three options handle this job, and each fits a different situation. A server-level rule, placed in your .htaccess file or Nginx config, rejects requests to xmlrpc.php before WordPress loads, which makes it the fastest and most reversible choice when you can edit server files. A plugin is the practical pick when you do not have file access or feel more comfortable with a toggle in the dashboard. Application code added to a child theme or a must-use plugin sits in between: it needs no extra plugin but does require comfort editing PHP.
- Server-level block: fastest, cleanest, requires hosting or server access.
- Plugin: no code needed, works on shared hosting, easy to reverse.
- Code snippet: lightweight, developer-friendly, needs careful testing.
Before you touch any of these, confirm you are not relying on Jetpack, the official WordPress mobile app, or an older remote-publishing workflow, since all three use XML-RPC to talk to your site.
How do you disable XML-RPC with a plugin?
Plugins remain the quickest path for site owners who would rather not edit code. Two widely used options, Disable XML-RPC and Simple Disable XML-RPC, work by hooking into the same WordPress filters you would otherwise add manually, and neither requires server access or a code edit.
- Go to Plugins → Add New in your WordPress dashboard.
- Search for "Disable XML-RPC" or "Simple Disable XML-RPC."
- Check the plugin's update history and user reviews before installing; both plugins are actively maintained.
- Click Install Now, then Activate.
- Most of these plugins work immediately on activation with no settings screen; a few add a simple on/off toggle under Settings.
- Test your site by sending a request to
/xmlrpc.phpand confirming you get a response indicating the service is disabled, a verification method commonly used by plugin documentation and community testing.
Keep in mind that some of these plugins only block the authenticated XML-RPC methods rather than the entire endpoint, so a handful of unauthenticated calls, such as pingbacks, may still get through depending on which plugin and settings you use. If you ever need to restore functionality, for example if Jetpack suddenly stops syncing, deactivating the plugin re-enables XML-RPC instantly with no cleanup required.
Pro Tip: Deactivate any security plugin's built-in XML-RPC blocker before installing a dedicated one, since two plugins fighting over the same filter can produce confusing, inconsistent results.
Can you disable XML-RPC with a code snippet instead?
If you would rather skip another plugin, a short snippet in your child theme's functions.php file or in a must-use plugin gets the job done. Two filters cover most needs, and they behave differently enough that the choice matters.
add_filter('xmlrpc_enabled', '__return_false');disables XML-RPC methods that require authentication, which is where most brute-force and amplification abuse happens, according to the WordPress developer reference.- That same filter does not necessarily block unauthenticated endpoints like pingbacks, so if you need a complete shutdown, use
add_filter('xmlrpc_methods', '__return_empty_array');instead, which clears the entire method list. - Add a short snippet to remove the
X-Pingbackheader too, since leaving it in place after disabling XML-RPC can confuse pingback-aware themes and services:remove_action('wp_head', 'rsd_link');. - Place any of this code in a child theme, not your parent theme, or better yet in a dedicated must-use plugin file so a theme update never wipes it out.
Back up your site and test on a staging copy first. A misplaced filter rarely breaks a site outright, but a typo in functions.php can produce a blank page fast, and you want to catch that somewhere other than your live domain.
How do you block xmlrpc.php at the server level?
Blocking the request before it reaches PHP is the most efficient option when you can edit server configuration, since a blocked request never touches the database or your PHP workers, as Perishable Press explains in its rundown of server-level blocking methods.
| Server | Rule type | Example |
|---|---|---|
| Apache | Files/RequireAll deny | <Files xmlrpc.php> Require all denied </Files> |
| Apache (mod_alias) | RedirectMatch 403 | RedirectMatch 403 ^/xmlrpc\.php$ |
| Nginx | location deny | location = /xmlrpc.php { deny all; } |
Drop the Apache rule into your site's .htaccess file, or the Nginx block into your server block, and reload. If you need to allow a specific service, such as a known Jetpack IP range, add an allow line above the deny rule rather than removing the block entirely.
If you are on shared hosting without file-level server config access, ask your host's support team whether they can apply this rule for you; most managed hosts can. Deploy this kind of change on a staging copy first, since a typo in a location block can take down more than just XML-RPC on an Nginx server.
How do you confirm XML-RPC is actually disabled?
A few quick checks tell you whether the change worked.
- Send a test POST request with
curl -d "" https://yoursite.com/xmlrpc.phpand look for either a message saying XML-RPC services are disabled, if you used a plugin or thexmlrpc_enabledfilter, or a 403 response if you blocked it at the server level. - Open the official WordPress mobile app and try logging in; it should fail to connect once XML-RPC is off.
- Run your site through an XML-RPC validator such as xmlrpc.blog to confirm the endpoint no longer responds to standard method calls.
- Watch your server access logs for a few days after the change.
A drop in repeated POST requests to /xmlrpc.php in your logs, alongside a falling rate of 401 and 403 responses, is a reliable sign the block is working, while continued heavy traffic there suggests attackers have simply moved to another endpoint, a pattern WPScan's security analysis has observed around this kind of hardening.
What breaks if you disable XML-RPC?
Before flipping the switch, check what actually depends on this endpoint. The official WordPress mobile app, Jetpack's remote features, pingbacks and trackbacks, and a handful of legacy remote-publishing tools all rely on XML-RPC to function, and plugin documentation flags these dependencies explicitly.
- The
xmlrpc_enabledfilter blocks authenticated calls, which covers most mobile app and remote-publishing use, but may leave pingbacks reachable. - The
xmlrpc_methodsfilter wipes out every method, authenticated or not, including pingbacks, but also disables Jetpack features that rely on XML-RPC. - A full server-level block stops everything equally, regardless of which WordPress filter would have applied.
Before you disable anything, check your active plugin list for Jetpack or any remote publishing add-on, and ask anyone on your team who posts from a phone whether they use the official app. A five-minute audit here saves a confused phone call later.
What's the checklist for rolling back if something breaks?
Keep this short list handy before and after you make the change.
- Take a full backup and clone your site to staging before applying any method.
- To revert a plugin, deactivate it; to revert code, delete the snippet from functions.php or your mu-plugin file; to revert a server rule, remove the deny block and reload the server.
- If Jetpack stops syncing, reconnect it from the Jetpack dashboard once you've confirmed the relevant endpoint is reachable again.
- If the mobile app throws a connection error, that's expected once XML-RPC is off. No fix is needed unless you want the app working.
- Check your error logs first whenever something unrelated seems to break. A blank page after a code change is almost always a PHP syntax issue, not a WordPress core problem.
Pro Tip: If you're not confident reading a PHP error log, contact your host's support team before trying another fix. A five-minute conversation beats an hour of guessing.
What hosting-side help actually makes this safer?
Rolling out a server-level block is far less stressful with a staging copy and a recent backup already in place. Testing a .htaccess or Nginx rule on a clone of your site, rather than the live one, takes minutes instead of a support ticket.
A server-level block also uses fewer resources than a plugin, since a request rejected by the web server never reaches PHP or your database, which matters most on busy sites fielding repeated bot traffic. If you're not sure your current plan allows direct server config edits, that's worth checking before you commit to this method over a plugin.
A pragmatic rule of thumb for XML-RPC
Our rule is simple: disable XML-RPC if nothing on your site actively uses it, and reach for a server-level block before a plugin whenever you have the access to make one. Test changes during low-traffic hours and watch your logs for a day or two afterward rather than assuming success. XML-RPC hardening is one layer. Pair it with two-factor authentication and login-attempt limits for a setup that doesn't depend on any single fix.
— Ihor
How InSave Hosting supports safe XML-RPC changes
We built our WordPress hosting around the kind of change you're making here: staging environments, free migrations, and managed security baked into every plan, so testing a server rule or plugin toggle never has to happen on a live site. If server-level access matters to you, our WordPress hosting plans are built with that flexibility in mind, and our support team can help apply the Apache or Nginx rule directly if you'd rather not touch config files yourself.
- Staging copies for testing plugin, code, or server changes before they go live.
- Free migration if you're moving from a host that won't let you edit server rules.
- Support access for help with .htaccess or Nginx XML-RPC blocks.
Check our WordPress hosting plans if you want a setup where this kind of change is routine rather than risky.
FAQ
What is XML-RPC in WordPress and why does it matter?
XML-RPC is a WordPress feature at /xmlrpc.php that lets external applications, like the mobile app or Jetpack, interact with your site remotely. It has been enabled by default since WordPress 3.5.0, according to the WordPress developer reference, and it can be abused for brute-force login attempts and DDoS-style amplification if left open and unused.
How do I disable XML-RPC in wp-config or with code?
The standard approach isn't wp-config itself but a filter added to your child theme's functions.php or a must-use plugin: add_filter('xmlrpc_enabled', '__return_false'); disables authenticated methods, while add_filter('xmlrpc_methods', '__return_empty_array'); removes all methods entirely. The second option gives a more complete block, including pingbacks.
Will disabling XML-RPC break Jetpack or my mobile app?
Yes, both rely on XML-RPC to communicate with your site, so disabling it, by any method, will stop Jetpack's remote features and block the official WordPress mobile app from connecting. Check whether you actually use either before disabling, since re-enabling later is simple but requires reversing whichever method you chose.
What's the best way to block xmlrpc attacks without a plugin?
A server-level rule in your .htaccess file (Apache) or Nginx config is the most efficient block, since it rejects the request before PHP or your database get involved. If you don't have server access, ask your host's support team to add the rule, or use a trusted plugin as a temporary measure.
Are there XML-RPC alternatives for remote publishing?
Modern WordPress sites typically use the REST API for remote publishing and integrations instead of XML-RPC, which is why many sites can disable the older endpoint without losing functionality. Check any third-party tool's documentation to confirm whether it still depends on XML-RPC or has moved to the REST API before you disable anything.
Sources
For deeper technical detail, the WordPress developer reference on xmlrpc_enabled covers the filter's exact behavior, while the Disable XML-RPC plugin page documents the plugin-based approach. WPScan's analysis covers the security case for disabling it, and Perishable Press walks through server-level blocking in detail. For a quick site check alongside these changes, the robots.txt checker from BabyLoveGrowth is a useful companion tool.
- Disable XML-RPC
- apply_filters( 'xmlrpc_enabled' ) — WordPress Developer Reference
- 3 Ways to Disable WordPress XML-RPC for Better Security | Perishable Press
- Is WordPress XMLRPC a security problem? — WPScan Blog