Part of the series: WordPress Pre-Launch Technical Checks
When reviewing a WordPress site before launch, one technical detail that often appears in security checklists is XML-RPC exposure.
Many developers disable it automatically. Others leave it untouched. Some are not even sure whether the site actually uses it.
Before delivering a WordPress project, it is worth understanding what XML-RPC does and whether leaving it exposed makes sense for the final setup.
What XML-RPC is
XML-RPC is a remote communication protocol built into WordPress. It allows external systems to interact with a site programmatically.
Historically it was used for things like:
- remote publishing tools
- mobile WordPress apps
- certain integrations and external services
In modern WordPress setups it is often not needed, but it still exists by default.
Why it appears in technical reviews
The problem is not that XML-RPC exists. The issue is that it may remain exposed even when nothing in the project actually requires it.
When that happens, the endpoint simply becomes an unnecessary surface that nobody reviewed during the launch process.
This is why many technical checklists include it as a point to verify before publishing a site.
Common XML-RPC situations before launch
1. Nobody checked whether it is needed
In many projects XML-RPC remains enabled simply because nobody reviewed it.
The site works, so the configuration stays untouched.
2. Legacy assumptions from older setups
Older WordPress workflows depended more heavily on XML-RPC. Some configurations remain from those times even when the modern stack no longer uses them.
3. Security plugins disabling it automatically
Some security plugins disable XML-RPC by default. In those cases it might already be restricted without anyone explicitly deciding it.
Understanding what the final configuration actually does is part of a clean technical delivery.
What I usually review before launch
When checking a WordPress site before delivery, I typically review:
- whether the XML-RPC endpoint is publicly reachable
- whether the project relies on any functionality that needs it
- whether the final configuration reflects a deliberate decision
- whether plugins or server rules already modify its behavior
The goal is not necessarily to disable it everywhere, but to avoid leaving technical decisions unreviewed.
Why this belongs in a launch checklist
XML-RPC exposure is a good example of something that rarely breaks a site immediately, but still deserves attention.
It sits in that category of technical details that are easy to ignore during development but should be reviewed before a project is considered finished.
Including it in a repeatable launch checklist helps keep deliveries technically cleaner.
Where PreFlight fits in
PreFlight focuses on the technical review stage before delivering a WordPress project.
If you want to review XML-RPC exposure as part of a technical check, you can see the check here:
https://preflightstandard.com/checks/xml-rpc-exposure/
And if you want to run a broader technical review before publishing or delivering a site:
https://preflightstandard.com/
Final thought
Not every technical detail will break a launch. But a professional delivery process should still review them.
XML-RPC exposure is one of those small checks that helps make sure nothing unnecessary is left open once a site goes live.
Top comments (0)