A publishing app can fail to connect even while the website opens normally. That does not automatically mean XML-RPC is broken: the app may use the REST API or its own service instead.
Check the integration’s documentation and the exact endpoint it contacts before changing security settings. Once you know which interface it uses, the response code or XML fault can show whether WordPress, a firewall or authentication rejected the request.
If XML-RPC is required, compare the endpoint, HTTP response and XML fault before changing access settings. A browser GET test is not the same as the client’s authenticated publishing request.
Guide reviewed: October 8, 2026. Menu labels use English WordPress; provider-specific controls may differ.
Confirm the client and endpoint before changing security
| Result | Check | Next step |
|---|---|---|
| Endpoint says POST requests are required | Browser used GET | Use the client’s supported connection test |
| XML fault reports authentication failure | Client credential and account capability | Follow the provider’s credential workflow |
| HTTP block page or challenge | Host/CDN/security event | Find the exact blocked request and policy |
| XML parser receives HTML | Unexpected response content | Identify redirect, login or warning page |
| Client supports REST instead | Documented migration route | Set up and test the supported REST flow |
The endpoint needs to match the installation
- Read the integration’s current connection requirements.
- Confirm the WordPress installation path and HTTPS hostname.
- Compare the documented endpoint with the address saved in the client.
- Run the client’s safe connection check and preserve its full error.
For example, an installation under /wordpress/ may use /wordpress/xmlrpc.php. These are illustrative paths; use the actual installation location.
For WordPress installed at the root of a domain, the endpoint is normally https://example.com/xmlrpc.php. An installation in a subdirectory may need that directory in the path. An old hostname or missing path can make a reachable site appear unavailable to the client.
Opening the endpoint in a browser is only a basic reachability check. XML-RPC clients send POST requests containing an XML method call; a browser navigation usually sends GET. A message about accepting POST requests can therefore be normal and does not establish whether authenticated publishing works.
The HTTP response and XML fault are not interchangeable
Record two separate values: the HTTP status and the XML response’s fault code/message. A WordPress authentication fault and a firewall’s HTML 403 page need different follow-up even when both contain the number 403.
WordPress can return an XML-RPC fault containing a code and message within the response body. That fault code is separate from the HTTP status of the request. For example, a WordPress XML-RPC authentication fault can use 403, while an upstream firewall can independently return an HTTP 403 page.
The distinction matters when deciding what to change. A WordPress message about credentials belongs in the authentication investigation. A branded block page belongs in the security or host investigation. An XML parsing error may mean the client received HTML or an unexpected warning instead of the XML response it expected.
Keep the full response, the client version, the operation and its approximate time. Remove passwords, tokens and private content before sharing a log.
A security setting may deliberately limit XML-RPC
A plugin, code snippet, hosting policy or firewall can restrict the endpoint or particular methods. WordPress filters such as xmlrpc_enabled and xmlrpc_methods can affect different parts of the service. In particular, xmlrpc_enabled should not be assumed to switch every possible XML-RPC method off.
If a setting appears to be involved, identify why it was added and what the integration needs before removing it. A supported plugin setting is generally easier to understand than layering another snippet over existing custom code.
A client that needs remote publishing does not necessarily need pingbacks or every available method. Keep the comparison focused on the required workflow rather than treating XML-RPC as a single all-or-nothing feature.
Authentication depends on the supported client workflow
The integration may expect a username and an application-specific credential, or another provider-supported connection. Follow its current instructions. A valid account still needs the capabilities required for the action, so being able to authenticate does not prove that it can publish, upload or manage every item.
Repeatedly trying different passwords is unhelpful when a firewall is refusing the request before WordPress sees it. Compare the response and logs first. Credentials belong in the official setup flow, not in a public test URL or support screenshot.
Where to look when the request never reaches WordPress
A hosting rule, CDN challenge or security plugin may block /xmlrpc.php. Look for an event at the time of the failed operation, including a rule identifier or blocked source where available. A client connecting from a server can encounter a different policy from a visitor browsing on a home connection.
A required integration may need a documented, narrowly scoped exception. The host or security provider can help establish what is supported. Disabling the entire firewall makes the test broader than the original problem and can conceal the rule that needs attention.
Testing one harmless operation gives a clearer answer
- Use the client’s supported authentication method with an authorized account.
- Create one harmless draft if that is the permitted workflow.
- Open WordPress and confirm the draft exists with the expected content.
- Check an upload separately only if the integration needs it.
A successful account lookup proves less than a saved draft. Avoid repeated publishing attempts while a rate limit is active.
A reachability test without credentials can show whether the endpoint responds to an XML-RPC request, but it cannot prove authenticated publishing. The next test should be the client’s own safe connection check or a permitted operation such as creating a draft.
Check the expected result in WordPress rather than relying only on a success message in the client. A saved draft demonstrates a different part of the workflow from a successful account lookup. If rate limiting is involved, avoid bulk retries while testing.
Moving to REST when the provider supports it
The REST API can be an alternative when the integration explicitly supports it. It returns JSON and applies authentication and permissions to protected operations. Migration requires the client’s supported endpoint and authentication flow; substituting a REST address into an XML-RPC field is not enough.
After migration, repeat the smallest required operation before returning to routine publishing. If no integration needs XML-RPC, there is no reason to enable it merely because it is available. Record the required interface, the responsible setting and the test that confirmed recovery so future changes are easier to review.
XML-RPC references and safer alternatives
- XML-RPC documentation
- REST API Handbook
- official login method reference
- wp_xmlrpc_server class reference
- WordPress invalid JSON responses
- WordPress 400 Bad Request errors
- WordPress changes not showing after an update
Keep only the interface the integration needs
If the provider supports a REST migration, follow its documented setup and test a draft before routine publishing. Do not replace an XML-RPC address with a REST address while leaving the client protocol unchanged. The official WordPress XML-RPC documentation describes the interface.