Can I just delete the xmlrpc.php file?

You can, and it comes back: WordPress core updates restore the file. Blocking access at the edge or in your server configuration is the durable fix, because it survives every update and takes effect for attackers before WordPress runs.

Will blocking xmlrpc.php break Jetpack or the mobile app?

It can, because both use xmlrpc.php to talk to your site. If you rely on Jetpack, the WordPress mobile app, or remote publishing tools, use a Managed Challenge instead of a block, or allow only the IP ranges those services publish. If you use none of them, a full block is safe.

Does blocking xmlrpc.php hurt SEO?

No. Search engines crawl your pages over normal HTTP requests and never touch xmlrpc.php. The file exists for remote publishing and pingbacks, and neither plays any role in how your site is crawled, indexed, or ranked.

How do I find out whether anything still uses it?

Watch before you block. In Cloudflare, open Security Events, filter the URI path for xmlrpc.php, and look at a few days of traffic. Requests from your own tools have recognizable sources; the rest is almost always automated abuse from addresses you have never seen.

What Is xmlrpc.php and Why Is It Being Hammered?

Open your access log on almost any WordPress site and you will find it: request after request to a file you have never touched, xmlrpc.php. Here is what that file actually does, why attackers love it more than your login page, and how to close it down safely.

What does xmlrpc.php actually do?

It is WordPress's old remote-control socket. XML-RPC is a protocol from the early days of blogging that lets other software talk to your site: publish a post from a desktop app, connect the WordPress mobile app, let Jetpack reach your site, or exchange pingbacks with other blogs. Every WordPress install ships with it at the same address, /xmlrpc.php, switched on. Most of what it did has since moved to the newer REST API, which modern WordPress and its plugins use instead, so on a typical site today the old socket sits unused. Except by attackers.

Why do attackers hammer it?

Two reasons make it a better target than your login page. First, amplified password guessing: XML-RPC supports a method called system.multicall, which lets one request carry many commands. A script can pack hundreds of username-and-password guesses into a single POST, so your server does hundreds of times the work for each request that reaches it, and simple attempt counters see one attempt instead of hundreds. Second, pingback abuse: the pingback feature can be told to fetch another website, which lets attackers use thousands of innocent WordPress sites as amplifiers in attacks on someone else. Your server pays the bill either way.

Do I still need it?

Ask what talks to your site from outside. If you use the WordPress mobile app, Jetpack, or a desktop publishing tool, those still speak XML-RPC. If you publish from the WordPress admin like most owners, nothing you rely on touches the file. Not sure? Watch before you block: in Cloudflare, open Security → Events, filter the URI path for xmlrpc.php, and look at who is calling it for a few days.

How do I block it with Cloudflare?

In the dashboard: Security → WAF → Custom rules. Create a rule where the URI path equals /xmlrpc.php and set the action to Block, or Managed Challenge if you want Jetpack and similar services to keep working while automation is stopped. Custom rules are included on Cloudflare's free plan, and the rule takes effect in seconds. The block happens at the edge, before the request ever reaches your server, which is the whole point: with 1 in 2 web requests coming from bots in 2025, turning this traffic away early is real capacity handed back to your site.

What should I check afterwards?

Security Events: within hours you should see blocked or challenged requests piling up on /xmlrpc.php, each one work your server no longer does.
Your own tools: post from the mobile app or check Jetpack once, if you use them. If something broke, switch the rule to Managed Challenge.
The login page next: the same attackers that abuse xmlrpc also hammer wp-login.php. Our brute-force guide closes that door with the same free toolbox.

One file down. The book closes the rest.

The ebook Cloudflare for Website Owners covers the full toolbox behind this fix: custom rules, rate limiting, bot filtering, and a dedicated case-study chapter that hardens a WordPress site end to end, with real dashboard screenshots at every step. See the WordPress edition of the pitch or the full overview.

Sources: Cloudflare Radar 2025 Year in Review (roughly 1 in 2 web requests from bots). Figures rounded. Cloudflare is a trademark of Cloudflare, Inc.; this guide is by 8grams and is not affiliated with Cloudflare, Inc.