Should you disable XML-RPC in WordPress? How to decide and do it

Q: Can I disable XML-RPC from the command line?

Yes. wp bettershield harden xmlrpc --dry-run describes the change, wp bettershield harden xmlrpc --user=admin applies it, and adding --undo reverses it. See WP-CLI commands.

Your security audit flags XML-RPC, and the usual advice is to disable XML-RPC in WordPress straight away. Often that is right. But if you publish from the WordPress mobile app or rely on Jetpack, turning it off can stop them working.

So the real question is whether anything on your site still uses it. This guide shows how to find out, then how to turn it off in BetterShield with a preview, an optional watch period and an undo that never expires.

Quick summary

XML-RPC is a legacy remote-access API at xmlrpc.php, and a frequent target of automated sign-in attempts.
BetterShield’s own note says turning it off could break the WordPress mobile app and Jetpack, if you publish through them. The REST API is untouched.
Preview the change says whether anything has used XML-RPC recently. Monitor first watches real requests for 1 hour, 24 hours or 7 days before you enforce.
Once applied, xmlrpc.php answers 403. Turning the switch off brings XML-RPC back at once.
An AI assistant allowed to make changes can apply this fix directly. Taking it off again needs a plan you agree to.

What XML-RPC is, and why xmlrpc.php draws so many requests

XML-RPC is an older remote-access API built into WordPress, in one file, xmlrpc.php, at the root of your site. Outside apps send it requests to publish and manage content, and other sites use it for pingbacks, the notices one site sends another when it links to it.

WordPress also has a newer interface, the REST API, and the block editor works through that. XML-RPC stays on unless something turns it off.

Most XML-RPC requests that do something carry a username and password. That makes xmlrpc.php a second place to try passwords, away from the sign-in page. BetterShield’s audit sums it up as “a legacy remote-access API that most sites no longer use, and a frequent target of automated login attempts.”

Is XML-RPC needed on your site?

Three questions settle most cases:

Does anyone publish from the WordPress mobile app? BetterShield’s note on the finding says it could break.
Do you use Jetpack? The same note names it. When Jetpack is active, the fix’s row also says: “Jetpack is active and some of its features use XML-RPC. Check your Jetpack connection after applying.”
Does any outside tool or service post to the site with a username and password? Some older publishing tools work this way. Ask whoever set them up.

Whatever your answers, turning it off stops incoming pingbacks. Trackbacks and the REST API are left as they are, so editing in the dashboard carries on as before.

If all three answers are no, you probably do not need it. Either way, check the evidence first.

The finding: XML-RPC is enabled

On BetterShield › Findings, XML-RPC is enabled is a Medium finding in the Exposure area. It takes 7 points off your score while it is open. Explain shows:

Why it matters: the sentence quoted above.
What could break: “Could break: the WordPress mobile app and Jetpack, if you publish through them.”

Its Apply fix button, here and under Worth doing first on the Overview, applies the fix at once. Because it can break publishing tools, it is not among the five Quick Setup fixes. Open it on the Hardening screen instead, where you can look first. More in the Score and findings guide.

How to disable XML-RPC in WordPress, step by step

Open BetterShield › Protect › Hardening. Disable XML-RPC is under What can run: “Turns off the legacy XML-RPC API completely. No files are modified, and undo restores it instantly.”

1. Preview the change

Press Preview the change. Nothing changes. The first line answers from your activity log, which records each hour in which something used XML-RPC as XML-RPC used. It reads one of two ways:

“Nothing has used this in the last 30 days, which is as far back as this site’s log goes.”
“Something used this on 5 separate hours in the last 30 days, most recently 2 hours ago. Switching this off will stop it.”

The window never reaches further back than the log, or than BetterShield has been active; in its first day there is no line yet.

Below that, the preview lists what applying would do: answer every request to xmlrpc.php with 403 Forbidden, before WordPress processes it; remove the XML-RPC methods, pingbacks included; stop advertising the endpoint; and leave trackbacks and the REST API untouched.

2. Monitor first, if you are unsure

If the preview finds recent use, or you cannot say what it was, watch before you enforce. Press Monitor first at the end of the row:

Choose a New observation window: 1 hour, 24 hours (preselected) or 7 days. Pick a week if something might only connect now and then.
Press Start monitoring with the fields above. Nothing is blocked while it watches.
The panel counts what arrives, as “38 requests observed; 3 matched this rule.” End monitoring now stops early.
When the window ends, press Enforce reviewed settings. It needs a working recovery link or printed recovery codes, and the normal undo still works.

Automated sign-in attempts reach xmlrpc.php too, so a count above zero does not prove that something you rely on uses it. Requests handled before WordPress, by your host for example, are not counted, so zero proves nothing either. Read it together with the preview.

3. Apply it

Turn the Disable XML-RPC switch on, or press Enforce reviewed settings at the end of a watch. The row shows On since and Undo never expires, and the change is written to the activity log.

To check, open yoursite.com/xmlrpc.php in a browser. It answers 403 with one line: “XML-RPC is disabled on this site.” The finding moves to Fixed; if it is still listed, press Run audit.

If Jetpack is active, check its connection now, as the note beside the switch asks. If you publish from the mobile app, try a test post.

4. Undo it if something stops working

Turn the Disable XML-RPC switch off. XML-RPC answers again straight away, and the finding returns to your score. This undo has no time limit.

How application passwords fit in

An application password is a separate password you create under your WordPress profile for one app. WordPress accepts them over both the REST API and XML-RPC, and, as BetterShield’s screen puts it, they sign in without the second factor.

Disable XML-RPC leaves them working on the REST API. To refuse them, use Refuse application passwords under Signing in on Protect › Login & Access, for Accounts that can manage this site (preselected) or Every account. Nothing is deleted.
Two-factor changes how XML-RPC signs in. For an account with two-factor or passkey-only sign-in, BetterShield refuses XML-RPC with the account password: “This account uses two-factor authentication, so XML-RPC needs an application password instead of the account password.” See Two-factor and passkeys.
The two fixes overlap. An app that signs in to XML-RPC with an application password stops when XML-RPC is off, and also when application passwords are refused for its account. Refuse application passwords also previews recent use and offers Monitor first, so look at both.

What an AI assistant may do with this fix

BetterShield’s built-in MCP server lets an assistant such as Claude or ChatGPT work with your site once you turn it on under BetterShield › Agents › Connect. For this fix:

Before you decide. Even a read-only assistant can read your activity log, where XML-RPC use is recorded, so you can ask whether anything has used it lately.
Applying. With Let agents act: changes that can be undone right away, anything heavier once you agree on, and a credential allowed to change the site, an assistant can apply Disable XML-RPC directly. It is one of seven reversible fixes that apply without a plan, and the way back is written down before the change is made. Ask it to describe the change first: its plan carries the same lines as Preview the change.
Taking it off. An assistant can only turn the fix off through a plan you agree to in the conversation.
Watching first. Monitor first runs from the Hardening screen, so start it yourself.

Every call over the connection is recorded in the activity log. More in WordPress MCP: connecting an AI assistant safely and Connect an AI assistant.

Common mistakes

Pressing Apply fix on the Overview without a look. It applies at once. If anyone publishes from the mobile app, preview first.
Treating a Monitor first count as a verdict. Automated traffic adds to it, and a quiet week proves nothing on its own.
Expecting it to close the REST API or application passwords. It closes XML-RPC only.
Forgetting Jetpack afterward. If the note beside the switch mentions Jetpack, check its connection once the fix is on.
Doing the same job in two plugins. If another security plugin already turns XML-RPC off, keep the job in one place, so you know where to undo it.

Frequently asked questions

Does disabling XML-RPC affect the REST API or the block editor?

No. The fix leaves the REST API untouched, and the block editor works through the REST API, so editing in the dashboard carries on as before.

Will the WordPress mobile app still work?

Perhaps not, if you publish through it: BetterShield’s note names the mobile app and Jetpack. Preview the change shows whether anything has used XML-RPC recently, and turning the switch off brings it back at once.

Can I disable XML-RPC from the command line?

Yes. wp bettershield harden xmlrpc --dry-run describes the change, wp bettershield harden xmlrpc --user=admin applies it, and adding --undo reverses it. See WP-CLI commands.

My site needs XML-RPC. What should I do with the finding?

Leave XML-RPC on. If you will always need it, mark the finding Not applicable; if you plan to move off it, Remind me later keeps it counting. Wrong passwords sent through XML-RPC still count toward BetterShield’s sign-in attempt limit (see Login & Access).

Conclusion

WordPress XML-RPC security comes down to one decision, made with evidence. BetterShield’s audit says most sites no longer use XML-RPC, and yours may be one of them. Preview the change, watch for a day or a week if you are unsure, then apply it knowing the switch puts it back.

BetterShield is free on WordPress.org. The Hardening guide covers this fix and the other fifteen.