XML-RPC in WordPress, explained

XML-RPC is one of WordPress’s oldest remote communication interfaces.

It allows software outside the WordPress dashboard to send structured requests to a WordPress installation and ask it to perform supported operations such as publishing posts, editing content, retrieving information, managing comments or processing pingbacks.

The interface is normally exposed through:

https://example.com/xmlrpc.php

Unlike a normal webpage, xmlrpc.php is not intended for somebody to open in a browser and interact with visually.

It is an application endpoint.

A remote client sends an HTTP request containing XML that specifies a method and its parameters. WordPress parses that request, determines which XML-RPC method was requested, performs authentication and capability checks where necessary, executes the corresponding operation and returns an XML response.

WordPress has supported XML-RPC for many years, and the official wp_xmlrpc_server documentation confirms that it remains part of WordPress core and has been enabled by default since WordPress 3.5.

XML-RPC is frequently discussed only as a security problem, but that description is incomplete.

It is a legitimate remote API that became less central as newer technologies such as the WordPress REST API became available. Some applications and integrations can still depend on it.

Understanding XML-RPC therefore requires separating three questions:

• what the protocol actually does;
• which WordPress functionality uses it;
• whether a particular website still needs it.

This guide explains how XML-RPC works in WordPress, what xmlrpc.php does, which APIs and methods WordPress exposes, how authentication works, how pingbacks fit into the system, how XML-RPC differs from the REST API and why the endpoint is frequently targeted by automated attacks.

What is XML-RPC?

XML-RPC stands for XML Remote Procedure Call.

The basic idea is straightforward.

One computer sends a structured request to another computer asking it to execute a specific procedure.

XML is used to describe:

• the method being requested;
• the parameters supplied to that method;
• the result returned by the server;
• errors produced during execution.

Communication normally happens over HTTP.

A simplified architecture looks like:

External application
        ↓
HTTP request
        ↓
XML payload
        ↓
xmlrpc.php
        ↓
WordPress XML-RPC server
        ↓
requested method
        ↓
authentication / permissions
        ↓
WordPress operation
        ↓
XML response

The remote application does not need to load wp-admin or reproduce the normal WordPress user interface.

It communicates directly with the server-side API.

Where is XML-RPC located in WordPress?

A standard WordPress installation exposes the XML-RPC entry point through:

/xmlrpc.php

For a site installed at:

https://example.com/

the endpoint is normally:

https://example.com/xmlrpc.php

If WordPress itself is installed in a subdirectory, the endpoint follows that installation path.

The historical WordPress XML-RPC documentation describes this endpoint and the remote publishing APIs WordPress supports.

What happens if you open xmlrpc.php in a browser?

Opening:

https://example.com/xmlrpc.php

with a normal browser request does not represent a valid XML-RPC API call.

The endpoint expects specially formatted requests, normally sent using HTTP POST.

A browser visit may therefore return a simple message or another response indicating that XML-RPC communication requires a POST request.

This does not mean the endpoint is broken.

It means you are talking to an API as though it were a webpage.

What does an XML-RPC request look like?

An XML-RPC client sends XML describing the method it wants WordPress to execute.

A simplified request might conceptually resemble:

<methodCall>
    <methodName>wp.getUsersBlogs</methodName>
    <params>
        ...
    </params>
</methodCall>

The actual parameters depend on the method.

WordPress then:

1. receives the request through xmlrpc.php;
2. parses the XML;
3. identifies the method name;
4. locates the corresponding server method;
5. validates parameters;
6. authenticates the user when required;
7. checks the user’s WordPress capabilities;
8. executes the operation;
9. returns an XML-RPC response.

The WordPress XML-RPC server

The main WordPress implementation is represented by the wp_xmlrpc_server class.

The official WordPress code reference describes it as the WordPress XML-RPC server implementation.

The class supports WordPress-specific methods as well as compatibility with historical blogging APIs.

The server can handle functionality related to:

• posts;
• pages;
• comments;
• media;
• users;
• taxonomies;
• site options;
• pingbacks;
• historical remote-publishing APIs.

Which APIs does WordPress XML-RPC support?

WordPress’s implementation has accumulated compatibility with several API families.

The core documentation lists support for:

• the WordPress API;
• Blogger API compatibility;
• MetaWeblog API compatibility;
• Movable Type API compatibility;
• the Pingback API.

This reflects XML-RPC’s history.

WordPress had to communicate with blogging applications long before today’s JSON REST APIs became the normal architecture for web applications.

The WordPress XML-RPC API

Modern XML-RPC clients designed specifically for WordPress can use methods prefixed with:

wp.

Examples registered by the WordPress XML-RPC server include methods such as:

wp.getUsersBlogs
wp.newPost
wp.editPost
wp.deletePost

Additional WordPress methods exist for retrieving and managing other content and site information.

The exact methods exposed by the server are registered when wp_xmlrpc_server is constructed.

The official wp_xmlrpc_server constructor documentation shows how WordPress registers these method names.

XML-RPC methods can be extended by plugins

The list of available methods is not necessarily limited to WordPress core.

WordPress passes the registered method array through:

xmlrpc_methods

This filter allows plugins to:

• add XML-RPC methods;
• remove existing methods;
• replace method callbacks;
• modify the externally available API surface.

A WordPress site’s XML-RPC capabilities can therefore depend on its installed plugins as well as core.

What can XML-RPC be used for?

Historically, XML-RPC allowed applications to manage WordPress without requiring users to work directly inside the browser-based dashboard.

Possible workflows include:

• creating posts remotely;
• editing existing posts;
• publishing drafts;
• uploading media;
• retrieving content;
• managing comments;
• retrieving categories and taxonomies;
• working with selected site settings;
• processing pingbacks.

Remote publishing was one of XML-RPC’s primary use cases

Before browser-based editors became as capable as they are today, desktop blogging clients were common.

A writer could install a publishing application on their computer, connect it to WordPress and write posts without opening the WordPress administration area.

The client could then communicate with:

xmlrpc.php

to publish or edit the content remotely.

From the user’s perspective:

Desktop publishing app
        ↓
WordPress credentials
        ↓
XML-RPC
        ↓
WordPress site
        ↓
Post published

This architecture explains why XML-RPC became deeply integrated with WordPress even though many modern websites never use it directly.

Why is XML-RPC still included in WordPress?

Compatibility.

WordPress has an enormous ecosystem, and completely removing a long-standing interface could break applications and integrations that still depend on it.

The existence of a newer API does not automatically mean every older integration has migrated.

XML-RPC therefore remains available largely because WordPress values backward compatibility.

XML-RPC has been enabled by default since WordPress 3.5

Older WordPress versions exposed an administration setting that allowed users to enable or disable remote publishing.

That changed in WordPress 3.5.

The current wp_xmlrpc_server documentation confirms that XML-RPC has been enabled by default since WordPress 3.5.

The historical interface option disappeared, and the API became generally available unless code, a plugin, server configuration or another security layer restricts it.

How XML-RPC authentication works

Many XML-RPC methods perform operations that should obviously not be available to anonymous visitors.

For example, an anonymous user should not be able to call:

wp.newPost

and publish arbitrary content.

Authenticated XML-RPC methods therefore require WordPress credentials and then apply WordPress’s normal authorization model.

The server must determine:

• which WordPress user is making the request;
• whether the supplied credentials are valid;
• whether that user has the capability required for the requested operation.

Authentication and authorization are different

These two concepts should not be collapsed into one step.

Authentication

Authentication answers:

Who is making this request?

Authorization

Authorization answers:

Is this user allowed to perform this operation?

A valid Subscriber account should not automatically gain the ability to perform administrator-level XML-RPC operations merely because its password is correct.

WordPress capabilities still matter.

Not every XML-RPC method requires authentication

This is one of the most important details when understanding WordPress XML-RPC.

Some methods do not require an authenticated WordPress user.

Pingback functionality is the most important example.

This distinction becomes critical when administrators attempt to “disable XML-RPC” using the common:

add_filter( 'xmlrpc_enabled', '__return_false' );

The name of that filter is misleading if interpreted literally.

What xmlrpc_enabled actually disables

The official xmlrpc_enabled documentation explicitly states that this filter controls XML-RPC methods that require authentication.

It does not fully disable the entire XML-RPC system.

WordPress specifically notes that the filter does not control pingbacks or custom XML-RPC methods that do not require authentication.

Therefore:

add_filter( 'xmlrpc_enabled', '__return_false' );

should be understood as:

Disable authenticated XML-RPC methods

not:

Completely remove xmlrpc.php and every possible XML-RPC method

Why the xmlrpc_enabled name is confusing

The behavior exists partly for backward compatibility with the older WordPress setting that controlled XML-RPC publishing functionality.

As the current WordPress documentation explains, the filter’s name sounds broader than its actual scope.

This creates one of the most common XML-RPC configuration mistakes.

An administrator may apply:

xmlrpc_enabled = false

and assume:

• xmlrpc.php is inaccessible;
• pingbacks are impossible;
• all custom XML-RPC methods are disabled;
• no XML-RPC attack surface remains.

Those assumptions are not guaranteed by that filter alone.

XML-RPC and pingbacks

Pingbacks are part of WordPress’s XML-RPC implementation.

A pingback allows one website to notify another that it has linked to a page.

WordPress registers methods including:

pingback.ping
pingback.extensions.getPingbacks

The official XML-RPC server method registration includes both.

How pingback.ping works

The pingback.ping method accepts information describing:

• the URL containing the link;
• the URL that was linked to.

The receiving WordPress site then performs processing to determine whether the pingback is valid.

The current pingback_ping() implementation can retrieve the remote source page and verify that the claimed link exists before registering the pingback.

The simplified process is:

Site A links to Site B
        ↓
pingback notification
        ↓
Site B receives XML-RPC request
        ↓
Site B retrieves source page
        ↓
checks for link
        ↓
valid pingback
        ↓
pingback stored

For the broader publishing behavior, see Pingbacks, Trackbacks & Internal Links.

What are self-pingbacks?

A self-pingback occurs when a WordPress site processes a link from one of its own posts to another URL on the same site.

The website can effectively notify itself that it linked to itself.

The internal link may be valuable.

The resulting notification usually is not.

That distinction is covered in WordPress Self-Pingbacks Explained.

If the only requirement is eliminating same-site pingback noise, disabling XML-RPC entirely may be unnecessarily broad.

See Disable Self-Pingbacks Without Disabling XML-RPC.

XML-RPC and trackbacks are not exactly the same thing

Pingbacks and trackbacks are often discussed together because both belong to WordPress’s historical distributed-blogging workflow.

However, they are different mechanisms.

Pingbacks use an automated notification and verification process involving XML-RPC.

Trackbacks are an older mechanism where a trackback endpoint is explicitly notified.

Disabling one part of this ecosystem should not automatically be described as disabling every possible link-notification behavior.

What is system.multicall?

XML-RPC implementations can support a mechanism known as system.multicall.

Its purpose is efficiency.

Instead of sending:

Request 1
Request 2
Request 3
Request 4

separately, a client can package multiple method calls into a single XML-RPC request.

Conceptually:

One HTTP request
        ↓
multiple XML-RPC calls
        ↓
multiple operations processed

This can be useful for legitimate clients because it reduces HTTP overhead.

It also matters from a security perspective because one HTTP request can represent more than one internal XML-RPC operation.

Why XML-RPC appears in brute-force discussions

WordPress administrators usually associate brute-force attacks with:

/wp-login.php

but XML-RPC can provide another authentication surface.

If an XML-RPC method accepts WordPress credentials, an attacker can attempt to submit credentials through that API instead of the normal login form.

The attacker’s goal remains the same:

username
+
password
↓
valid account access

Only the endpoint changes.

This matters because protecting the visible login page does not necessarily protect every authentication interface.

See WordPress Brute-Force Attacks, Explained for the broader threat model.

XML-RPC brute-force attempts can consume resources even when they fail

An attacker does not need to discover the correct password to create server work.

An XML-RPC request may require:

• web-server processing;
• PHP execution;
• WordPress bootstrap;
• XML parsing;
• method routing;
• authentication logic;
• database access;
• plugin and security processing.

A large volume of failed requests can therefore consume resources even when no account is compromised.

This is why rate limiting and infrastructure-level controls can matter in addition to password security.

XML-RPC and application-level login protection

A login security plugin may protect:

/wp-login.php

without automatically applying the same controls to:

/xmlrpc.php

That depends entirely on the implementation.

Administrators should verify whether:

• rate limiting covers XML-RPC;
• failed authentication is logged;
• WAF rules inspect XML-RPC traffic;
• IP restrictions include the endpoint;
• two-factor authentication affects remote authentication workflows.

Do not assume a protected login form automatically means every WordPress authentication surface has equivalent protection.

XML-RPC pingbacks introduce another type of externally triggered behavior

Pingbacks do not primarily create an authentication problem.

They create a different concern.

A remote request can cause the receiving WordPress site to retrieve another URL to verify that a link exists.

This means the feature can trigger server-to-server HTTP activity.

Historically, pingback functionality has therefore appeared in discussions about:

• unwanted outbound requests;
• traffic amplification;
• distributed request abuse;
• server resource consumption.

This does not mean every enabled pingback is automatically a vulnerability.

It means the feature exposes externally triggerable behavior that should have a legitimate reason to remain available.

XML-RPC is not inherently malware

Calling XML-RPC “malicious” is technically inaccurate.

It is an API.

The same interface can be used by:

• a legitimate remote publishing client;
• a management service;
• a plugin integration;
• an attacker testing stolen passwords;
• an automated scanner.

The security question is not whether XML-RPC itself has moral intentions, which would be an impressive burden to place on a PHP file.

The relevant questions are:

• does the website need the functionality?
• which methods are exposed?
• how is authentication protected?
• how much abusive traffic reaches the endpoint?

XML-RPC vs. the WordPress REST API

WordPress now provides a modern REST API in addition to XML-RPC.

The REST API is commonly available under:

https://example.com/wp-json/

Both interfaces allow external software to communicate with WordPress.

They should not be treated as interchangeable implementations.

XML-RPC

XML-RPC:

• uses XML-formatted remote procedure calls;
• typically communicates through xmlrpc.php;
• has been part of WordPress for many years;
• supports historical remote-publishing APIs;
• includes pingback methods;
• may remain necessary for legacy services.

REST API

The WordPress REST API:

• uses normal HTTP endpoints;
• primarily exchanges JSON;
• is designed around resources and routes;
• is extensively used by modern WordPress functionality;
• supports routes registered by WordPress and plugins;
• plays an important role in the Block Editor and modern integrations.

For the security model of the newer interface, see WordPress REST API Security Basics.

Disabling XML-RPC does not disable the REST API

The two interfaces operate independently.

Blocking:

/xmlrpc.php

does not automatically block:

/wp-json/

Likewise, restricting REST API requests does not inherently disable XML-RPC.

This distinction becomes important when hardening WordPress.

A website can legitimately choose:

XML-RPC disabled
REST API enabled

which is a common configuration for modern WordPress sites.

Do not disable the REST API merely because XML-RPC is unnecessary

The REST API is much more deeply integrated into modern WordPress than XML-RPC is on many installations.

The Block Editor and many plugins depend on REST functionality.

A blanket REST shutdown can therefore break normal administration and frontend features.

If the concern is controlling public REST exposure, first understand What Depends on the WordPress REST API before making a broad change.

XML-RPC vs. Application Passwords

Application Passwords are WordPress credentials intended for programmatic access by external applications.

They solve a different problem from the communication protocol itself.

Conceptually:

XML-RPC / REST API
= communication interfaces

Application Password
= credential used by an application

A secure integration architecture needs to consider both:

• which API the application communicates with;
• how that application authenticates.

Replacing an older remote workflow may therefore involve reviewing both the API and the authentication mechanism.

Does Jetpack use XML-RPC?

Jetpack has historically been one of the most important examples mentioned when administrators consider disabling XML-RPC.

Depending on the service and current integration architecture, WordPress.com-connected functionality can require remote communication that administrators should not blindly block.

The larger lesson is more important than any single plugin:

never disable a remote interface on a production website before checking whether a legitimate service depends on it.

What else might depend on XML-RPC?

Potential dependencies include:

• legacy desktop publishing applications;
• mobile publishing clients;
• remote site-management tools;
• WordPress.com-connected services;
• custom integrations;
• older automation systems;
• plugins that explicitly register XML-RPC functionality.

Many modern websites use none of these.

That should be verified rather than assumed.

How to determine whether XML-RPC is enabled

Start with the endpoint:

https://example.com/xmlrpc.php

A response from the file confirms that the route itself is reachable, but it does not automatically prove every XML-RPC method is available.

This distinction matters.

Possible configurations include:

• endpoint reachable and authenticated methods available;
• endpoint reachable but authenticated methods disabled;
• selected methods removed;
• pingbacks removed but other methods available;
• endpoint blocked completely.

A simple browser visit cannot distinguish every configuration.

How to inspect XML-RPC traffic

Web-server, CDN and WAF logs can provide more useful evidence.

Search for requests to:

/xmlrpc.php

Then review:

• request volume;
• HTTP methods;
• source IP addresses;
• response codes;
• request frequency;
• known legitimate service addresses;
• repeated authentication attempts;
• sudden traffic spikes.

Large amounts of XML-RPC traffic do not automatically mean the site uses XML-RPC legitimately.

Public WordPress endpoints are continuously scanned by automated systems.

How to determine whether a legitimate integration uses XML-RPC

Traffic alone is insufficient.

Review the site’s actual operational dependencies.

Check installed plugins

Search documentation for explicit references to:

XML-RPC
xmlrpc.php
remote publishing

Check external services

Review:

• site-management dashboards;
• mobile applications;
• publishing tools;
• automation platforms;
• monitoring systems.

Ask what happens outside wp-admin

If nobody publishes, edits or manages WordPress remotely, XML-RPC is less likely to be required.

Test on staging

When dependencies are unclear, restriction should be tested before production rollout.

A staging-first workflow avoids discovering a hidden dependency after an integration has already stopped working.

How plugins can monitor XML-RPC calls

WordPress provides the:

xmlrpc_call

action for built-in XML-RPC methods.

The official xmlrpc_call documentation explains that the hook fires after authentication for relevant methods and before the rest of the method logic executes.

Developers and security tools can use XML-RPC-related hooks to:

• observe activity;
• apply additional policies;
• log operations;
• integrate security controls.

Can individual XML-RPC methods be disabled?

Yes.

Because WordPress exposes its method list through:

xmlrpc_methods

a developer can remove specific methods rather than disabling the entire interface.

Conceptually:

XML-RPC
├── publishing methods        keep
├── media methods             keep
├── pingback methods          remove
└── another custom method     keep

This can be useful where one integration still requires XML-RPC but unrelated functionality should not remain exposed.

Example: remove pingback methods only

A focused implementation can filter the method list:

add_filter(
    'xmlrpc_methods',
    function ( $methods ) {
        unset( $methods['pingback.ping'] );
        unset( $methods['pingback.extensions.getPingbacks'] );

        return $methods;
    }
);

This is different from:

add_filter( 'xmlrpc_enabled', '__return_false' );

and different again from blocking xmlrpc.php entirely.

Three different levels of XML-RPC restriction

It helps to think about WordPress XML-RPC controls in layers.

1. Disable authenticated methods

add_filter( 'xmlrpc_enabled', '__return_false' );

This disables methods requiring authentication.

2. Remove selected methods

Use:

xmlrpc_methods

to remove particular API methods.

3. Block xmlrpc.php completely

A complete application, server, proxy, CDN or WAF restriction can prevent requests from reaching the XML-RPC endpoint at all.

These approaches are not equivalent.

Application-level vs. server-level XML-RPC blocking

Where XML-RPC is blocked affects how much work the server performs.

WordPress-level restriction

A plugin or PHP snippet may allow the request to reach WordPress before rejecting it.

This can still involve:

• web-server processing;
• PHP;
• WordPress bootstrap;
• plugin loading.

Web-server or edge restriction

Nginx, Apache, a CDN or WAF can potentially reject a request before WordPress is fully loaded.

This can be more efficient against heavy automated traffic.

However, infrastructure-level blocking requires appropriate server access and must still preserve any legitimate integrations.

Should xmlrpc.php return 403 or 404 when blocked?

There is no universal answer appropriate for every infrastructure design.

A 403 Forbidden clearly communicates that the server understood the request but refuses access.

A 404 Not Found can reduce obvious endpoint exposure and is often used by hardening tools.

The more important requirements are:

• the unwanted operation is actually blocked;
• legitimate dependencies remain functional;
• the response is consistent;
• the block occurs at an appropriate layer.

Does hiding the RSD link disable XML-RPC?

No.

WordPress can advertise remote publishing capabilities using an RSD discovery link in the document head.

Removing that discovery element only hides one advertisement.

It does not make:

/xmlrpc.php

unavailable.

This follows the same architecture seen with RSS feeds, REST discovery and shortlinks:

remove discovery
≠
disable functionality

Does removing XML-RPC discovery improve security?

Only marginally as an information-exposure cleanup.

An attacker does not need an RSD element to know that WordPress commonly exposes:

/xmlrpc.php

Automated scanners can test that path directly.

If XML-RPC presents an unwanted security surface, the meaningful control is restricting or disabling the functionality itself.

Does XML-RPC reveal that a site uses WordPress?

A recognizable response from:

/xmlrpc.php

can contribute to WordPress fingerprinting.

It is only one of many signals.

Other clues can include:

• /wp-content/ assets;
• /wp-includes/ assets;
• REST API behavior;
• login routes;
• generator information;
• theme files;
• plugin assets.

See How Attackers Fingerprint WordPress Sites for the broader reconnaissance process.

Does disabling XML-RPC hide WordPress?

No.

Blocking one recognizable endpoint can remove one fingerprinting signal, but WordPress can usually still be identified through many others.

Security should not rely on keeping the CMS name secret.

More important controls include:

• keeping software updated;
• using strong authentication;
• restricting unnecessary interfaces;
• rate limiting abusive requests;
• monitoring suspicious activity;
• maintaining recoverable backups.

Does XML-RPC affect SEO?

XML-RPC itself is not an SEO feature.

Disabling it does not directly improve rankings.

Keeping it enabled does not directly help rankings either.

Possible indirect effects would come from operational consequences, such as:

• server load caused by abusive traffic;
• site compromise following successful credential attacks;
• spam or malicious content after account takeover.

Those are security and availability issues rather than normal SEO signals.

Does XML-RPC affect website performance?

The existence of xmlrpc.php does not meaningfully slow normal frontend page views by itself.

If nobody requests the endpoint, it does very little.

Performance becomes relevant when the endpoint receives substantial traffic.

For example:

100,000 abusive XML-RPC requests
≠
unused XML-RPC endpoint receiving zero traffic

The operational impact depends on actual request volume and how early unwanted traffic can be rejected.

How TheOneWP handles XML-RPC

TheOneWP includes a dedicated Disable XML-RPC module for sites that have confirmed they do not need the interface.

The objective is broader than merely applying the misleadingly named xmlrpc_enabled filter.

The module is designed for the configuration where the desired result is:

xmlrpc.php
↓
remote XML-RPC access blocked

rather than only:

authenticated XML-RPC publishing methods disabled

This is appropriate when no required plugin, publishing application or external service depends on XML-RPC.

Do not use complete XML-RPC disabling to solve a narrower problem

If the only problem is self-pingbacks, TheOneWP provides the separate Disable Self Pingbacks module.

That module filters same-site destinations from WordPress’s outgoing ping queue without disabling XML-RPC.

This is intentionally narrower.

The decision should therefore be:

No XML-RPC dependency
→ Disable XML-RPC

XML-RPC required, but self-pingbacks unwanted
→ Disable Self Pingbacks

Only selected XML-RPC behavior unwanted
→ apply a focused method-level restriction

How to audit XML-RPC before disabling it

Do not begin by adding a blocking rule.

Begin by discovering what the site actually uses.

Check the endpoint

Request:

/xmlrpc.php

and record its current behavior.

Check access logs

Search for:

POST /xmlrpc.php

and identify legitimate versus suspicious sources where possible.

Check publishing workflows

Determine whether anyone uses:

• mobile publishing;
• desktop publishing;
• remote editing;
• external site-management applications.

Check plugin documentation

Do not assume plugins are independent from XML-RPC merely because their user interface never mentions it.

Check WordPress.com-connected functionality

Review services such as Jetpack and any related remote-management workflow.

Check custom integrations

Custom code is the dependency most likely to be forgotten because there may be no public documentation describing it.

Test in staging

Apply the intended restriction and verify every remote workflow before production deployment.

How to test after disabling XML-RPC

A proper test should include more than opening the endpoint once.

Test xmlrpc.php directly

Confirm the endpoint returns the intended blocked response.

Test wp-admin

Normal administration should remain available.

Test the REST API

If REST API access is supposed to remain enabled, confirm:

/wp-json/

still behaves normally.

Test the Block Editor

XML-RPC shutdown should not be confused with REST API shutdown.

Normal editor functionality should remain intact unless another setting affects it.

Test integrations

Verify:

• Jetpack or equivalent services;
• mobile applications;
• publishing clients;
• monitoring tools;
• remote management;
• custom automations.

Inspect logs afterward

Confirm that unwanted traffic receives the expected response and that legitimate services are not repeatedly failing.

Common XML-RPC mistakes

Assuming xmlrpc_enabled disables everything

It controls authenticated methods, not every possible XML-RPC method.

Blocking XML-RPC without checking dependencies

This can break remote services silently.

Keeping XML-RPC because WordPress enables it by default

A default is not evidence that your particular website needs the feature.

Calling XML-RPC a vulnerability

The interface itself is legitimate.

Unused exposure and abusive traffic are the real configuration concerns.

Protecting wp-login.php and ignoring xmlrpc.php

If authenticated XML-RPC methods remain available, they represent another credential-processing surface.

Disabling the REST API together with XML-RPC without testing

The REST API has a much larger role in modern WordPress.

The two interfaces should be evaluated separately.

Disabling XML-RPC merely to stop self-pingbacks

A focused pre_ping filter can solve that narrower problem without shutting down the complete interface.

Assuming no visible traffic means no dependency

Some remote integrations run only occasionally.

Review the system architecture as well as recent logs.

Assuming blocking xmlrpc.php hides WordPress

WordPress remains detectable through many other signals.

Describing every XML-RPC request as an attack

Some requests are legitimate.

Use logs, dependency documentation and behavior to determine what the traffic represents.

XML-RPC in WordPress checklist

• Understand that XML-RPC is a remote API, not a normal webpage.
• Know that the standard endpoint is /xmlrpc.php.
• Understand that requests normally use XML over HTTP POST.
• Know that WordPress uses wp_xmlrpc_server to implement the API.
• Understand that WordPress supports its own XML-RPC methods.
• Remember that historical Blogger, MetaWeblog and Movable Type compatibility exists.
• Understand that pingbacks are part of WordPress XML-RPC functionality.
• Know that XML-RPC has been enabled by default since WordPress 3.5.
• Distinguish authenticated from unauthenticated methods.
• Do not assume xmlrpc_enabled disables the complete endpoint.
• Use xmlrpc_methods when method-level control is required.
• Understand that plugins can register additional XML-RPC methods.
• Review remote publishing dependencies.
• Review mobile application dependencies.
• Review WordPress.com and Jetpack-related workflows.
• Review remote site-management tools.
• Review custom integrations.
• Inspect access logs for requests to xmlrpc.php.
• Distinguish legitimate traffic from automated scanning.
• Protect XML-RPC authentication if authenticated methods remain available.
• Understand that login-page protection may not automatically cover XML-RPC.
• Review pingback functionality separately.
• Use self-pingback filtering when that is the only problem.
• Do not disable the REST API merely because XML-RPC is unnecessary.
• Understand that XML-RPC and REST are separate interfaces.
• Do not claim XML-RPC shutdown directly improves SEO.
• Do not claim an unused XML-RPC endpoint automatically harms performance.
• Test restrictions in staging when dependencies are uncertain.
• Test external services after changing XML-RPC access.
• Check server logs after deployment.
• Document any integration that requires XML-RPC to remain available.
• Completely disable XML-RPC only when the site genuinely does not need it.

Related guides

• What Is XML-RPC in WordPress, and Why Disable It?
• Pingbacks, Trackbacks & Internal Links
• Disable Self-Pingbacks Without Disabling XML-RPC
• WordPress Brute-Force Attacks, Explained
• WordPress REST API Security Basics

Final recommendation

XML-RPC is best understood as a legacy-compatible remote communication interface rather than simply an old WordPress feature that should always be removed.

It allows external software to communicate with WordPress through xmlrpc.php, execute registered methods and perform operations without using the normal administration interface.

That architecture remains legitimate.

The problem is that many modern WordPress websites no longer require it.

An interface that accepts remote requests, can process credentials, exposes extensible methods and supports pingbacks creates additional functionality that administrators have to monitor and protect.

If a site actively uses a remote publishing client, management service or another XML-RPC-dependent integration, keep the required interface available and protect it appropriately.

If only certain functionality is unnecessary, restrict that functionality narrowly.

For example, remove pingback methods when pingbacks are the concern, or filter self-pingbacks when internal notifications are the only problem.

If nothing depends on XML-RPC, completely disabling access to xmlrpc.php is a reasonable hardening decision because unused remotely accessible functionality provides no operational benefit.

Most importantly, understand the scope of the control you apply.

xmlrpc_enabled does not mean exactly what its name suggests. It disables authenticated XML-RPC methods, not necessarily every method or the endpoint itself.

Likewise, blocking XML-RPC does not disable the REST API, and it should not be used as an excuse to restrict modern WordPress APIs without understanding their dependencies.

The right XML-RPC policy is therefore not “always on” or “always off.”

It is simpler: identify what depends on the interface, expose only what the site actually needs, and completely close it when nothing legitimate uses it.