What XML-RPC Does in WordPress
XML-RPC is a WordPress communication endpoint that lets external apps send data to your site, including publishing requests, remote comments, and pingbacks.
It was useful before the WordPress REST API became widely adopted, but it can also expand your attack surface if you do not need it.
Understanding its role matters before you turn it off.
Some plugins, mobile apps, and third-party services still rely on XML-RPC, so the safest approach is to confirm what your site uses and then disable only what you do not need.
Why Site Owners Disable XML-RPC
The main reason to disable XML-RPC is security.
Attackers often target the endpoint for brute-force login attempts, pingback abuse, and amplification in distributed attacks.
- Brute-force protection: XML-RPC can allow multiple login attempts through a single request pattern.
- Pingback abuse prevention: Pingbacks can be misused to create unwanted traffic or spam.
- Reduced attack surface: Fewer exposed features generally means fewer ways to exploit a site.
- Compliance and hardening: Security policies often recommend disabling unused services.
At the same time, disabling XML-RPC is not always necessary.
If you use the WordPress mobile app, Jetpack, remote publishing tools, or certain integrations, you should verify whether they still depend on it.
How to Check Whether Your Site Uses XML-RPC
Before you disable anything, audit your site’s dependencies.
Check your active plugins, publishing workflow, and any external tools that connect to WordPress.
Common XML-RPC users
- WordPress mobile app
- Jetpack connections and some Jetpack features
- Remote posting tools like older desktop blog clients
- Services that publish content or manage comments remotely
You can also test the endpoint directly.
Visiting /xmlrpc.php on your domain should usually return a response if the file is available.
A simple test with a security plugin or server-side log review can reveal whether requests are still reaching it.
How to Disable XML-RPC in WordPress Safely
The safest method depends on your hosting stack, theme, and plugin setup.
For most sites, a plugin-based approach is the least disruptive because it is easy to reverse if something stops working.
Method 1: Use a security plugin
Security plugins such as Wordfence, Solid Security, or similar hardening tools often include an option to disable XML-RPC.
This is usually the simplest method for non-technical site owners because it avoids manual file edits.
- Install or open your security plugin.
- Find the hardening or firewall settings.
- Enable the option to block or disable XML-RPC.
- Test login, publishing, and any connected services afterward.
This option is often preferable because it is reversible and can be paired with other protections like rate limiting and login alerts.
Method 2: Block XML-RPC with .htaccess
If your site runs on Apache, you can block access at the server level using the .htaccess file.
This is more direct than a plugin and can reduce processing overhead.
Example rule:
<Files xmlrpc.php> Order Deny,Allow Deny from all </Files>
On Apache 2.4+, the preferred syntax is:
<Files xmlrpc.php> Require all denied </Files>
After saving the file, verify that your site still functions normally.
Server-level blocking is effective, but it can interfere with legitimate remote publishing or app-based workflows if you depend on them.
Method 3: Block XML-RPC in NGINX
For sites hosted on NGINX, block the endpoint in the site configuration rather than through .htaccess, which NGINX does not use.
This keeps the rule close to the web server and is usually efficient.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
After updating the config, reload NGINX and test the endpoint.
If you use managed hosting, ask support to apply the change safely.
Method 4: Disable XML-RPC with a code snippet
Some developers prefer to disable XML-RPC by adding a filter in a custom plugin or the theme’s functions file.
A small code-based solution can be useful if you want fine control, but it is less ideal than a dedicated security plugin unless you maintain the site regularly.
add_filter( 'xmlrpc_enabled', '__return_false' );
This disables XML-RPC at the application level.
Use a child theme or custom plugin rather than editing a parent theme directly, so updates do not remove your change.
How to Disable XML-RPC Without Breaking Useful Features
Disabling XML-RPC safely means matching the method to your site’s actual needs.
If you use only the WordPress dashboard, most visitors will never notice the change.
- Test publishing: Create a draft and publish a post after disabling XML-RPC.
- Check mobile access: Confirm whether the WordPress mobile app still connects.
- Verify integrations: Test Jetpack, scheduling tools, and any remote editors.
- Review logs: Watch for blocked requests and failed authentication attempts.
If a critical workflow breaks, re-enable XML-RPC temporarily and identify the exact service that depends on it.
In some cases, replacing the old integration with the WordPress REST API is the better long-term fix.
XML-RPC vs REST API: What Should You Use Instead?
For modern WordPress sites, the REST API is usually the better choice for integrations and app development.
It is widely supported, actively used by core WordPress features, and better aligned with current development practices.
That said, the REST API is not a direct replacement for every legacy XML-RPC use case.
Some older desktop publishing tools and external services still need XML-RPC specifically, so do not remove it blindly if those tools are part of your workflow.
Security Best Practices After Disabling XML-RPC
Turning off XML-RPC is one layer of defense, not a complete security strategy.
Combine it with broader hardening measures to reduce the chance of compromise.
- Use strong, unique passwords and two-factor authentication.
- Limit login attempts with a trusted security plugin or host feature.
- Keep WordPress core, plugins, and themes updated.
- Remove unused plugins and inactive themes.
- Use a web application firewall, such as Cloudflare or a host-managed firewall.
Also review your server logs for repeated requests to xmlrpc.php.
If your site receives many hits, that is often a sign the endpoint was being probed automatically.
When You Should Not Disable XML-RPC
There are situations where keeping XML-RPC enabled is reasonable.
If your editorial team publishes from the WordPress mobile app, if Jetpack features require it, or if an external business system depends on it, disabling it may create more problems than it solves.
In those cases, harden the endpoint instead of removing it entirely.
A firewall, rate limiting, login protection, and IP allowlisting for trusted services can reduce risk while preserving functionality.
Quick Checklist Before You Make the Change
- Confirm whether any plugin or service uses XML-RPC.
- Choose the safest blocking method for your hosting environment.
- Back up your site before editing server files or code.
- Test publishing, login, and integrations after the change.
- Monitor logs for unexpected failures or blocked requests.
For most site owners, the safest answer to how to disable XML RPC in WordPress safely is to use a reversible method first, then move to server-level blocking only after testing confirms nothing critical depends on it.