WordPress XML-RPC Not Working? 8 Checks

WordPress XML-RPC not working? When a mobile app, publishing tool, or external integration can no longer connect to WordPress, the error often points to xmlrpc.php. A blocked request can look like an authentication failure, a firewall rule, a disabled service, or a problem in the client itself. Those causes need different fixes.

XML-RPC is a remote interface that can manage WordPress content and other features. It is still used by some older tools and integrations, but a site does not need to expose it simply because it exists. The safest troubleshooting path is to identify what the client needs, read the exact response, and change only the layer that is actually failing.

Quick answer

Start by confirming the endpoint your client uses: https://your-domain.com/xmlrpc.php. Then compare the error with these common patterns:

405 or a message saying XML-RPC is disabled: WordPress or a plugin is refusing the service.
403 or an authentication message: credentials, permissions, a security plugin, or a firewall may be involved.
Timeout, connection reset, or 429: the host, CDN, rate limit, or Web Application Firewall may be blocking the request.
500 or an XML parsing error: a plugin, theme, PHP warning, or server response may be corrupting the XML reply.

If the integration does not specifically require XML-RPC, use a provider-supported REST API connection instead. WordPress documents XML-RPC as a remote API, while the REST API provides a JSON-based interface for applications and the block editor. See the official XML-RPC documentation and REST API Handbook before changing a security setting.

What a failed XML-RPC connection looks like

The same integration can fail in more than one way. Write down the complete message, HTTP status, approximate time, and the action that triggered it. “The site is unreachable” is less useful than “the request reaches the site and returns 405” or “only one network receives 403.”

The client says the site is not a WordPress site.
A publishing action fails while the public site still loads.
A login or account-list request returns 403.
The client reports that XML-RPC services are disabled.
Requests work from one connection but time out from another.
The response is an HTML error page instead of an XML-RPC response.

Before changing anything

Do not begin by disabling every security feature. First record the client name and version, the site URL it has saved, the exact error, and whether the problem affects one user or every user. If the site is important, take a current backup and use a staging copy for code-level tests.

Also check whether the client is still supported. An old integration may be using XML-RPC even though its vendor now recommends the REST API. An outdated client can produce a misleading “login failed” message when the real problem is an obsolete endpoint or authentication method.

1. Confirm that the client really needs XML-RPC

Look in the integration’s official documentation for the words XML-RPC, WordPress API, or REST API. Do not assume that every WordPress publishing tool uses the same interface. Some use REST endpoints, some use a service in the middle, and some still send XML-RPC requests.

If the vendor supports REST, record that as the preferred migration path rather than reopening XML-RPC only to keep an old connection alive. This also makes the next diagnostic step clearer: you can test the interface the integration is actually designed to use.

2. Check the endpoint and the site address

The endpoint must point to the WordPress installation, not only to the homepage. For a root installation it is normally:

https://example.com/xmlrpc.php

A subdirectory installation may use a path such as https://example.com/blog/xmlrpc.php. Copy the exact HTTPS address from the site configuration or the integration’s setup screen. A missing subdirectory, an old domain, or an HTTP address redirected to HTTPS can make a working service appear broken.

A browser visit is only a basic reachability check because XML-RPC clients send POST requests. It does not prove that a specific method or login will succeed. Never put a real password in a public test, screenshot, URL, or support ticket.

3. Read the status code instead of guessing

WordPress’s XML-RPC server code distinguishes a disabled service from failed authentication. Its official reference shows a 405 error when XML-RPC is disabled and a 403 error for incorrect credentials. That distinction is useful, but a security plugin or host may return its own 403, 429, or HTML page before WordPress handles the request. See the official login method reference for the WordPress-level behavior.

Compare the response in the client’s log with the response from the server. If the body says “XML-RPC services are disabled on this site,” investigate WordPress filters or plugins. If the body is a branded firewall page, investigate the CDN, host, or security layer. If only the client reports a failure and the server log shows nothing, check the client’s saved URL and network path first.

4. Check whether a plugin or code snippet disabled it

XML-RPC can be disabled with the xmlrpc_enabled filter. A security plugin, a snippets plugin, or custom theme code may add that filter. The WordPress code reference documents this setting in the wp_xmlrpc_server class reference.

Review active security and snippets plugins, then search a staging copy of the theme or custom plugin files for:

xmlrpc_enabled
wp_xmlrpc_server
xmlrpc_methods

If you find a filter, identify why it was added before removing it. Do not paste a “re-enable” snippet into the live site as a first response. If a plugin owns the setting, change it in that plugin’s documented settings so the change remains understandable and reversible.

5. Verify the account and authentication method

A valid WordPress username does not guarantee that an external client is allowed to perform every action. Check the account role, the site it belongs to, and whether the client expects a username, an application-specific credential, or a third-party connection. Follow the integration provider’s current authentication instructions instead of trying multiple passwords.

Change a credential only through the official WordPress or provider screen. Do not send the main administrator password to a support agent, enter it into an unknown plugin, or store it in a screenshot. If the credentials are correct but the response is 403, keep investigating the firewall and permissions layers rather than repeatedly locking the account with failed attempts.

6. Check the host, CDN, and security plugin logs

Many XML-RPC failures happen before WordPress receives the request. A host-level rule, CDN firewall, bot challenge, IP reputation rule, or rate limit can block /xmlrpc.php. Security plugins can do the same. Check the timestamp of a failed request in each available log and look for a matching rule ID, blocked IP, challenge, or rate-limit event.

Allowing one required request is safer than turning off the Web Application Firewall globally. Ask the host or CDN provider whether the endpoint is blocked and what narrow exception they recommend. If you use a security plugin, check its official documentation for XML-RPC, brute-force protection, and allowlist settings. Keep a note of every exception so it can be reviewed later.

7. Test pingbacks and publishing separately

XML-RPC is not one single feature. WordPress exposes methods for posts, media, comments, users, and pingbacks. A publishing client may need only a small part of that surface, while a pingback request follows a different path. A failure in pingbacks does not automatically mean that authenticated publishing is broken.

Test one harmless operation at a time. Avoid sending repeated login attempts or bulk requests while diagnosing a rate limit. If you do not use pingbacks or a legacy remote-publishing workflow, ask whether that feature can remain disabled. The goal is to restore the required integration, not to expose every available method.

8. Move to a supported REST connection when possible

If the vendor supports the WordPress REST API, migrate the connection according to its documentation. The REST API returns JSON and is used by the block editor and modern WordPress applications. It also applies authentication and privacy restrictions to protected content, so a successful connection still depends on the correct account and permissions.

Do not substitute a random REST URL for an XML-RPC login. The integration must support the REST endpoint and its authentication flow. After migration, test the smallest required action first: read a permitted item, create a draft, or perform the vendor’s safe connection test. Only then enable publishing or other write actions.

Useful diagnostic request

For administrators who understand command-line tools, the following request checks whether the endpoint returns an XML-RPC response without sending account credentials. Replace the domain, run it once, and inspect the status and response body. It is a reachability check, not a full publishing test.

curl -i -X POST https://example.com/xmlrpc.php \
  -H "Content-Type: text/xml" \
  --data '<?xml version="1.0"?>
<methodCall>
  <methodName>system.listMethods</methodName>
  <params></params>
</methodCall>'

A response from the wrong host, a WAF-branded HTML page, or a clear 403/405 status tells you which layer to investigate. Do not use a public command history or shared terminal for real credentials.

Common mistakes that make troubleshooting harder

Testing only the homepage and assuming it tests xmlrpc.php.
Changing the password repeatedly when the firewall is returning 403.
Disabling the CDN or security plugin globally without recording the change.
Allowing every XML-RPC method when the client needs only one workflow.
Copying an old code snippet without checking what plugin or theme added it.
Testing from one network when the block affects only a server IP or region.
Calling a legacy XML-RPC integration “fixed” before a real draft or safe action succeeds.

WordPress, plugin, and hosting differences

WordPress core can report one status, while a security plugin, reverse proxy, CDN, or hosting firewall can replace it with another. The same URL may therefore behave differently in a local test, a browser, a mobile app, and a server-to-server request.

Start with the layer that generated the response. A WordPress message belongs in the WordPress or plugin settings. A branded block page belongs in the CDN or host logs. A client-only error belongs in the integration’s saved URL, authentication flow, or request log. This layered approach prevents unrelated settings from being changed together.

Best 3 questions

Is XML-RPC enabled by default in WordPress?

The official wp_xmlrpc_server reference says XML-RPC is enabled by default as of WordPress 3.5, but a plugin, theme, snippet, host, or firewall can disable or block it. The effective behavior on your site must be checked at each layer.

Does a 403 always mean the username or password is wrong?

No. WordPress can use 403 for incorrect XML-RPC credentials, but a security layer can also return 403 before WordPress handles the request. Read the response body and compare the time with firewall and security logs.

Should I re-enable XML-RPC if I do not use it?

Not automatically. If no supported integration needs it, keeping an unnecessary remote interface closed may be the simpler choice. Confirm the requirement with the provider and use the REST API when that is the supported alternative.

Related WordPress checks

If the XML-RPC client also reports an API or editor problem, compare it with our guides to WordPress invalid JSON responses, WordPress 400 Bad Request errors, and WordPress changes not showing after an update. These symptoms can share a firewall or caching layer, but the fixes are not interchangeable.

Final checklist

Confirm the exact client, endpoint, and required interface.
Record the complete status code and response body.
Separate WordPress errors from CDN, host, and plugin blocks.
Check the account and supported authentication method without exposing credentials.
Review the narrowest relevant log and setting.
Test one safe action and confirm the expected result.
Migrate to REST when the provider supports it.

XML-RPC troubleshooting becomes much less confusing when every response is tied to the layer that produced it. Restore only the access the integration needs, document the change, and recheck the connection after the next plugin, host, or security update.

WordPress XML-RPC Blocked? Identify the Provider, Firewall or Endpoint