How WordPress advertises RSS feeds by default

WordPress does more than provide RSS feed URLs. It can also advertise those feeds automatically inside the HTML document head, allowing browsers, feed readers and other software to discover them without already knowing the feed address.

This distinction matters because a WordPress feed and a WordPress feed discovery link are not the same thing.

The feed itself might exist at:

https://example.com/feed/

while WordPress advertises it from a normal HTML page using markup similar to:

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

Removing that <link> element does not automatically remove or disable the feed endpoint.

Likewise, disabling a feed endpoint without removing its discovery markup can leave WordPress advertising a resource that no longer works.

WordPress can advertise more than just the primary posts feed. Depending on the page being viewed, the site configuration and the active theme, discovery links can point to feeds for:

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

This guide explains how WordPress advertises RSS feeds by default, which core functions generate those links, how theme support affects them, why different pages can advertise different feeds, and how to remove feed discovery safely without confusing it with disabling RSS itself.

What does it mean for WordPress to advertise an RSS feed?

Advertising a feed means publishing metadata that tells compatible software where a syndication version of the current website or content collection can be found.

WordPress normally does this through <link> elements placed inside the page’s <head>.

For example:

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

The important attributes are:

• rel="alternate", indicating an alternative representation;
• type="application/rss+xml", identifying the format;
• href, providing the feed URL;
• title, describing what the feed represents.

A client inspecting the HTML can therefore discover the feed programmatically.

Feed discovery is different from the feed itself

The feed discovery tag is only a pointer.

It is not the actual RSS feed.

Think of the relationship like this:

Normal webpage
https://example.com/

contains:

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

                       ↓

RSS endpoint
https://example.com/feed/

The first resource advertises the second.

This is exactly why the distinction between hiding feeds and disabling feeds matters.

For the complete comparison, see Hiding vs. Disabling WordPress Feeds.

Why does WordPress advertise feeds automatically?

RSS was designed around syndication and automatic discovery.

A visitor should not necessarily need to know that:

/feed/

exists.

Software can instead inspect the page and discover the appropriate feed URL.

This historically allowed:

• browsers to display subscription controls;
• RSS readers to detect available feeds;
• aggregators to locate syndication endpoints;
• applications to subscribe to site updates;
• blogging tools to recognize related content streams.

Browser interfaces have changed dramatically since RSS’s peak popularity, but the underlying discovery mechanism remains part of WordPress.

Which WordPress functions generate feed discovery links?

Two core functions are particularly important:

feed_links()
feed_links_extra()

The official WordPress Developer Resources describe feed_links() as the function that displays links to the general feeds.

The feed_links_extra() documentation describes the second function as displaying additional contextual feeds, such as category feeds.

They serve related but different roles.

What does feed_links() advertise?

feed_links() handles the general site-level feeds.

Its output can include discovery for:

• the site’s main posts feed;
• the site’s comments feed.

A typical page might therefore contain:

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

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

These are general feeds rather than feeds specific to the current archive or post.

What does feed_links_extra() advertise?

feed_links_extra() adds contextual feed discovery based on the current WordPress query.

This is where the system becomes considerably broader than just:

/feed/

Depending on the current page, WordPress can advertise feeds associated with:

• single-post comments;
• categories;
• tags;
• custom taxonomy terms;
• authors;
• search queries;
• public post type archives.

The current WordPress source for feed_links_extra() contains conditional handling for each of these contexts.

Feed discovery changes depending on the page

One of the easiest mistakes during a WordPress audit is checking only the homepage.

The homepage might advertise:

Main posts feed
Comments feed

but a category page can advertise an additional category-specific feed.

A single post may advertise a comments feed for that post.

A search-results page can advertise a feed representing that search.

Therefore WordPress feed discovery is contextual.

Homepage feed discovery

On a typical installation, the homepage or blog archive may advertise the main site feed:

https://example.com/feed/

and possibly the global comments feed:

https://example.com/comments/feed/

These are the most obvious feeds and are usually what administrators encounter first when inspecting the page source.

Category feed discovery

Suppose the site contains a category:

https://example.com/category/security/

WordPress can generate a feed for posts inside that category:

https://example.com/category/security/feed/

When viewing the category archive, feed_links_extra() can advertise this feed automatically.

This makes the feed specific to the content currently being browsed.

Tag feed discovery

The same concept applies to tags.

A tag archive such as:

https://example.com/tag/performance/

can have its own feed:

https://example.com/tag/performance/feed/

WordPress can include a corresponding discovery element when rendering that archive.

Custom taxonomy feed discovery

WordPress’s feed architecture is not limited to built-in categories and tags.

A public custom taxonomy can also expose term feeds.

For example, a site might define:

Topic:
security

URL:
/topic/security/

Feed:
/topic/security/feed/

The function get_term_feed_link() generates feed URLs for taxonomy terms.

This becomes especially relevant on larger WordPress installations that use custom content structures.

Author feed discovery

Author archives can also have feeds.

For example:

Author archive:
https://example.com/author/jane/

Author feed:
https://example.com/author/jane/feed/

When viewing an author archive, WordPress can advertise that author’s posts feed.

Whether author archives themselves should be publicly exposed is a separate editorial, SEO and privacy decision.

Feed discovery merely reflects the route WordPress provides.

Search-result feed discovery

WordPress can generate feeds based on search queries.

Conceptually, a search such as:

https://example.com/?s=security

can correspond to a feed representing results for that query.

feed_links_extra() contains specific handling for search feeds and can advertise them when the current request is a search-results page.

Many site owners never intentionally use this feature, which is precisely why a complete audit should not assume only the main feed exists.

Post type archive feed discovery

Public custom post types can have archive feeds when their configuration supports feeds.

Suppose a website registers a public post type:

Projects

with an archive at:

https://example.com/projects/

A corresponding feed might be available at:

https://example.com/projects/feed/

The WordPress get_post_type_archive_feed_link() function is used to generate this type of URL.

For a broader discussion of custom content structures, see WordPress Custom Post Types and SEO.

Individual post comments feeds

WordPress can expose a feed containing comments for one specific post.

For example:

Post:
https://example.com/example-article/

Comments feed:
https://example.com/example-article/feed/

depending on the permalink and feed configuration.

On singular content, WordPress can advertise this feed separately from the global site comments feed.

This is another example of why a homepage-only inspection does not reveal every feed discovery link WordPress may output.

How feed discovery reaches wp_head

Feed discovery links are typically printed through WordPress’s wp_head action.

The wp_head hook is where WordPress, themes and plugins add many elements to the document head.

That can include:

• feed discovery links;
• canonical links;
• REST API discovery;
• shortlinks;
• oEmbed discovery;
• scripts;
• styles;
• resource hints;
• other metadata.

This is why RSS discovery often appears as part of a broader WordPress head cleanup.

See Cleaning Up WordPress’s Default Head Output for the larger architecture.

The role of automatic-feed-links theme support

Modern WordPress themes can declare support for automatic feed links using:

add_theme_support( 'automatic-feed-links' );

This tells WordPress that the theme supports automatic feed discovery output.

The older function:

automatic_feed_links()

still exists but has been deprecated since WordPress 3.0.

The official automatic_feed_links() documentation explicitly recommends using:

add_theme_support( 'automatic-feed-links' )

instead.

Why theme support matters

Feed links may look like purely core-generated markup, but WordPress expects themes to participate in deciding whether automatic feed-link output should be active.

A theme can declare:

add_theme_support( 'automatic-feed-links' );

commonly from a setup function:

function example_theme_setup() {
    add_theme_support( 'automatic-feed-links' );
}

add_action( 'after_setup_theme', 'example_theme_setup' );

This allows WordPress to generate appropriate discovery metadata rather than requiring the theme to hard-code feed URLs manually.

Do block themes advertise feeds differently?

The fundamental WordPress feed system remains the same, but themes can differ in how they register support and what additional markup they output.

A block theme does not eliminate RSS simply because templates are constructed with blocks.

Likewise, switching from a classic theme to a block theme should not be assumed to disable feed endpoints.

Feeds are WordPress routing and syndication functionality, not merely a theme template feature.

How WordPress chooses the feed URL

WordPress provides dedicated functions for generating feed URLs rather than relying on themes to concatenate strings manually.

The primary feed URL can ultimately be generated using WordPress’s feed-link APIs.

The feed_link filter can modify a generated feed permalink before it is returned.

This means plugins or custom code can potentially alter where a feed points.

WordPress supports multiple feed formats

RSS 2.0 is the format most administrators recognize, but WordPress has historically supported several feed formats.

The official WordPress Feeds documentation lists built-in support including:

• RSS 2.0;
• Atom;
• RSS 0.92;
• RDF/RSS 1.0.

The site’s default feed is normally RSS2 unless configuration changes it.

That is why the discovery markup most commonly uses:

type="application/rss+xml"

Feed discovery does not mean every feed format is advertised

WordPress can understand multiple feed formats without printing separate discovery links for every historical format on every page.

The important distinction is between:

• formats WordPress can serve;
• feed URLs WordPress generates;
• feed URLs WordPress advertises in the current document.

These sets are related but not necessarily identical.

How to inspect WordPress feed discovery

The easiest audit begins with the rendered page source.

Open a public page and search for:

application/rss+xml

You may find markup such as:

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

Do not stop after finding the first one.

Search for every occurrence.

Inspect several WordPress page types

A complete audit should include representative pages from different query contexts.

Check at least:

• homepage;
• posts archive;
• single post;
• category archive;
• tag archive;
• author archive;
• search results;
• custom taxonomy archive;
• custom post type archive.

The exact set depends on the site’s architecture.

Do feed discovery links appear visibly to visitors?

Normally, no.

They live inside:

<head>

rather than the visible:

<body>

A typical visitor will therefore not see an RSS link in the page content unless the theme or site owner explicitly adds one.

The discovery metadata exists primarily for software rather than human navigation.

An RSS icon is separate from feed discovery

A theme might display a visible RSS icon:

Subscribe via RSS

and link it directly to:

/feed/

That visible link is separate from WordPress’s automatic <head> discovery.

Removing feed_links() does not automatically remove a manually created:

• menu item;
• footer link;
• RSS icon;
• widget;
• block;
• theme template link.

This distinction matters when someone expects a head-cleanup snippet to eliminate every visible mention of RSS from the site.

The RSS block is also separate

WordPress includes an RSS block that can display entries from a feed.

The official RSS block documentation describes its use for displaying content from another site’s RSS feed.

Removing your own site’s feed discovery does not remove the RSS block from WordPress.

Likewise, disabling your site’s feeds does not inherently prevent an RSS block from consuming an unrelated external feed.

Does removing feed discovery disable /feed/?

No.

Suppose you remove both:

feed_links()
feed_links_extra()

from wp_head.

Your page source may no longer contain:

application/rss+xml

but visiting:

https://example.com/feed/

can still produce a normal RSS document.

This is one of the central distinctions in WordPress feed management.

For the implementation-level comparison, see Disable RSS Feeds vs. Remove Feed Links.

Does disabling /feed/ remove discovery automatically?

Not necessarily.

If custom code intercepts feed requests but leaves the default head callbacks in place, WordPress can continue outputting:

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

even though the destination no longer returns a valid feed.

This creates inconsistent configuration.

If feed functionality is intentionally disabled, discovery markup should normally be reviewed as part of the same change.

How to remove WordPress feed discovery links

If you want feeds to remain functional but no longer want WordPress advertising them automatically, remove the relevant callbacks from wp_head.

A focused implementation is:

add_action(
    'after_setup_theme',
    function () {
        remove_action( 'wp_head', 'feed_links', 2 );
        remove_action( 'wp_head', 'feed_links_extra', 3 );
    }
);

This targets the discovery layer.

It does not modify feed routes.

Why remove both feed_links and feed_links_extra?

Removing only:

feed_links

can leave contextual feed discovery generated by:

feed_links_extra

Conversely, removing only the extra links can leave the main posts and comments feeds advertised.

If the objective is:

Remove automatic WordPress feed discovery

then both layers should be considered.

WordPress now provides more granular feed discovery controls

Modern WordPress versions expose filters that allow individual contextual feed links to be controlled more selectively.

For example, feed_links_extra() includes filters for whether to display:

• post comments feeds;
• post type archive feeds;
• category feeds;
• tag feeds;
• taxonomy feeds;
• author feeds;
• search feeds.

This means a developer does not always need to choose between:

Everything on
Everything off

A project can suppress specific discovery types while leaving others available.

Example: hide author feed discovery only

If a site wants to keep RSS generally available but does not want author feed discovery advertised, a granular filter can be preferable to removing all feed links.

The architectural principle is:

Global removal
→ remove all contextual discovery

Granular filter
→ remove only one contextual feed type

This is useful on complex sites where some forms of syndication remain valuable.

Example: hide search feed discovery

Search feeds are rarely a deliberate requirement on many business websites.

A site might want to preserve:

• main RSS feed;
• category feeds;

while suppressing:

• search-result feed discovery.

The granular filters exposed by current versions of feed_links_extra() allow that type of targeted configuration.

Should you remove feed discovery?

There is no universal requirement to remove it.

Keeping discovery is reasonable when:

• the website actively supports RSS subscriptions;
• readers use feed applications;
• aggregators consume the content;
• automation depends on RSS;
• the site’s publishing strategy deliberately embraces syndication.

Removing it can be reasonable when:

• feeds exist only for compatibility;
• no automatic discovery is needed;
• the site is simplifying head output;
• specific contextual feed types provide no value;
• feeds are being disabled entirely.

Does RSS discovery affect SEO?

RSS discovery links are not a substitute for normal SEO architecture.

Search engines can discover content through:

• internal links;
• XML sitemaps;
• external backlinks;
• previous crawls;
• normal site navigation.

Removing RSS discovery does not automatically prevent pages from being indexed.

Likewise, keeping RSS discovery is not a significant ranking advantage by itself.

The decision should primarily reflect syndication requirements rather than attempts to manipulate rankings.

RSS feed discovery and XML sitemaps are different systems

Both may use XML-related technologies, but they solve completely different problems.

An RSS feed is primarily for syndicating content updates.

An XML sitemap primarily helps search engines discover canonical public URLs.

You should not disable an XML sitemap merely because RSS feeds are unnecessary.

For the sitemap side of the distinction, see What Is an XML Sitemap, and Why Does It Matter?.

Does removing discovery improve performance?

The performance impact is negligible.

A handful of <link> elements represents a very small amount of HTML.

Removing them will not materially change:

• Largest Contentful Paint;
• Interaction to Next Paint;
• server processing time;
• JavaScript execution;
• image loading;
• Core Web Vitals.

Feed discovery removal should therefore be considered markup cleanup, not a meaningful performance optimization.

Does removing feed discovery improve security?

Not in any substantial way by itself.

The discovery links reveal that feed endpoints exist, but WordPress feed URLs are predictable.

An automated scanner can simply try:

/feed/

without first reading the page head.

Removing the advertisement may reduce one passive discovery signal, but it does not secure the feed endpoint.

This follows the same principle as other WordPress discovery metadata: hiding information can reduce casual exposure without replacing actual access controls.

Does feed discovery contribute to WordPress fingerprinting?

RSS discovery markup can contribute a small signal indicating how a site is configured.

However, it is only one of many possible clues.

WordPress can often be identified through:

• asset paths;
• REST API behavior;
• login routes;
• generator information;
• XML-RPC;
• theme and plugin assets;
• other core-generated metadata.

Removing feed links alone does not meaningfully hide WordPress.

Can feed discovery expose authors?

Author feed links can make author archives and associated feed URLs easier to discover.

Whether that matters depends on how the website manages author identity.

A public editorial website may intentionally expose author archives.

A business site with a single administrative account may prefer to reduce unnecessary author-facing URLs.

That issue should be addressed as part of broader author archive and account exposure configuration rather than expecting RSS cleanup alone to solve it.

Can plugins add their own RSS discovery links?

Yes.

Removing WordPress’s core:

feed_links
feed_links_extra

does not guarantee the document contains no RSS-related markup.

A plugin, theme or custom integration can add its own:

<link rel="alternate" ...>

through:

• wp_head;
• theme templates;
• block rendering;
• custom hooks;
• direct HTML output.

Always inspect the rendered HTML rather than assuming one code snippet controls every possible source.

Can plugins create custom feeds?

Yes.

A plugin may register feeds for:

• podcast episodes;
• products;
• events;
• newsletters;
• custom datasets;
• third-party syndication systems.

Those feeds may use their own discovery mechanisms.

Core RSS cleanup should therefore not be confused with a complete inventory of every XML or syndication endpoint available on the site.

How WordPress feed URLs relate to permalink settings

With pretty permalinks enabled, WordPress commonly produces readable feed paths such as:

/feed/
/category/security/feed/

Other permalink configurations can produce query-based feed URLs.

The site should rely on WordPress’s URL-generation functions rather than hard-coding assumptions about the current permalink structure.

This is particularly important for themes and plugins that output feed links dynamically.

How to audit automatic feed discovery correctly

Start with a representative set of pages.

Check the homepage

Search the source for:

application/rss+xml

Record every result.

Check a single post

Look specifically for a comments feed associated with that individual post.

Check a category

Determine whether WordPress advertises the category-specific feed.

Check a tag

Repeat the same process.

Check an author archive

Determine whether an author feed is exposed.

Check search results

Search feeds are easily overlooked.

Check custom archives

Review custom taxonomies and post type archives.

Inspect the destination URLs as well

Discovery markup tells you what WordPress advertises.

It does not tell you whether those destinations actually function correctly.

For each relevant feed, test the URL directly.

For example:

Discovery:
<link href="https://example.com/feed/" ...>

Direct test:
GET https://example.com/feed/

A healthy configuration should align the two layers.

How TheOneWP handles RSS feed discovery

TheOneWP treats feed advertising separately from feed endpoint availability.

This distinction allows a site owner to remove WordPress’s automatic discovery markup without automatically shutting down RSS functionality that readers or integrations may still use.

When feed-link cleanup is enabled, the goal is to remove unnecessary discovery generated through WordPress’s normal head output while leaving the underlying feed system untouched unless feed disabling is configured separately.

This follows the same general approach TheOneWP uses for other WordPress discovery features:

• remove the advertisement when that is the actual requirement;
• disable functionality only when the underlying functionality itself is unwanted.

When should discovery and feed endpoints both be removed?

If the website has no legitimate use for RSS at all, keeping discovery while disabling endpoints makes little sense.

Likewise, keeping active endpoints that nobody uses may be unnecessary.

In that case, a complete feed shutdown can include:

1. removing automatic feed discovery;
2. disabling feed handlers;
3. reviewing plugin-defined feeds;
4. testing feed routes;
5. checking caches and CDN behavior.

See How to Disable RSS Feeds in WordPress for that broader configuration.

Common mistakes when auditing RSS discovery

Checking only /feed/

The primary feed is only one feed route.

Categories, authors, comments and other contexts may have their own feeds.

Checking only the homepage source

feed_links_extra() is contextual.

Other page types can advertise additional feeds.

Assuming removing feed_links disables RSS

It does not.

The endpoint can remain accessible.

Assuming feed URLs disappear when discovery is removed

A feed does not need to be advertised to exist.

Removing only feed_links()

This may leave contextual discovery from feed_links_extra().

Removing only feed_links_extra()

This can leave the general site and comments feeds advertised.

Hard-coding feed URLs in a theme

Use WordPress URL-generation functions so permalink changes remain compatible.

Using deprecated automatic_feed_links()

Modern themes should use:

add_theme_support( 'automatic-feed-links' );

Assuming all RSS markup comes from WordPress core

Themes and plugins can generate their own discovery elements.

Treating discovery removal as a major security feature

Feed endpoints remain predictable and potentially accessible.

Treating discovery removal as a performance optimization

The markup reduction is extremely small.

Disabling RSS without checking dependencies

Newsletter systems, automations and feed readers may still depend on it.

WordPress RSS feed discovery checklist

• Understand that feed discovery and feed endpoints are separate layers.
• Identify whether the active theme supports automatic-feed-links.
• Inspect the homepage for RSS discovery.
• Inspect the blog archive.
• Inspect a single post.
• Inspect a category archive.
• Inspect a tag archive.
• Inspect an author archive.
• Inspect search results.
• Inspect custom taxonomy archives.
• Inspect public post type archives.
• Search page source for application/rss+xml.
• Record which discovery links come from general feeds.
• Record which links are contextual.
• Understand the role of feed_links().
• Understand the role of feed_links_extra().
• Use granular filters where only selected discovery types should be hidden.
• Remember that removing discovery does not disable feeds.
• Test feed URLs directly after modifying discovery.
• Do not use deprecated automatic_feed_links() in new theme code.
• Check plugins and themes for custom RSS markup.
• Check for plugin-defined custom feeds.
• Do not confuse RSS feeds with XML sitemaps.
• Do not treat RSS discovery removal as meaningful performance optimization.
• Do not treat discovery removal as access control.
• Check integrations before disabling feeds completely.
• Clear page, server and CDN caches before verifying changes.
• Test several WordPress query contexts rather than only the homepage.
• Document whether the project hides feed discovery or disables feeds entirely.

Related guides

• Hiding vs. Disabling WordPress Feeds
• WordPress RSS Feed URLs Explained
• Disable RSS Feeds vs. Remove Feed Links
• Cleaning Up WordPress’s Default Head Output
• How to Disable RSS Feeds in WordPress

Final recommendation

WordPress’s default RSS advertising is a discovery system, not the feed system itself.

The distinction sounds minor until you start changing the configuration.

feed_links() advertises the site’s general feeds, while feed_links_extra() can advertise feeds specific to the current post, category, tag, taxonomy, author, search query or post type archive.

That means the exact discovery markup can change from one page to another.

If RSS is useful to readers or integrations, there is nothing inherently wrong with letting WordPress advertise those feeds automatically.

If the feeds need to remain functional but automatic discovery provides no value, remove or selectively filter the discovery layer while leaving the endpoints intact.

If RSS itself is unnecessary, then removing discovery is only half of the work. Disable the feed endpoints separately and verify that themes or plugins have not introduced additional feeds or discovery markup.

Most importantly, audit what WordPress actually outputs rather than assuming every page behaves like the homepage.

Check different query contexts, inspect the generated <head>, test the destination URLs and decide intentionally which feeds should be advertised, which should remain accessible without advertising, and which should not exist at all.

The cleanest configuration is not necessarily the one with the fewest <link> tags. It is the one where WordPress advertises exactly the syndication features the website genuinely intends to provide.