RSD and WordPress discovery endpoints, explained

WordPress exposes several discovery mechanisms that allow browsers, publishing clients, feed readers and external applications to learn which machine-readable services a website provides.

One of the oldest is RSD, or Really Simple Discovery.

A standard WordPress page can advertise RSD with markup similar to:

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

A compatible client can follow that URL, retrieve an XML document and discover remote interfaces such as WordPress XML-RPC and, in modern WordPress, the REST API.

RSD is only one part of a much larger discovery system.

WordPress can also advertise:

• the REST API;
• REST representations of individual resources;
• RSS feeds;
• oEmbed endpoints;
• shortlinks;
• XML-RPC-related capabilities;
• Windows Live Writer metadata;
• other resources added by themes and plugins.

These mechanisms are easy to confuse because several appear inside the same document <head>.

But they do not all do the same thing.

A useful distinction is:

Discovery
→ tells another application that something exists

Endpoint
→ receives the actual request

Authentication
→ establishes who is making the request

Authorization
→ determines what that client may do

Removing discovery therefore does not automatically disable the underlying endpoint.

This guide explains how RSD fits into WordPress’s broader discovery architecture, which endpoints and resources WordPress advertises, how the different mechanisms interact, and what actually happens when you hide or disable them.

What is a discovery endpoint?

The term can be slightly ambiguous because two related concepts are often described together.

Discovery metadata

This is information embedded in HTML or HTTP headers that points clients toward another resource.

For example:

<link
    rel="https://api.w.org/"
    href="https://example.com/wp-json/"
/>

tells a client where the WordPress REST API root is located.

Discovery endpoint

This is an actual URL that returns machine-readable information about available services.

For RSD, that URL is commonly:

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

The RSD endpoint itself then advertises additional API endpoints.

WordPress therefore uses discovery in multiple layers.

The WordPress discovery architecture

A simplified WordPress installation can expose something like:

WordPress frontend page
│
├── RSD discovery
│   └── /xmlrpc.php?rsd
│       ├── XML-RPC endpoint
│       └── REST API endpoint
│
├── REST API discovery
│   ├── HTML <link>
│   └── HTTP Link header
│
├── RSS discovery
│   ├── site feed
│   ├── comments feed
│   └── contextual feeds
│
├── oEmbed discovery
│   ├── JSON oEmbed
│   └── XML oEmbed
│
└── shortlink discovery
    └── ?p=123

Some of these discovery systems are modern.

Others exist primarily because WordPress maintains compatibility with older publishing technologies.

RSD: Really Simple Discovery

RSD is an XML-based mechanism for discovering remote publishing APIs.

WordPress outputs the RSD discovery element through:

rsd_link()

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

The current core implementation points to:

xmlrpc.php?rsd

using the site’s WordPress installation URL.

For a dedicated explanation of that tag, see What Is the RSD Tag in WordPress?.

How a client discovers RSD

A compatible application starts with a normal webpage.

It parses the document head and looks for:

rel="EditURI"

with the type:

application/rsd+xml

The complete workflow is:

Client receives website URL
        ↓
requests frontend HTML
        ↓
parses document head
        ↓
finds RSD link
        ↓
requests /xmlrpc.php?rsd
        ↓
parses RSD XML
        ↓
discovers supported APIs

What does the RSD document contain?

The RSD response contains structured information about the site and available publishing interfaces.

A simplified response can resemble:

<?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"
            />

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

        </apis>

    </service>
</rsd>

The official WordPress REST API discovery documentation documents this RSD-based discovery process and shows both WordPress XML-RPC and WP-API entries in the discovery document.

RSD can advertise XML-RPC

Historically, this was one of its primary purposes.

An RSD document can tell a remote publishing client that the WordPress XML-RPC endpoint is:

https://example.com/xmlrpc.php

The client can then communicate directly with that endpoint.

This creates two different layers:

/xmlrpc.php?rsd
→ discovery

/xmlrpc.php
→ API communication

This distinction is covered in more detail in XML-RPC in WordPress, Explained.

Removing RSD does not disable XML-RPC

If you remove:

<link rel="EditURI" ...>

from the frontend HTML, a client can still request:

/xmlrpc.php

directly.

Therefore:

RSD removed
≠
XML-RPC disabled

If XML-RPC itself is unnecessary, that interface must be evaluated separately.

See What Is XML-RPC in WordPress, and Why Disable It?.

RSD can also advertise the REST API

WordPress extended its legacy discovery system when the REST API was introduced.

The function:

rest_output_rsd()

adds the REST API root URL to the RSD response.

The official rest_output_rsd() documentation confirms that it adds the REST API URL to the WordPress RSD endpoint.

The resulting entry uses:

name="WP-API"

and points toward the API root returned by WordPress.

Why does modern WordPress put REST information inside a legacy RSD document?

Backward compatibility.

A client that already understands RSD can learn that a newer API is available without implementing a completely different initial discovery mechanism.

This does not make RSD the preferred way to discover the REST API.

The WordPress REST API handbook explicitly describes RSD as the least-preferred of the primary REST discovery methods because it requires:

1. retrieving HTML;
2. parsing the RSD link;
3. performing another request;
4. parsing an XML document.

More direct discovery methods require fewer steps.

Modern REST API discovery

WordPress exposes REST discovery independently of RSD.

The standard REST root is normally:

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

For sites using default permalink structures, WordPress may instead expose a URL based on:

?rest_route=/

The official REST API Discovery handbook documents both forms.

See How WordPress Advertises Its REST API for the complete WordPress-specific workflow.

REST discovery through an HTML link element

WordPress can output:

<link
    rel="https://api.w.org/"
    href="https://example.com/wp-json/"
/>

The corresponding function is:

rest_output_link_wp_head()

The official rest_output_link_wp_head() reference shows that the function outputs the REST API link tag into the page header.

The callback can also output an alternate JSON representation for the currently queried resource when WordPress can determine an appropriate REST route.

REST discovery through HTTP Link headers

HTML is not the only discovery layer.

WordPress can send:

Link: <https://example.com/wp-json/>;
      rel="https://api.w.org/"

through HTTP response headers.

The corresponding core function is:

rest_output_link_header()

The official discovery documentation identifies this header-based method as the preferred REST API discovery mechanism.

Removing the REST head link may leave REST discovery elsewhere

If you remove only:

rest_output_link_wp_head()

you may still have:

• the REST HTTP Link header;
• RSD advertising the REST API;
• direct access to /wp-json/;
• resource-specific JSON links.

This is why Hiding vs. Restricting the WordPress REST API distinguishes discovery cleanup from actual API access control.

Resource discovery in modern WordPress

WordPress does not only advertise the API root.

It can also advertise the REST representation corresponding to the current frontend resource.

For example, a post page can expose something similar to:

<link
    rel="alternate"
    type="application/json"
    href="https://example.com/wp-json/wp/v2/posts/123"
/>

The REST API handbook documents this resource discovery behavior, which was added to provide a machine-readable link between frontend documents and their API representations.

REST discovery continues inside API responses

The discovery system does not stop when a client reaches /wp-json/.

REST API responses can contain relational links to related resources.

The official Linking and Embedding documentation describes the _links and _embedded structures WordPress uses to make API responses browsable.

A response can identify relationships such as:

• author;
• taxonomy terms;
• collection routes;
• related resources.

Discovery therefore exists both:

outside the API
→ helping clients find it

inside the API
→ helping clients navigate it

REST namespaces are another discovery layer

Requesting:

/wp-json/

returns the REST API index.

This can expose registered namespaces such as:

wp/v2
oembed/1.0

and namespaces added by plugins.

For example:

my-plugin/v1

can indicate that an installed plugin has registered REST functionality.

This is one reason REST exposure is sometimes discussed in relation to WordPress fingerprinting.

But hiding only the head discovery element does not prevent somebody from requesting the API index directly.

RSS feed discovery

WordPress also advertises syndicated content feeds.

A typical page can contain:

<link
    rel="alternate"
    type="application/rss+xml"
    title="Example Site Feed"
    href="https://example.com/feed/"
/>

WordPress uses:

feed_links()

for general feed discovery.

The official feed_links() documentation confirms that it displays links to general feeds when the theme supports automatic feed links.

Contextual feed discovery

WordPress can also advertise feeds associated with the current query using:

feed_links_extra()

Depending on context, these can include feeds for:

• individual post comments;
• categories;
• tags;
• custom taxonomies;
• authors;
• search results;
• custom post type archives.

The current feed_links_extra() documentation describes these contextual feed links.

The full advertising process is covered in How WordPress Advertises RSS Feeds by Default.

Removing feed discovery does not disable feeds

This follows exactly the same discovery-versus-functionality model.

If you remove:

feed_links()
feed_links_extra()

from wp_head, the endpoint:

/feed/

can remain accessible.

Therefore:

Feed links hidden
≠
feeds disabled

See Hiding vs. Disabling WordPress Feeds and Disable RSS Feeds vs. Remove Feed Links.

oEmbed discovery endpoints

WordPress can also expose machine-readable oEmbed representations of embeddable content.

For an eligible singular post, WordPress can output discovery links such as:

<link
    rel="alternate"
    type="application/json+oembed"
    href="..."
/>

<link
    rel="alternate"
    type="text/xml+oembed"
    href="..."
/>

The corresponding WordPress function is:

wp_oembed_add_discovery_links()

The official wp_oembed_add_discovery_links() documentation confirms that WordPress can generate JSON and XML oEmbed discovery links for embeddable singular content.

What does oEmbed discovery tell another site?

It tells an application:

This page can provide an embeddable representation.

Here is the endpoint that generates it.

That is conceptually similar to RSS or REST discovery, but the purpose is different.

RSS:

discover syndicated content

REST:

discover API resources

oEmbed:

discover an embeddable representation

For the complete feature, see WordPress oEmbed Privacy and Security, Explained.

Removing oEmbed discovery is different from disabling oEmbed

Removing only the discovery links does not necessarily eliminate every oEmbed endpoint or embedding behavior.

A complete shutdown involves more than deleting:

<link type="application/json+oembed">

from the document head.

See How to Disable oEmbed in WordPress.

WordPress shortlink discovery

WordPress can advertise an alternative short URL using:

<link
    rel="shortlink"
    href="https://example.com/?p=123"
/>

The corresponding function is:

wp_shortlink_wp_head()

The official wp_shortlink_wp_head() reference confirms that WordPress injects a rel="shortlink" element when a shortlink exists for the current page.

Shortlinks can also be advertised through HTTP headers

WordPress additionally provides:

wp_shortlink_header()

which can send:

Link: <https://example.com/?p=123>; rel=shortlink

The official wp_shortlink_header() documentation confirms this separate HTTP-level discovery mechanism.

This mirrors the REST API pattern:

HTML discovery
+
HTTP header discovery

For the full shortlink architecture, see What Is the WordPress Shortlink, and Do You Need It?.

Removing the shortlink does not necessarily disable ?p=ID URLs

Removing:

<link rel="shortlink">

only removes one advertisement of the alternate URL.

WordPress can still understand its underlying query-based permalink format.

Again:

Discovery removed
≠
routing disabled

Windows Live Writer discovery

WordPress also includes legacy metadata for Windows Live Writer:

<link
    rel="wlwmanifest"
    type="application/wlwmanifest+xml"
    href="https://example.com/wp-includes/wlwmanifest.xml"
/>

The callback is:

wlwmanifest_link()

This mechanism helped desktop publishing software understand WordPress capabilities.

Like RSD, it belongs primarily to WordPress’s historical remote publishing ecosystem.

Pingback discovery

Themes or custom implementations can expose:

<link
    rel="pingback"
    href="https://example.com/xmlrpc.php"
/>

This tells another system where pingback requests can be sent.

The underlying functionality relates to XML-RPC methods such as:

pingback.ping

Removing a pingback discovery element does not automatically remove those methods.

The complete relationship is explained in Pingbacks, Trackbacks & Internal Links.

Discovery markup often comes through wp_head

Many WordPress discovery mechanisms appear because themes call:

wp_head()

The official wp_head() documentation confirms that the function fires the wp_head action.

WordPress core attaches numerous callbacks there.

The current wp_head hook reference includes callbacks for:

• feed links;
• RSD;
• Windows Live Writer;
• shortlinks;
• canonical URLs;
• WordPress version output;
• styles and scripts;
• site icons;
• other core output.

This is why a WordPress head audit often reveals several unrelated discovery systems next to each other.

Not everything inside wp_head is a discovery endpoint

This distinction matters.

For example:

<link rel="canonical" ...>

is not an API discovery mechanism.

It communicates the preferred URL for indexing and consolidation.

Similarly:

• stylesheets load CSS;
• scripts execute JavaScript;
• robots tags control crawler behavior;
• site icons provide branding;
• Open Graph tags describe social sharing content.

Do not classify every <link> element as optional WordPress discovery clutter.

See WordPress Head Tags You Can Safely Remove for a safer breakdown.

Discovery removal vs. endpoint restriction

This is the central architectural rule for all of these systems.

Feature	Discovery	Underlying functionality
RSD	rel="EditURI"	xmlrpc.php?rsd and advertised APIs
REST API	api.w.org link/header	/wp-json/
RSS	application/rss+xml links	/feed/ endpoints
oEmbed	oEmbed alternate links	oEmbed REST endpoints
Shortlink	rel="shortlink"	short URL routing
Pingback	pingback link metadata	XML-RPC pingback methods

Why hiding discovery is not access control

Most standard WordPress endpoints are predictable.

An automated client can try:

/wp-json/
/xmlrpc.php
/feed/

without first parsing the website.

Therefore removing discovery metadata can:

• reduce passive exposure;
• clean frontend markup;
• remove unused legacy signals;
• reduce automatic discovery by compliant clients.

It cannot reliably prevent direct requests.

Why discovery still matters even when endpoints are predictable

Predictability does not make discovery meaningless.

Discovery provides a standardized contract.

A client can identify:

• the correct API root;
• whether pretty permalinks are active;
• the canonical endpoint generated by WordPress;
• which services are supported;
• resource-specific API representations;
• plugin REST namespaces.

This is particularly useful for software that must connect to arbitrary WordPress installations rather than one hard-coded site.

Discovery and WordPress fingerprinting

Discovery metadata can also provide information about the site’s underlying platform.

Examples include:

xmlrpc.php?rsd
https://api.w.org/
/wp-json/
wp/v2
application/json+oembed

These signals can help identify WordPress.

Removing some of them reduces obvious platform metadata, but it does not make a WordPress installation anonymous.

Other signals commonly remain.

See How Attackers Fingerprint WordPress Sites.

Discovery metadata is not automatically a vulnerability

A discovery element does not become a vulnerability simply because it reveals an endpoint.

The important question is what the endpoint allows.

For example:

REST discovery link
→ reveals /wp-json/

REST permissions
→ determine which data or operations are accessible

Likewise:

RSD
→ reveals XML-RPC

XML-RPC policy
→ determines whether remote methods are actually usable

Security belongs primarily at the functionality, authentication and authorization layers.

How RSD interacts with WordPress internal behavior

RSD is old, but it is not completely disconnected from current WordPress core.

WordPress provides:

wp_is_local_html_output()

which can inspect returned HTML to determine whether it appears to have been generated by the local site.

The current wp_is_local_html_output() source first checks for the site’s RSD link when rsd_link remains attached to wp_head.

If the RSD callback is unavailable, WordPress can instead inspect the REST API discovery link.

This is a useful reminder that legacy discovery output can occasionally have secondary roles inside modern WordPress.

Does this mean RSD cannot be removed?

No.

The same WordPress implementation explicitly accounts for the possibility that the RSD callback has been removed.

The lesson is simply:

old feature
≠
feature with zero current references

Head cleanup should therefore be based on current core behavior rather than ancient snippets copied indefinitely from one WordPress tutorial to another.

How WordPress discovery has evolved

WordPress’s discovery mechanisms reflect several generations of web publishing technology.

Early remote publishing

Systems such as:

• RSD;
• XML-RPC;
• Windows Live Writer manifests;
• pingbacks;
• MetaWeblog compatibility;

supported desktop and distributed blogging workflows.

Syndication

RSS discovery allowed feed readers and aggregators to automatically find content feeds.

Embeddable content

oEmbed discovery allowed external platforms to retrieve standardized embeddable representations.

Modern APIs

REST discovery now exposes JSON-based application interfaces and links frontend resources to API representations.

Modern WordPress therefore contains old and new discovery systems simultaneously.

Should you remove all WordPress discovery metadata?

Usually not as a single blanket policy.

Each mechanism should be evaluated independently.

For example:

RSD
→ probably unnecessary on many modern sites

WLW manifest
→ probably unnecessary on many modern sites

RSS discovery
→ useful for publications and feed consumers

REST discovery
→ useful for API clients and modern integrations

oEmbed discovery
→ useful when content should be embeddable

Shortlink
→ often unnecessary but harmless

The correct configuration depends on the website.

A sensible discovery policy for a modern business website

A typical company website with no remote publishing clients might reasonably use:

RSD discovery              removed
WLW manifest               removed
WordPress shortlink        removed
RSS discovery              optional
REST discovery             evaluate
oEmbed discovery           evaluate
Canonical URLs             keep
Site icon                  keep
SEO metadata               keep

A news publication can reasonably make completely different choices.

A sensible discovery policy for a content publisher

A publication could reasonably use:

RSD discovery              removed
WLW manifest               removed
RSS discovery              keep
REST discovery             keep
oEmbed discovery           keep
Shortlink                  optional

RSS, APIs and embedding can provide real distribution value in that environment.

A sensible policy for a headless WordPress site

A headless installation may depend heavily on:

REST API
or
GraphQL/plugin APIs

while having almost no reason to expose:

• RSD;
• Windows Live Writer discovery;
• shortlinks;
• traditional frontend feed discovery.

Removing REST discovery purely because it looks like WordPress metadata would be particularly questionable in this architecture.

How to remove RSD discovery

If no client needs RSD, the frontend discovery tag can be removed with:

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

The official remove_action() documentation explains the WordPress mechanism for detaching callbacks from actions.

How to remove selected WordPress discovery output

A broader but still selective cleanup could look like:

add_action(
    'after_setup_theme',
    function () {

        // Really Simple Discovery.
        remove_action( 'wp_head', 'rsd_link' );

        // Windows Live Writer discovery.
        remove_action( 'wp_head', 'wlwmanifest_link' );

        // WordPress shortlink discovery.
        remove_action( 'wp_head', 'wp_shortlink_wp_head', 10 );

        // RSS discovery.
        remove_action( 'wp_head', 'feed_links', 2 );
        remove_action( 'wp_head', 'feed_links_extra', 3 );

        // REST API discovery in HTML.
        remove_action( 'wp_head', 'rest_output_link_wp_head', 10 );
    }
);

This is an example of discovery cleanup.

It is not equivalent to disabling all of the corresponding endpoints.

For a wider audit, see Cleaning Up WordPress’s Default Head Output.

Do not remove canonical URLs as discovery cleanup

A canonical element such as:

<link
    rel="canonical"
    href="https://example.com/example-post/"
/>

serves an SEO-related URL consolidation purpose.

It is not equivalent to an RSD, RSS, REST or oEmbed discovery link.

See WordPress Canonical URLs, Explained.

Do not remove the REST API just because RSD is legacy

RSD and REST appear together because WordPress supports compatibility between generations of APIs.

That does not mean their importance is equivalent.

Many sites can remove RSD with almost no consequences.

The REST API can be fundamental to:

• the Block Editor;
• the Site Editor;
• plugins;
• custom administration interfaces;
• headless applications;
• external integrations.

Before applying restrictions, see What Depends on the WordPress REST API.

How to audit WordPress discovery endpoints

1. Inspect the rendered document head

Search for:

EditURI
application/rsd+xml
wlwmanifest
https://api.w.org/
application/rss+xml
application/json+oembed
text/xml+oembed
shortlink
pingback

2. Inspect HTTP response headers

Look for Link headers advertising:

• REST API roots;
• REST resource representations;
• shortlinks.

3. Request the RSD endpoint

Inspect:

/xmlrpc.php?rsd

and identify which APIs are advertised.

4. Request the REST API root

Check:

/wp-json/

or the appropriate:

?rest_route=/

form.

5. Inspect REST namespaces

Identify functionality registered by:

• WordPress core;
• plugins;
• custom code.

6. Check RSS endpoints

Test the feeds the site actually needs.

For a deeper map, see WordPress RSS Feed URLs Explained.

7. Inspect oEmbed discovery

Check singular posts and pages separately because oEmbed discovery is contextual.

8. Check integrations before removing anything

Review:

• publishing clients;
• mobile apps;
• feed services;
• REST clients;
• headless frontends;
• automation platforms;
• embedding workflows;
• custom software.

How to test discovery cleanup

After changing discovery output:

1. clear WordPress caches;
2. clear server caches;
3. clear CDN caches;
4. inspect HTML again;
5. inspect HTTP response headers;
6. test the actual endpoint independently;
7. test legitimate external integrations.

That fifth and sixth step is especially important.

If you remove an HTML discovery element and then conclude the underlying API is disabled because the HTML disappeared, you have only tested the wrong layer very successfully.

How TheOneWP approaches WordPress discovery endpoints

TheOneWP treats discovery output as a collection of separate WordPress behaviors rather than one generic “remove everything from the head” switch.

This makes it possible to control features such as:

• RSD discovery;
• REST API discovery;
• RSS feed links;
• shortlinks;
• oEmbed functionality;
• WordPress version output;
• other optional head metadata.

For RSD specifically, the Disable RSD Link feature removes the Really Simple Discovery link from WordPress frontend output.

This should be understood as:

RSD advertisement removed

not:

every remotely accessible WordPress API disabled

The same principle applies to the Disable REST API Links feature, which targets REST discovery rather than blindly disabling the REST API itself.

Feed discovery can likewise be handled independently through Disable RSS Feed Links.

And WordPress shortlink advertising can be removed separately with Disable Shortlink.

This modular separation matters because:

RSD
REST
RSS
oEmbed
shortlinks
XML-RPC

are related through discovery architecture, but they are not one feature.

Common mistakes with WordPress discovery endpoints

Assuming every discovery link is an endpoint

Some elements only point toward the real endpoint.

Assuming every endpoint is advertised in wp_head

Some are also exposed through HTTP headers or predictable URLs.

Removing RSD and claiming XML-RPC is disabled

RSD is discovery.

XML-RPC is the underlying remote API.

Removing REST discovery and claiming /wp-json/ is private

The endpoint remains directly discoverable and accessible according to its permissions.

Removing feed links and claiming RSS is disabled

Feed endpoints can remain active.

Removing oEmbed links and assuming every embed endpoint has disappeared

Discovery removal and feature disabling are separate operations.

Removing shortlinks and assuming ?p=ID no longer works

Routing and discovery are separate.

Treating RSD as the preferred modern REST discovery method

WordPress documents HTTP Link discovery as preferable and RSD as the least-preferred primary REST discovery mechanism.

Calling discovery metadata a security vulnerability

Information exposure and exploitable functionality are different concepts.

Trying to make WordPress invisible by deleting discovery links

Many other fingerprinting signals remain.

Removing every link element from wp_head

Some links perform essential SEO, browser or resource-loading functions.

Testing only HTML

Discovery can also exist in HTTP headers and machine-readable endpoints.

RSD and WordPress discovery endpoints checklist

• Know that RSD means Really Simple Discovery.
• Recognize the rel="EditURI" RSD element.
• Know that WordPress normally points RSD to xmlrpc.php?rsd.
• Understand that rsd_link() outputs the RSD discovery element.
• Understand that the RSD response is an XML document.
• Know that RSD can advertise WordPress XML-RPC.
• Know that modern WordPress can also advertise the REST API through RSD.
• Understand the role of rest_output_rsd().
• Know that RSD is not the preferred modern REST discovery mechanism.
• Recognize REST discovery through rel="https://api.w.org/".
• Understand rest_output_link_wp_head().
• Check REST discovery in HTTP Link headers.
• Understand that REST discovery can include resource-specific JSON links.
• Inspect the REST API index for namespaces.
• Recognize RSS discovery through application/rss+xml.
• Understand the difference between feed_links() and feed_links_extra().
• Remember that hiding RSS discovery does not disable feeds.
• Recognize JSON and XML oEmbed discovery links.
• Understand the role of wp_oembed_add_discovery_links().
• Remember that hiding oEmbed discovery is narrower than disabling oEmbed.
• Recognize WordPress rel="shortlink" output.
• Remember that shortlinks can also be advertised through HTTP headers.
• Remember that hiding a shortlink does not necessarily disable ?p=ID routing.
• Recognize Windows Live Writer discovery as legacy publishing metadata.
• Evaluate pingback discovery separately from XML-RPC functionality.
• Understand that many discovery callbacks are connected to wp_head.
• Do not treat every <link> element as optional.
• Keep canonical URLs unless intentionally replaced.
• Keep required styles, scripts and SEO metadata.
• Distinguish discovery from authentication.
• Distinguish authentication from authorization.
• Do not treat hidden endpoints as protected endpoints.
• Review public REST permissions separately from REST discovery.
• Review XML-RPC policy separately from RSD.
• Review feeds separately from feed links.
• Review oEmbed functionality separately from oEmbed links.
• Inspect both HTML and HTTP response headers.
• Test predictable endpoints directly.
• Review plugin-added REST namespaces.
• Review remote publishing clients.
• Review feed consumers.
• Review headless applications.
• Review embedding requirements.
• Clear caches after changing discovery output.
• Test multiple frontend contexts after cleanup.
• Use current WordPress Developer Resources when removing core callbacks.
• Prefer selective discovery cleanup to indiscriminate head stripping.

Related guides

• What Is the RSD Tag in WordPress?
• How WordPress Advertises Its REST API
• Hiding vs. Restricting the WordPress REST API
• XML-RPC in WordPress, Explained
• How WordPress Advertises RSS Feeds by Default
• Cleaning Up WordPress’s Default Head Output

Final recommendation

RSD makes much more sense when it is viewed as one member of WordPress’s broader discovery architecture rather than as an isolated legacy tag.

WordPress has accumulated several generations of machine-readable discovery:

RSD
→ remote publishing APIs

REST discovery
→ modern JSON API

RSS discovery
→ syndicated content

oEmbed discovery
→ embeddable content

shortlinks
→ alternate content URLs

Some of these mechanisms remain central to modern WordPress.

Others exist largely for backward compatibility.

The important distinction is that discovery and functionality are separate layers.

Removing the RSD tag does not disable XML-RPC.

Removing the REST API link does not restrict /wp-json/.

Removing RSS links does not disable feeds.

Removing oEmbed discovery does not necessarily remove every oEmbed endpoint.

Removing a shortlink does not automatically disable WordPress’s query-based URL routing.

For that reason, a WordPress cleanup strategy should begin by deciding what you actually want to change.

If a service remains useful but its automatic discovery does not, remove only the discovery layer.

If the underlying service itself is unnecessary, evaluate and disable that functionality separately.

If the service contains protected operations, secure those operations with proper authentication and authorization rather than relying on an undisclosed URL.

For most modern WordPress sites, legacy discovery such as RSD and Windows Live Writer metadata can often be removed safely after checking dependencies, while REST, RSS and oEmbed should be evaluated according to the site’s actual publishing and integration requirements.

The cleanest WordPress configuration is therefore not the one that exposes the fewest possible links. It is the one where every advertised endpoint and every enabled service exists for a deliberate reason.