What is the RSD tag in WordPress?

The RSD tag in WordPress is a small discovery link placed inside the document <head> that points external applications toward WordPress’s Really Simple Discovery endpoint.

It commonly looks like this:

<link
    rel="EditURI"
    type="application/rsd+xml"
    title="RSD"
    href="https://example.com/xmlrpc.php?rsd"
/>

RSD stands for Really Simple Discovery.

Its original purpose was to help blogging clients and other remote applications discover which publishing APIs a website supports and where those APIs are located.

On WordPress, the RSD document is normally available through:

https://example.com/xmlrpc.php?rsd

The RSD tag therefore acts as a pointer:

Normal WordPress page
        ↓
RSD discovery link
        ↓
xmlrpc.php?rsd
        ↓
RSD document
        ↓
available remote APIs

The tag itself does not provide remote publishing functionality.

It only advertises where a compatible client can discover that functionality.

This distinction is important because removing the RSD tag does not automatically disable XML-RPC, pingbacks or the WordPress REST API.

This guide explains what the WordPress RSD tag is, how Really Simple Discovery works, why WordPress still outputs it, how it relates to XML-RPC and the REST API, whether modern websites still need it, and how to remove it safely.

What does RSD stand for?

RSD stands for:

Really Simple Discovery

It is an XML-based discovery format designed to allow software to determine which remote APIs a website supports.

Rather than forcing an application to know in advance that WordPress uses:

/xmlrpc.php

the application can first inspect the website’s HTML, locate the RSD discovery element, request the RSD document and then read the advertised API endpoints.

The WordPress REST API handbook still documents RSD as one of WordPress’s API discovery mechanisms, while describing it as a less-preferred method compared with modern REST discovery.

What does the WordPress RSD tag look like?

A normal WordPress page can contain:

<link
    rel="EditURI"
    type="application/rsd+xml"
    title="RSD"
    href="https://example.com/xmlrpc.php?rsd"
/>

Each part has a specific purpose.

rel=”EditURI”

The rel attribute identifies the link as a discovery location related to editing or remote publishing capabilities.

type=”application/rsd+xml”

This tells compatible clients that the destination is an RSD XML document.

title=”RSD”

The title identifies the discovery format.

href

The href points to the RSD endpoint:

https://example.com/xmlrpc.php?rsd

Which WordPress function outputs the RSD tag?

WordPress generates the discovery link through:

rsd_link()

The official WordPress rsd_link() documentation describes the function as displaying a link to the Really Simple Discovery service endpoint.

The function outputs an RSD URL based on the WordPress installation URL and:

xmlrpc.php?rsd

It is normally attached to WordPress’s wp_head action.

How does rsd_link() reach the page head?

WordPress themes normally call:

<?php wp_head(); ?>

inside their document head.

WordPress then executes callbacks registered on the:

wp_head

action.

rsd_link() is one of the core callbacks that can contribute markup there.

The result is approximately:

<head>

    ...

    <link
        rel="EditURI"
        type="application/rsd+xml"
        title="RSD"
        href="https://example.com/xmlrpc.php?rsd"
    />

    ...

</head>

This is why the RSD tag often appears when auditing WordPress Head Tags You Can Safely Remove.

What happens after a client discovers the RSD URL?

Finding the <link> element is only the first stage.

A compatible client can then request:

https://example.com/xmlrpc.php?rsd

WordPress responds with an XML document describing available remote APIs.

A simplified RSD document looks conceptually like:

<?xml version="1.0" encoding="utf-8"?>

<rsd version="1.0">
    <service>

        <engineName>WordPress</engineName>

        <homePageLink>
            https://example.com/
        </homePageLink>

        <apis>

            <api
                name="WordPress"
                apiLink="https://example.com/xmlrpc.php"
            />

        </apis>

    </service>
</rsd>

The actual WordPress response can advertise multiple APIs.

The RSD discovery process

The complete workflow can therefore be represented as:

1. Client receives a WordPress page

https://example.com/

        ↓

2. Client parses HTML

        ↓

3. Finds:

<link rel="EditURI"
      href="https://example.com/xmlrpc.php?rsd">

        ↓

4. Requests RSD document

https://example.com/xmlrpc.php?rsd

        ↓

5. Parses XML

        ↓

6. Finds supported API endpoints

        ↓

7. Connects to the appropriate API

This was particularly useful when remote blogging software needed to work with multiple publishing platforms.

Why was RSD useful?

Historically, remote publishing clients could connect to many different blogging systems.

A client could not necessarily assume that every site used:

/xmlrpc.php

or that every platform implemented the same API.

RSD created a discovery layer.

The client could ask:

What publishing system is this?

Which APIs does it support?

Where are those APIs located?

and receive structured answers.

RSD and XML-RPC

RSD is closely associated with WordPress XML-RPC.

The RSD endpoint itself is normally reached through:

xmlrpc.php?rsd

and the document can advertise WordPress’s XML-RPC API endpoint:

xmlrpc.php

However, RSD and XML-RPC are not the same feature.

RSD is:

discovery

XML-RPC is:

remote communication functionality

The relationship is:

RSD
↓
tells a client where XML-RPC is

XML-RPC
↓
actually processes remote API calls

For the underlying API architecture, see XML-RPC in WordPress, Explained.

Removing RSD does not disable XML-RPC

This is the most important practical distinction.

If you remove:

<link rel="EditURI" ...>

from the document head, the endpoint:

https://example.com/xmlrpc.php

can remain completely functional.

A remote client that already knows the XML-RPC URL does not need RSD discovery.

An automated scanner does not need it either.

Therefore:

Remove RSD tag
≠
disable XML-RPC

Removing RSD also does not disable pingbacks

WordPress pingbacks use XML-RPC functionality.

Removing the RSD discovery element does not remove methods such as:

pingback.ping

from the XML-RPC server.

If pingbacks are the actual concern, configure pingbacks specifically.

See Pingbacks, Trackbacks & Internal Links.

The RSD document can advertise more than XML-RPC

Modern WordPress adds an interesting compatibility layer to the old RSD system.

The current WordPress REST API discovery documentation shows an RSD response that can include both traditional WordPress XML-RPC information and a REST API entry such as:

<api
    name="WP-API"
    apiLink="https://example.com/wp-json/"
/>

This allows clients that already implement RSD discovery to learn about the newer WordPress REST API as well.

How does the REST API get into the RSD document?

WordPress provides:

rest_output_rsd()

which adds REST API information to the RSD endpoint.

The WordPress Developer Resources for get_rest_url() identify rest_output_rsd() as functionality that adds the REST API URL to the WordPress RSD endpoint.

This is an example of WordPress preserving an older discovery protocol while progressively exposing newer APIs through it.

RSD and REST API discovery are still different

Although RSD can advertise the REST API, WordPress also has more direct REST discovery methods.

Modern frontend pages can advertise REST API access through a link relationship associated with:

https://api.w.org/

WordPress can also expose REST discovery through HTTP headers.

The REST API Discovery documentation describes these methods and treats RSD as a less-preferred alternative for clients that already support XML-RPC discovery.

Why is RSD considered a legacy discovery mechanism?

RSD requires more work than modern alternatives.

The process is effectively:

Request HTML
↓
parse HTML
↓
find RSD link
↓
request RSD XML
↓
parse XML
↓
discover API

A direct REST discovery mechanism can avoid some of those steps.

The official WordPress REST API handbook explicitly notes that RSD-based discovery requires parsing both the page and an additional XML document.

For new REST clients, simpler discovery mechanisms are generally preferable.

Why does WordPress still support RSD?

WordPress places a very high value on backward compatibility.

Removing a discovery interface that older applications may still understand could unnecessarily break remote publishing workflows.

RSD therefore remains available even though most modern WordPress administrators never interact with it directly.

Its continued existence does not mean every website needs to advertise it.

Which applications historically used RSD?

RSD was useful to software capable of publishing remotely to blogging platforms.

Examples of the broader category included:

• desktop blogging clients;
• remote publishing applications;
• blog-management tools;
• software supporting MetaWeblog-style APIs;
• XML-RPC clients.

Rather than forcing the user to provide exact API paths, the client could discover them.

Is RSD required for WordPress itself?

For normal WordPress operation, generally no.

The RSD tag is not required for:

• loading pages;
• logging into WordPress;
• using wp-admin;
• rendering posts;
• rendering pages;
• using menus;
• loading themes;
• loading plugins;
• normal SEO indexing;
• normal permalink routing.

Its purpose is remote API discovery.

Is RSD required for XML-RPC?

No.

A client can connect directly to:

https://example.com/xmlrpc.php

if it already knows the endpoint.

RSD simply provides a standardized method for discovering it.

Is RSD required for the REST API?

No.

The WordPress REST API remains available independently at URLs based around:

/wp-json/

assuming the API has not otherwise been restricted.

WordPress has separate REST discovery mechanisms.

Removing RSD therefore does not disable or inherently break the REST API.

See How WordPress Advertises Its REST API.

Is RSD required for the Block Editor?

No.

The modern Block Editor relies heavily on the REST API, not on RSD discovery as a normal requirement for editing content inside WordPress.

Removing the RSD tag should therefore not be confused with restricting the REST API.

Is RSD required for SEO?

No.

Search engines do not require WordPress’s RSD discovery element in order to:

• crawl pages;
• index posts;
• understand canonical URLs;
• read robots directives;
• process XML sitemaps;
• follow internal links.

Removing RSD should therefore be SEO-neutral in ordinary circumstances.

Does the RSD tag affect page performance?

The performance impact of the RSD tag itself is negligible.

It is a small line of HTML.

Removing:

<link rel="EditURI" ...>

does not materially improve:

• Largest Contentful Paint;
• Interaction to Next Paint;
• server response time;
• JavaScript execution;
• image loading.

RSD removal should therefore be described as markup and discovery cleanup, not as meaningful performance optimization.

Is the RSD tag a security vulnerability?

No.

The tag itself is not an exploitable vulnerability.

It advertises information about remote API discovery.

That information can make certain WordPress interfaces easier to identify, but removing the tag does not secure those interfaces.

An attacker can directly request predictable WordPress routes such as:

/xmlrpc.php

without first reading RSD metadata.

Does RSD contribute to WordPress fingerprinting?

Yes, as one small signal.

An RSD tag containing:

xmlrpc.php?rsd

strongly suggests WordPress or another system implementing a compatible publishing architecture.

The RSD response can also include information identifying the engine.

However, removing RSD does not meaningfully make WordPress invisible.

Other signals can include:

• /wp-content/ paths;
• /wp-includes/ assets;
• REST API behavior;
• XML-RPC responses;
• login URLs;
• theme files;
• plugin assets;
• WordPress-generated markup.

See How Attackers Fingerprint WordPress Sites.

Why remove the RSD tag if it is not dangerous?

Because not every exposed discovery mechanism needs to remain present simply because it is harmless.

If a website does not use clients that depend on RSD, removing the tag can:

• reduce unnecessary document-head markup;
• remove an unused legacy discovery signal;
• make site behavior more intentional;
• slightly reduce passive WordPress fingerprinting information.

The benefits are modest, but the compatibility cost is also usually modest on sites with no RSD-dependent integrations.

When should you keep the RSD tag?

Keep it when you have a known client or integration that relies on Really Simple Discovery.

Potential situations include:

• legacy remote-publishing software;
• custom XML-RPC clients;
• older blog-management applications;
• special integrations explicitly using RSD discovery.

If you do not know whether something depends on it, check the site’s integrations before removing it from a business-critical installation.

How to remove the RSD tag in WordPress

WordPress registers the RSD output through its hook system, so it can be removed without editing WordPress core.

The standard removal is:

remove_action( 'wp_head', 'rsd_link' );

A more structured implementation can run after theme setup:

add_action(
    'after_setup_theme',
    function () {
        remove_action( 'wp_head', 'rsd_link' );
    }
);

This prevents rsd_link() from printing the discovery tag through wp_head.

What exactly does that code remove?

It removes markup similar to:

<link
    rel="EditURI"
    type="application/rsd+xml"
    title="RSD"
    href="https://example.com/xmlrpc.php?rsd"
/>

from frontend pages where the callback would otherwise run.

It does not necessarily remove:

• /xmlrpc.php;
• /xmlrpc.php?rsd server handling;
• XML-RPC methods;
• pingbacks;
• REST API endpoints;
• REST API discovery;
• remote functionality registered elsewhere.

Why not edit WordPress core?

The RSD callback is intentionally registered through WordPress’s hook system.

The correct customization mechanism is therefore:

remove_action()

The official remove_action() documentation explains how callbacks registered on WordPress actions can be detached.

Editing:

wp-includes/general-template.php

or:

wp-includes/default-filters.php

would create a core modification that can be overwritten during updates.

Should you remove xmlrpc.php?rsd as well?

This depends on what you are trying to achieve.

If the objective is:

clean the document head

then removing the RSD discovery tag is enough.

If the objective is:

completely eliminate XML-RPC-related functionality

then removing the discovery tag is not enough.

You need to review the actual XML-RPC endpoint and its methods separately.

This is the same architectural distinction seen throughout WordPress:

Discovery layer
≠
functionality layer

Does blocking XML-RPC automatically remove RSD?

Not necessarily.

Suppose a security system blocks:

/xmlrpc.php

at the web-server or WAF layer.

If rsd_link() is still attached to wp_head, WordPress can continue printing:

<link
    rel="EditURI"
    href="https://example.com/xmlrpc.php?rsd"
/>

even though the destination is blocked.

That creates inconsistent discovery metadata.

If XML-RPC is intentionally unavailable, it is usually reasonable to remove the RSD advertisement too.

Does disabling authenticated XML-RPC methods remove RSD?

No.

The commonly used:

add_filter( 'xmlrpc_enabled', '__return_false' );

controls authenticated XML-RPC methods.

As the official xmlrpc_enabled documentation explains, it is not a complete XML-RPC shutdown.

It also does not inherently detach:

rsd_link()

from:

wp_head

These are separate controls.

RSD and WordPress Site Health

RSD has an interesting internal use beyond traditional remote publishing.

Current WordPress core contains functionality that can inspect HTML and use the site’s RSD link as one possible indicator that the returned HTML came from the local WordPress installation.

The official wp_is_local_html_output() source checks for the site’s Really Simple Discovery link when rsd_link is registered.

If that callback is unavailable, WordPress can fall back to checking REST API discovery output.

This is an important example of why modern WordPress behavior should be checked against current core rather than assuming RSD is completely disconnected from internal functionality simply because the protocol itself is old.

Does that mean you should never remove RSD?

No.

WordPress core already accounts for the possibility that the RSD callback is unavailable in that particular detection path.

The important lesson is simply that head cleanup should be performed with knowledge of current WordPress behavior rather than by deleting output blindly.

RSD vs. REST API discovery

The two mechanisms solve related discovery problems using different architectures.

RSD

HTML page
↓
RSD link
↓
XML RSD document
↓
API endpoint

REST discovery

HTML or HTTP metadata
↓
REST API URL
↓
/wp-json/

RSD requires an additional XML discovery document.

Modern REST discovery can point applications more directly toward the API.

RSD vs. the WordPress shortlink

Both can appear inside <head>, but they have unrelated purposes.

RSD:

advertises remote API discovery

A WordPress shortlink:

advertises an alternate short URL for content

Removing one has no inherent effect on the other.

See What Is the WordPress Shortlink, and Do You Need It?.

RSD vs. RSS discovery

Both use <link> elements to advertise machine-readable resources.

However:

RSD
→ API discovery

RSS discovery
→ content-feed discovery

Removing the RSD tag therefore has no effect on:

/feed/

or WordPress feed discovery.

For that layer, see How WordPress Advertises RSS Feeds by Default.

RSD vs. oEmbed discovery

oEmbed discovery tells external applications how content can be represented for embedding.

RSD tells remote clients which APIs a site exposes.

They are both examples of discoverability metadata, but they advertise completely different functionality.

Should the RSD tag be removed for security hardening?

It can be included in a broader cleanup policy, but it should not be treated as a major security control.

A sensible hardening sequence is:

1. determine whether XML-RPC is required;
2. restrict or disable unnecessary XML-RPC functionality;
3. protect authentication surfaces;
4. rate-limit abusive traffic where appropriate;
5. remove unnecessary discovery metadata such as RSD.

Doing only step five leaves the underlying functionality exposed.

Should RSD be removed from every WordPress site?

No universal rule is necessary.

A modern business website with no remote publishing clients can usually remove it without losing useful functionality.

A site with a known RSD-dependent integration should keep it.

The correct question is not:

Is RSD old?

It is:

Does anything on this site still need RSD discovery?

How TheOneWP handles RSD discovery

TheOneWP includes a dedicated Disable RSD Link feature for websites that do not need Really Simple Discovery in their document head.

The module removes the RSD discovery link generated by WordPress without pretending that this action disables XML-RPC itself.

That distinction is deliberate.

The result is:

Before

<link
    rel="EditURI"
    type="application/rsd+xml"
    href="https://example.com/xmlrpc.php?rsd"
/>


After

RSD discovery link removed

The underlying XML-RPC policy can then be managed separately depending on the site’s actual requirements.

This follows the same modular approach used for WordPress shortlinks, RSS discovery, REST API discovery and other optional head output.

How to test after removing the RSD tag

Clear caches

Clear:

• WordPress page cache;
• server cache;
• CDN cache;
• optimization-plugin cache.

Inspect the page source

Search for:

application/rsd+xml

and:

rel="EditURI"

The RSD element should no longer appear.

Check xmlrpc.php separately

If XML-RPC is supposed to remain enabled, verify that removing RSD has not been confused with blocking:

/xmlrpc.php

Test remote integrations

If the site has any remote management or publishing workflow, verify it after the change.

Check multiple frontend pages

Confirm the RSD element is not being reintroduced by:

• a theme;
• a plugin;
• custom code;
• cached HTML.

Common mistakes with the WordPress RSD tag

Assuming RSD is XML-RPC

RSD discovers APIs.

XML-RPC executes remote calls.

Removing RSD and assuming XML-RPC is disabled

The XML-RPC endpoint can remain available.

Removing RSD to stop pingbacks

Pingbacks are controlled separately.

Blocking XML-RPC but continuing to advertise it through RSD

If the endpoint is intentionally unavailable, review its discovery metadata too.

Removing RSD because it supposedly improves page speed

The performance difference is negligible.

Calling the RSD tag a vulnerability

It is discovery metadata, not a vulnerability by itself.

Assuming RSD is required for the REST API

The REST API has separate discovery mechanisms.

Assuming RSD is required for wp-admin

Normal WordPress administration does not depend on it.

Editing WordPress core to remove it

Use remove_action() instead.

Removing it without checking legacy integrations

Rare does not mean impossible.

Verify dependencies on business-critical sites.

WordPress RSD tag checklist

• Know that RSD means Really Simple Discovery.
• Understand that it is an API discovery mechanism.
• Recognize the rel="EditURI" link in the document head.
• Know that its content type is application/rsd+xml.
• Know that WordPress normally points it to xmlrpc.php?rsd.
• Understand that rsd_link() generates the discovery element.
• Know that the callback is connected to wp_head.
• Understand that the RSD document describes available remote APIs.
• Know that it can advertise WordPress XML-RPC.
• Understand that modern WordPress can also advertise the REST API through RSD.
• Distinguish RSD discovery from XML-RPC functionality.
• Remember that removing RSD does not disable xmlrpc.php.
• Remember that removing RSD does not disable pingbacks.
• Remember that removing RSD does not disable the REST API.
• Remember that removing RSD does not disable the Block Editor.
• Do not treat the RSD tag as an SEO requirement.
• Do not describe removing it as meaningful performance optimization.
• Do not describe the tag itself as a vulnerability.
• Recognize that it can contribute a small WordPress fingerprinting signal.
• Check for legacy remote publishing clients before removing it.
• Check custom integrations where appropriate.
• Use remove_action() instead of editing core files.
• Remove the discovery link separately from any XML-RPC restriction.
• If XML-RPC is blocked completely, review whether keeping RSD discovery still makes sense.
• Clear caches after changing head output.
• Inspect the rendered HTML rather than only theme source files.
• Search for application/rsd+xml after removal.
• Test remote integrations after changing discovery behavior.
• Keep RSD only when the site has a legitimate reason to advertise it.

Related guides

• XML-RPC in WordPress, Explained
• WordPress Head Tags You Can Safely Remove
• Cleaning Up WordPress’s Default Head Output
• How WordPress Advertises Its REST API
• Pingbacks, Trackbacks & Internal Links

Final recommendation

The WordPress RSD tag is a discovery mechanism from an earlier generation of remote publishing architecture.

It tells compatible software where to find an RSD XML document, and that document can then advertise remote APIs such as WordPress XML-RPC and, in modern WordPress, information about the REST API.

For most contemporary WordPress websites, users never interact with RSD directly and many sites have no external client that depends on it.

In that situation, removing the RSD link from wp_head is generally a reasonable cleanup decision.

However, the scope of that change must remain clear.

Removing:

<link rel="EditURI" ...>

only stops WordPress from advertising the RSD endpoint from normal frontend HTML.

It does not automatically disable XML-RPC.

It does not disable pingbacks.

It does not disable the REST API.

And it should not be presented as meaningful performance or security hardening by itself.

If XML-RPC is also unnecessary, evaluate and restrict that interface separately. If XML-RPC must remain available but nobody needs RSD-based discovery, remove only the discovery layer.

That is the cleanest approach: determine whether the site needs the feature, distinguish discovery from functionality, and remove only the layer that genuinely serves no purpose.