XML-RPC is a built-in WordPress feature that allows external applications and services to communicate with your website remotely.
It has been part of WordPress for many years and is enabled by default. However, because the xmlrpc.php endpoint can also attract automated login attempts and other unwanted traffic, many WordPress site owners wonder whether they should disable it.
The short answer is:
If your website does not use XML-RPC, disabling or restricting it is a reasonable WordPress security measure. If a service such as Jetpack or another remote integration depends on XML-RPC, you should keep it available and protect it instead of blocking it blindly.
What Is XML-RPC in WordPress?
XML-RPC stands for XML Remote Procedure Call.
It is a protocol that allows one system to send commands to another system over HTTP using XML-formatted requests.
In WordPress, these requests are normally sent to:
https://example.com/xmlrpc.php
External applications can use XML-RPC to perform actions on a WordPress site without manually logging into the WordPress dashboard.
Depending on the application and permissions involved, XML-RPC can support tasks such as:
- publishing and editing posts;
- retrieving posts and pages;
- managing comments;
- uploading media;
- retrieving site information;
- working with WordPress from external applications;
- receiving pingbacks.
WordPress still includes its XML-RPC server for backward compatibility and for services that continue to depend on it.
Is XML-RPC Enabled by Default in WordPress?
Yes.
XML-RPC has been enabled by default since WordPress 3.5.
Older WordPress versions included an option under:
Settings → Writing → Remote Publishing
that allowed administrators to enable or disable XML-RPC manually.
That setting no longer exists in modern WordPress installations.
Therefore, if you find instructions telling you to enable XML-RPC from the Writing settings screen, those instructions are outdated.
Do You Still Need XML-RPC?
That depends on how your WordPress website is being used.
Many normal WordPress websites do not directly need XML-RPC. If you only manage your site through wp-admin, XML-RPC may provide little practical benefit.
However, some external services and integrations still depend on it.
One important example is Jetpack, which uses XML-RPC to communicate between a self-hosted WordPress website and WordPress.com.
Before disabling XML-RPC, check whether your:
- security tools;
- publishing applications;
- remote management services;
- mobile or desktop applications;
- WordPress.com integrations;
- automation tools;
- custom integrations
depend on xmlrpc.php.
Do not disable an API simply because it exists. First determine whether anything on your website actually uses it.
Is XML-RPC a Security Risk?
XML-RPC itself should not automatically be treated as a vulnerability.
The security concern is that xmlrpc.php creates another remotely accessible interface that attackers and automated bots can target.
WordPress security guidance specifically identifies XML-RPC as a common brute-force target.
One method that has historically attracted attention is:
system.multicall
XML-RPC also provides pingback functionality, which has previously been abused for unwanted requests and denial-of-service activity.
This does not mean that leaving XML-RPC enabled automatically makes a WordPress site insecure.
A secure WordPress installation should still rely on broader protections such as:
- strong and unique passwords;
- two-factor authentication;
- updated WordPress core, plugins, and themes;
- rate limiting;
- a web application firewall;
- monitoring failed authentication attempts;
- limiting administrator accounts;
- HTTPS.
XML-RPC should therefore be considered one part of the site’s overall attack surface rather than the entire security strategy.
Should You Disable XML-RPC in WordPress?
For many WordPress websites, yes — if nothing actually requires it.
Consider disabling XML-RPC when:
- you manage WordPress only through the dashboard;
- no remote application connects through XML-RPC;
- Jetpack or similar integrations are not being used;
- your server receives significant unwanted requests to
xmlrpc.php; - you want to reduce unnecessary externally accessible endpoints.
You should probably keep XML-RPC available when:
- Jetpack requires it;
- an external publishing application depends on it;
- a remote management system uses it;
- you have a custom integration built around the XML-RPC API.
If XML-RPC is required, blocking the endpoint completely is usually the wrong approach.
Instead, consider protecting it using a WAF, rate limiting, IP restrictions where practical, and strong authentication.
How to Check Whether XML-RPC Is Accessible
The XML-RPC endpoint normally exists at:
https://yourdomain.com/xmlrpc.php
Opening this URL directly in a browser may return a message similar to:
XML-RPC server accepts POST requests only.
That tells you that the xmlrpc.php file is reachable.
However, this does not necessarily mean that every XML-RPC method is enabled.
WordPress can restrict authenticated XML-RPC methods while the endpoint itself remains accessible.
This distinction becomes important when testing security changes.
How to Disable XML-RPC Authentication in WordPress
WordPress provides the following filter:
add_filter( 'xmlrpc_enabled', '__return_false' );
You can add it through a custom plugin or a properly managed code-snippet system.
However, there is an important detail:
This does not completely block the XML-RPC endpoint.
Despite its name, the xmlrpc_enabled filter primarily disables XML-RPC methods that require authentication.
Other functionality, including certain pingback or custom XML-RPC methods, may still remain available.
Therefore, this method should not be described as a complete server-level block of xmlrpc.php.
How to Completely Block xmlrpc.php on Apache
If you are certain that your website does not require XML-RPC and your server uses Apache 2.4, you can deny access to the file at the web-server level.
Add the following to the appropriate Apache configuration or .htaccess file:
<Files "xmlrpc.php">
Require all denied
</Files>
This blocks HTTP access to xmlrpc.php before WordPress processes the request.
Because this can break services that depend on XML-RPC, test the website and its integrations after making the change.
Always back up configuration files before editing them.
How to Block xmlrpc.php on Nginx
On an Nginx server, the equivalent configuration can typically be handled with a dedicated location rule:
location = /xmlrpc.php {
deny all;
}
The exact configuration depends on how your server and PHP-FPM setup are structured.
If you use managed WordPress hosting, it may be better to ask your hosting provider or use its security controls rather than editing Nginx configuration manually.
What If You Need XML-RPC?
Disabling XML-RPC completely is not the only security option.
If an integration requires it, consider:
- rate limiting requests to
/xmlrpc.php; - using a WAF to filter abusive requests;
- monitoring repeated authentication attempts;
- using strong credentials;
- restricting access where your architecture allows it;
- disabling specific unnecessary XML-RPC methods instead of the entire endpoint.
Modern WordPress security guidance generally favors targeted controls and edge/server-level protection when XML-RPC needs to remain available.
XML-RPC vs. the WordPress REST API
For new WordPress integrations, the REST API is generally the more modern interface.
The WordPress REST API works with JSON and provides structured endpoints such as:
/wp-json/wp/v2/posts
It can be used to create applications, manage WordPress content, integrate external systems, and build custom interfaces.
WordPress also supports Application Passwords for authenticated API access. An Application Password can be created for an individual integration and revoked later without exposing or changing the user’s main WordPress password.
For example, a custom application that needs to publish or manage WordPress content can often use:
WordPress REST API + Application Password
instead of building a new XML-RPC integration.
This does not mean that you should remove XML-RPC when an existing service still requires it. The REST API is a modern option for new development, not an automatic replacement for every legacy integration.
What We Recommend
For most standard WordPress websites, the decision can be simplified to this:
| Situation | Recommendation |
|---|---|
| Nothing uses XML-RPC | Consider disabling it |
| Jetpack requires XML-RPC | Keep it available |
| Custom legacy integration uses it | Keep or selectively restrict it |
Heavy attacks are hitting xmlrpc.php |
Rate-limit, protect, or block it |
| Building a new custom integration | Consider the REST API |
| Unsure whether the site uses it | Test before disabling |
The important point is not to disable XML-RPC simply because a security checklist tells you to.
First determine whether it serves a purpose on your website. If it does not, removing an unnecessary remote-access endpoint is sensible hardening. If it does, protect it appropriately rather than breaking the integration.
Need Help Securing a WordPress Website?
WordPress security is rarely solved by changing one setting.
XML-RPC protection should be combined with proper server configuration, updates, authentication security, backups, monitoring, and protection against automated attacks.
Hollands Web works with WordPress hosting, website maintenance, troubleshooting, performance, and security configuration. If your WordPress website is receiving suspicious requests or you are unsure which services can safely be disabled, the site should be reviewed as a complete system rather than applying isolated security fixes.
Frequently Asked Questions
Is XML-RPC enabled by default in WordPress?
Yes. XML-RPC has been enabled by default since WordPress 3.5. The old option for enabling or disabling it from Settings → Writing was removed.
Is it safe to disable XML-RPC?
Usually, yes, if your website does not use any service or application that depends on it. You should verify your integrations before blocking it.
Does Jetpack need XML-RPC?
Yes. Jetpack uses XML-RPC to communicate between your WordPress website and WordPress.com, so completely blocking xmlrpc.php can cause Jetpack connection problems.
Does the xmlrpc_enabled filter completely disable XML-RPC?
No. The WordPress documentation explains that this filter disables methods requiring authentication, but it does not disable every XML-RPC method or pingback functionality.
Is the WordPress REST API better than XML-RPC?
For new custom integrations, the REST API is generally the more modern choice. It uses JSON, provides structured endpoints, and supports Application Passwords for authenticated external access.
