Here is the situation more developers are hitting in 2026 than at any point in the last five years: you are trying to connect a remote publishing tool, an automation workflow, a legacy mobile app, or a desktop blogging client to your WordPress site. You navigate to yoursite.com/xmlrpc.php expecting the confirmation message “XML-RPC server accepts POST requests only.” Instead, you get a 403 Forbidden error, a blank page, or a complete redirect to your homepage.

XML-RPC is enabled by default in every WordPress installation since version 3.5. So why is it not working?

Because your hosting provider has likely blocked it at the server level before it ever reaches WordPress. Or a security plugin disabled it. Or a caching plugin — not even a security plugin — quietly added a filter that breaks it. Or your .htaccess file has blocking rules added by a previous plugin that you already removed.

This guide covers all of it: what XML-RPC actually is, the exact methods to check if it is active or blocked, how to re-enable it at every level (WordPress core, .htaccess, Nginx, plugin), how to do that securely using IP whitelisting and Cloudflare WAF rules, and the honest assessment of when you should use XML-RPC in 2026 versus migrating to the WordPress REST API.

What Is WordPress XML-RPC?

XML-RPC (XML Remote Procedure Call) is a protocol that lets external applications communicate with your WordPress site using HTTP as the transport mechanism and XML as the data encoding format. It lives in a file called xmlrpc.php in the root directory of every WordPress installation.

According to the official WordPress Codex documentation at https://codex.wordpress.org/XML-RPC_Support, XML-RPC support allows external systems to interact with WordPress data. Its original use cases were wide: the WordPress mobile app, desktop blogging clients like Windows Live Writer and MarsEdit, pingbacks and trackbacks between sites, and the Jetpack plugin’s connection to WordPress.com.

XML-RPC predates WordPress itself — it was present in b2, the blogging software WordPress was forked from in 2003. It was initially disabled by default until WordPress 2.6 in 2008 added a toggle in Settings. Then WordPress 3.5 in 2012 enabled it permanently and removed the dashboard toggle entirely — largely to support the then-new WordPress mobile app.

That decision left xmlrpc.php enabled by default on every WordPress site worldwide, whether those sites use it or not. Which brings us to 2026 and the security situation that makes this topic so complicated to navigate.

The Security Reality: Why Hosts Block It and Why Some Still Need It

The reason your hosting provider blocks XML-RPC by default, and why security plugins disable it, is that xmlrpc.php is one of the most exploited files in WordPress. It is worth understanding exactly why so you can make an informed decision about enabling it.

The primary attack vector is the system.multicall method. This XML-RPC function allows a client to send multiple method calls in a single HTTP request. This sounds like a useful efficiency feature — and it is. But attackers abuse it to bundle hundreds or even thousands of authentication attempts into a single request. A standard brute force attack against the wp-login.php login page is easily detected: most security tools see repeated failed logins and block the IP address. XML-RPC’s system.multicall lets an attacker test 500 passwords with 3 or 4 HTTP requests. The server sees 4 requests, not 500 login attempts. Rate limiting and login lockout plugins that work at the application level often do not catch this at all.

The secondary attack vector is pingback amplification. XML-RPC’s pingback feature allows WordPress sites to automatically notify other sites when they are linked to. Attackers abuse this by sending forged pingback requests to thousands of WordPress sites simultaneously, all pointing at a single target URL. Each WordPress site then sends a verification request to the target, turning thousands of legitimate WordPress installations into participants in a DDoS attack.

These are real, active attacks that happen continuously in 2026. Security reports consistently rank XML-RPC exploitation among the top WordPress attack vectors. Hosting providers like Kinsta block it by default; others like Cloudways offer a one-click toggle; some shared hosts apply blanket .htaccess rules that block it without informing customers.

That said, there are legitimate reasons to enable XML-RPC in 2026. If you are running automation workflows that were built on XML-RPC before the REST API era and have not been migrated, you need it working. If you are using legacy desktop publishing clients (Windows Live Writer, MarsEdit on older macOS, Open Live Writer), you need it. If a specific plugin in your workflow still requires it and has not been updated to use the REST API, you need it. And if your n8n XML-RPC integration at https://n8n.io/integrations/xml/ is part of your current publishing pipeline, you need it until you migrate.

The answer to “should I enable XML-RPC” is not binary — it depends entirely on whether you have a specific, active use case for it. And if you do enable it, the security measures covered later in this guide are not optional.

Step 1: Confirm Whether XML-RPC Is Actually Active

Before doing anything else, confirm the current state of XML-RPC on your site. This prevents you from making changes to fix something that is not actually the problem.

Visit yoursite.com/xmlrpc.php directly in your browser.

There are three possible responses:

“XML-RPC server accepts POST requests only.” — This means XML-RPC is active and responding. The file is working correctly. Your issue is not that XML-RPC is disabled; it may be a credential or tool configuration problem.

403 Forbidden, 404 Not Found, or an error page — XML-RPC is blocked, either at the server level (.htaccess or Nginx configuration), by your hosting provider, or by a security plugin.

Redirect to your homepage — A plugin or code snippet has intercepted the request and redirected it. This is typically caused by a security plugin with XML-RPC blocking enabled.

You can also use an online XML-RPC validator tool — search for “XML-RPC validator WordPress” to find free tools that will test your endpoint and display the result.

Step 2: Re-Enable XML-RPC — The Four Methods

Work through these methods in order based on where your site is blocked.

Method 1: Remove Blocking Code in functions.php or a Plugin

If the response at yoursite.com/xmlrpc.php is a redirect or a PHP-level block (not a 403 from the server), the block is happening at the WordPress application layer. Search your theme’s functions.php and any active plugins for this filter:

add_filter(‘xmlrpc_enabled’, ‘__return_false’);

If you find it, removing this line re-enables XML-RPC at the application level. If it is in a plugin, deactivate the plugin or use the plugin’s settings to re-enable XML-RPC rather than editing its code directly.

To override a plugin that is blocking XML-RPC without removing it, you can add this to your theme’s functions.php:

add_filter(‘xmlrpc_enabled’, ‘__return_true’);

Note: This only works if the blocking plugin adds its filter at the default priority. If a plugin adds __return_false at a higher priority, this may not work and you will need to configure or deactivate the plugin directly.

Method 2: Remove .htaccess Blocking Rules (Apache Servers)

If you are getting a 403 error, check your .htaccess file in the root WordPress directory. Connect via FTP, SFTP, or your hosting control panel’s File Manager. The file may be hidden by default — enable “show hidden files” in your file manager to see it.

Look for any of these blocking patterns:

Block WordPress xmlrpc.php requests

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

Or:

Block XML-RPC

RewriteRule ^xmlrpc.php$ - [F,L]

Remove these blocks entirely, save the file, and test your xmlrpc.php URL again. Always back up your .htaccess file before making changes.

Method 3: Update Nginx Configuration (Nginx Servers)

For Nginx-based hosting, the block is typically in the server configuration file. Look for:

location = /xmlrpc.php { deny all; return 403; }

Comment out or remove this block, then restart Nginx (sudo systemctl restart nginx or via your hosting panel). Test again.

For managed hosting providers that block XML-RPC at the server level by default (Kinsta, WP Engine, and others), this configuration is not accessible to you directly. Contact your hosting support and request that XML-RPC be unblocked for your specific site. Most managed hosts have a process for this; Kinsta, for example, notes in their FAQ that XML-RPC is blocked by default but can be enabled by contacting support.

Method 4: Disable the Blocking Plugin or Adjust Its Settings

If XML-RPC is being blocked by a security plugin, open that plugin’s settings rather than trying to override it with code. Common plugins and where to find their XML-RPC settings:

Wordfence: Wordfence deliberately does not offer an XML-RPC disable option in the standard interface, as noted in their documentation. Wordfence’s approach is rate limiting authentication attempts rather than blocking XML-RPC entirely.

iThemes Security (now Solid Security): Go to Security > Settings > WordPress Tweaks. Toggle “Disable XML-RPC” off, or select “Disable Pingbacks” to only block the pingback abuse vector while keeping other XML-RPC methods functional.

Jetpack: If Jetpack itself is blocking XML-RPC due to connection issues, go to Jetpack > Settings and reconnect the plugin. Jetpack requires XML-RPC to connect to WordPress.com, so if you are using Jetpack, you categorically cannot disable XML-RPC.

All in One WP Security: Check the Firewall section for XML-RPC blocking rules and disable the specific rules that are blocking access.

After adjusting any plugin setting, re-test at yoursite.com/xmlrpc.php.

Step 3: Secure XML-RPC If You Must Keep It Enabled

If you have a legitimate reason to keep XML-RPC enabled, these security measures significantly reduce your exposure. None of them are optional if you are leaving xmlrpc.php accessible.

IP Whitelisting via .htaccess (Apache)

If you only need XML-RPC access from specific, known IP addresses — your office, your n8n server, your automation tool’s IP range — restrict access to those IPs only: <Files xmlrpc.php> Order deny,allow Deny from all Allow from YOUR.IP.ADDRESS.HERE Allow from ANOTHER.IP.ADDRESS.HERE </Files>

Replace YOUR.IP.ADDRESS.HERE with the actual IP addresses. For n8n Cloud, check the n8n Cloud IP addresses documentation to find the current outbound IP ranges to allowlist.

IP Whitelisting via Nginx

For Nginx, place this in your server block:

location = /xmlrpc.php { allow YOUR.IP.ADDRESS.HERE; deny all; }

Cloudflare WAF Custom Rule

If your site is behind Cloudflare, you can create a WAF rule that allows XML-RPC requests only from specific IP addresses or blocks system.multicall specifically, while passing through legitimate requests from your tools. Go to Cloudflare Dashboard > Security > WAF > Custom Rules and create a rule:

Field: URI Path Operator: equals Value: /xmlrpc.php Action: Block (for general blocking) or use IP-based expressions to allow specific sources

This blocks XML-RPC exploitation at the edge, before requests even reach your server — the most efficient blocking method available.

Disable Only Pingbacks While Keeping XML-RPC Functional

If you want to close the pingback DDoS vector without fully disabling XML-RPC, add this to your functions.php or a code snippet plugin:

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

This removes the pingback methods specifically while leaving all other XML-RPC functionality intact — including remote publishing and Jetpack.

XML-RPC vs the WordPress REST API: The Honest 2026 Comparison

This is the question every developer using XML-RPC for remote publishing should answer before investing time in the setup above.

The WordPress REST API, documented at https://developer.wordpress.org/rest-api/, was introduced in WordPress 4.4 in 2015 and reached full integration in 4.7 in 2016. It is the modern replacement for XML-RPC. Every legitimate use case that XML-RPC serves — creating posts, uploading media, managing comments, reading content — is covered by the REST API with significantly better security, JSON-based responses that are easier to parse in modern code, and OAuth2 authentication (using WordPress Application Passwords) instead of transmitting raw username and password credentials on every request.

The security difference is significant. XML-RPC sends credentials with every request. The REST API uses Application Passwords — revocable, per-application tokens that cannot be used for wp-admin login. This architecture is far more resistant to credential exposure.

When to use XML-RPC in 2026: You have a legacy tool that has not been updated and cannot be reconfigured to use the REST API. You are in the middle of a migration and need XML-RPC working temporarily. You are using a desktop blogging client (MarsEdit, Open Live Writer) that has not migrated its backend to the REST API.

When to use the REST API instead: Any new integration or automation workflow. n8n’s WordPress node (https://docs.n8n.io/integrations/builtin/app-nodes/n8n-nodes-base.wordpress/) uses the REST API with Application Password authentication — not XML-RPC. If you are setting up a new WordPress automation in n8n, use the REST API and Application Passwords rather than XML-RPC.

The practical migration path: If you are using XML-RPC for remote post creation, the equivalent REST API endpoint is POST /wp-json/wp/v2/posts. Authentication uses your WordPress username and an Application Password generated from Users > Profile. This is more secure, more reliable, and better supported by every modern tool including n8n.

Verifying XML-RPC Is Working After Re-Enabling

Once you have made your changes, verify with a direct browser test first. Navigate to yoursite.com/xmlrpc.php. You should see “XML-RPC server accepts POST requests only.” If you see this, the endpoint is responsive.

For a more complete test, use curl to make an authenticated POST request:

curl -X POST https://yoursite.com/xmlrpc.php
-H "Content-Type: text/xml"
-d '<?xml version="1.0"?><methodCall><methodName>wp.getUsersBlogs</methodName><params><param><value><string>yourusername</string></value></param><param><value><string>yourpassword</string></value></param></params></methodCall>'

A successful response returns an XML document with your site details. A failure returns a faultCode and faultString describing the error.

Common Errors and Fixes

403 Forbidden at xmlrpc.php

Server-level block. Check .htaccess for Files blocks targeting xmlrpc.php, check Nginx configuration, or contact your hosting provider to confirm they are not blocking it at the infrastructure level.

Empty page or homepage redirect at xmlrpc.php

PHP-level block via WordPress filter. Search functions.php and active plugins for add_filter(‘xmlrpc_enabled’, ‘__return_false’) and remove or override it.

“XML-RPC services are disabled on this site”

WordPress application is responding but XML-RPC is programmatically disabled. The xmlrpc_enabled filter is returning false. Find and remove or override the filter.

Authenticated requests failing with 403 or “Incorrect username or password”

Your credentials are wrong, or your Application Password is being used where a regular password is expected (or vice versa). XML-RPC uses your standard WordPress password, not an Application Password. Application Passwords are specifically for the REST API.

Jetpack failing to connect after changes

Jetpack’s WordPress.com connection uses XML-RPC. If you have re-enabled XML-RPC but Jetpack is still failing to connect, go to Jetpack > Settings and use the “Disconnect and Reconnect” flow. If you IP-whitelisted XML-RPC, you need to add Jetpack’s outbound IP ranges to your allowlist.

Requests working from browser but failing from automation tools

Your automation tool’s outbound IP addresses are not in your whitelist. Check the IP addresses your tool uses and add them to the .htaccess or Nginx allowlist.

Quick Reference

XML-RPC file location: /xmlrpc.php (root directory of WordPress)

Status check: Navigate to yoursite.com/xmlrpc.php in browser — “XML-RPC server accepts POST requests only” means active

Default state: Enabled in WordPress 3.5 and all later versions

Enable via filter: add_filter(‘xmlrpc_enabled’, ‘__return_true’); in functions.php

Disable via filter: add_filter(‘xmlrpc_enabled’, ‘__return_false’); in functions.php

Disable pingbacks only: Remove pingback.ping and pingback.extensions.getPingbacks methods via xmlrpc_methods filter

WordPress Codex XML-RPC docs: https://codex.wordpress.org/XML-RPC_Support

WordPress REST API docs: https://developer.wordpress.org/rest-api/

n8n XML-RPC integration: https://n8n.io/integrations/xml/

n8n WordPress node (uses REST API): https://docs.n8n.io/integrations/builtin/credentials/wordpress/

Final Thoughts

The XML-RPC situation in 2026 is a genuinely nuanced one. The feature exists, it is still enabled by default in WordPress core, and there are real use cases that still depend on it — particularly legacy tools, desktop clients, and Jetpack. At the same time, it is genuinely exploited at scale, and every responsible hosting provider blocks it by default for good reason.

The honest answer for most developers hitting XML-RPC problems in 2026: check whether you actually need XML-RPC, or whether your use case can be served by the REST API with Application Passwords instead. The REST API is faster, more secure, better documented, and supported by every major automation platform including n8n. If you are setting up a new workflow, use the REST API.

If you do need XML-RPC — legacy tools, Jetpack, specific automation setups — re-enable it using the methods in this guide, then immediately apply IP whitelisting or a Cloudflare WAF rule to restrict access to only the IP addresses that legitimately need it. Do not leave it fully open.