--- title: Should you disable XML-RPC in WordPress? description: Should you disable XML-RPC in WordPress? Most sites never use it, but Jetpack and some publishing tools do — the honest, both-ways answer. pubDate: 2026-08-08 source: https://wpproadmin.com/guides/disable-xmlrpc-wordpress/ --- If you've ever tailed your server's access log and found a wall of POST requests to `/xmlrpc.php`, you already know why this question keeps coming up: should you disable XML-RPC in WordPress? The honest answer depends on what else runs on your site, and it splits cleanly into two groups. For most sites, XML-RPC is dead weight that bots probe constantly and nothing legitimate ever calls. For a smaller group, it's load-bearing, and switching it off breaks something you use every week. ## What XML-RPC actually is XML-RPC is a remote-procedure-call protocol — a way for an outside application to call functions on your WordPress site over HTTP, packaging the request and response as XML. WordPress has shipped an XML-RPC endpoint at `/xmlrpc.php` since the 2008-era 2.x releases, well before the REST API existed. It's how the original WordPress mobile apps published posts, how desktop blogging clients like MarsEdit and Windows Live Writer talked to a site, and how one WordPress site tells another it linked to it — a pingback. For most of WordPress's life, XML-RPC was the only remote API there was. The REST API arrived properly in WordPress 4.7 and covers the same ground with JSON and modern authentication. Every actively maintained integration has had roughly a decade to move to it. XML-RPC didn't go away — the endpoint still answers requests today, mostly for backward compatibility, whether or not anything on your site still uses it. ## Who still needs XML-RPC A few things genuinely depend on it, and if any of them apply to you, this isn't a should-you question anymore: - **Jetpack.** Jetpack's connection to WordPress.com has historically run over XML-RPC for at least part of its handshake and sync traffic. Turning the protocol off can break the connection depending on your Jetpack version and which modules are active. - **The WordPress mobile app's legacy connection mode.** Modern versions of the app use the REST API, but older setups and some self-hosted configurations still fall back to XML-RPC for publishing. - **Remote-publishing tools.** Desktop and third-party clients that never migrated off `wp.newPost` and friends — some still exist, mostly in blogging workflows that predate the REST API. - **Pingbacks.** If you rely on WordPress's automatic pingback notifications between sites, that mechanism is built on XML-RPC's `pingback.ping` method. If you use any of these, don't disable XML-RPC — or at least don't block it completely. If none of them apply, which is true for most WooCommerce stores, brochure sites, and blogs that publish only through wp-admin, you're in the group where closing it is a straightforward win. ## Why bots probe xmlrpc.php nonstop The traffic isn't random curiosity. Two specific things about XML-RPC make it worth a bot's time. The first is `system.multicall`, a method built into the XML-RPC spec that lets a client bundle many method calls into a single HTTP request and get all the results back at once. It exists for efficiency — a legitimate client can batch several small operations instead of making several round trips. Attackers use it to batch credential guesses: one HTTP request can carry hundreds of `wp.getUsersBlogs` calls, each with a different username/password pair, and the server processes all of them and returns all the results in one response. That turns a normal brute-force attempt, which usually gets slowed down by rate limits on individual login requests, into a handful of large requests trying thousands of combinations. It's the same guessing attack our [guide on stopping spam user registration](/guides/stop-spam-user-registration-wordpress/) touches on — XML-RPC doesn't create the accounts bots are after, it's just a faster way to test the ones that already exist. The second is pingback abuse. A pingback works by asking your site to fetch a URL and confirm the link — which means `pingback.ping` can be used to make your server issue an outbound HTTP request to an address the attacker chooses. Point enough compromised WordPress sites at the same target with that method and you have a distributed reflection attack, with every request appearing to come from an unrelated, otherwise-legitimate WordPress install. Neither of these needs your site to be interesting. Bots that scan for `xmlrpc.php` don't know or care what's on it — the endpoint's mere presence is the target. ## The honest answer: should you disable XML-RPC in WordPress If you're not running Jetpack, don't rely on a legacy publishing client, and don't need pingbacks, XML-RPC is a feature you never asked for that's permanently exposed to the internet. Closing it doesn't add anything to your site. It removes a surface that gets probed automatically, on every WordPress install, all day, whether or not it's ever led to a successful compromise on yours specifically. That's the case for disabling it. It is not a case for panic — an unpatched XML-RPC endpoint on an up-to-date WordPress install isn't itself a known open door — it's a case for removing noise and one avenue of amplified guessing. ## Manual method one: the xmlrpc_enabled filter The advice you'll see most often is a one-line snippet for your theme's `functions.php` or a site-specific plugin: ```php add_filter( 'xmlrpc_enabled', '__return_false' ); ``` This is real, and it does something — but not what most articles imply. WordPress core checks this filter inside the XML-RPC server's authentication step. When it returns false, any method that requires a login (posting, editing, `system.multicall` calls that need credentials) gets rejected. What it does *not* do is turn off the endpoint. Unauthenticated methods — including `system.listMethods`, which just lists what's available, and `pingback.ping` — still respond normally. A bot hitting `/xmlrpc.php` after this filter is active still gets an HTTP 200 and a valid XML-RPC response; it just can't authenticate. If your goal is reducing what shows up in your logs as suspicious traffic, this filter alone won't do it — the requests keep coming and keep getting answered, just without success. ## Manual method two: blocking xmlrpc.php at the server The complete version of "disable it" happens outside WordPress, at the web server. In Nginx: ```nginx location = /xmlrpc.php { deny all; } ``` Or in an Apache `.htaccess` file: ```apache Require all denied ``` This kills the file entirely — every method, authenticated or not, returns a 403 before WordPress ever loads. It's the version that actually removes the endpoint from view rather than just locking its front door. The trade-off is that it's total: pingbacks stop working too, since they route through the same file, and Jetpack's XML-RPC-dependent traffic breaks along with everything else. In 2026, losing pingbacks is a small loss for most sites — the feature has been a minor part of WordPress for years, mostly superseded by manual linking and social sharing — but it's worth knowing it's part of the trade, not a side effect you'll discover later. ## The shortcut Disable XML-RPC is one of the six locks in WP Pro Admin, live now in the 2.x releases. It's a single toggle, and switching it on blocks the endpoint the same way the server-level rule above does — completely, not just the authenticated methods — without touching an Nginx config or a `.htaccess` file you might not have access to on managed hosting. Turn it off and `/xmlrpc.php` answers requests again immediately — nothing about the change is written anywhere that outlives the toggle, so there's no cleanup if you turn on Jetpack next month and need it back. It's a [free download](/), GPL, not yet on wordpress.org, and it will never show you an ad, an upgrade nag, or a promotional notice while you use it — a promise enforced by [an automated test in the build](/no-ads/), not a paragraph on a website.