Disable RSS feeds vs remove feed links

Disable RSS feeds vs remove feed links describes two very different WordPress changes that are often treated as though they were the same thing.

They are not.

Removing RSS feed links from the HTML document head changes how feeds are advertised and discovered.

Disabling RSS feeds changes whether the actual feed endpoints return feed content.

The difference can be summarized as:

Remove feed links
→ stop advertising feeds

Disable RSS feeds
→ stop serving feeds

If you remove:

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

from the page source, a visitor or application can still request:

https://example.com/feed/

directly.

If that URL still returns RSS, the feed has not been disabled.

This guide explains how both layers work, which WordPress functions control them, when you should remove only the discovery links, when actual feed endpoints should be disabled, how to test each configuration and how the separate TheOneWP Disable RSS Feed Links and TheOneWP Disable RSS Feeds modules handle the distinction.

Quick answer

Configuration	RSS links in HTML	Feed URLs
Default WordPress	Present where supported	Available
Remove feed links only	Removed	Still available
Disable feed endpoints only	May still be present	Disabled
Complete feed shutdown	Removed	Disabled

The most important rule is:

Feed discovery
≠
feed availability

What is a WordPress RSS feed?

WordPress can expose published content through machine-readable syndication feeds.

The main feed is commonly available at:

https://example.com/feed/

but WordPress can generate many additional feed URLs.

Examples include:

/feed/
/comments/feed/
/category/news/feed/
/tag/wordpress/feed/
/author/jane/feed/
/search/security/feed/

Custom taxonomies and public custom post-type archives can also have feed URLs depending on how they are registered.

For a detailed URL map, see WordPress RSS Feed URLs Explained.

WordPress supports several feed formats

WordPress Core includes handlers for formats such as:

RSS 0.92
RSS 2.0
RDF / RSS 1.0
Atom

The feed requested by a URL is ultimately processed through WordPress feed handling.

Feeds have two separate layers

To understand the comparison properly, think of WordPress RSS as two systems.

Layer 1: discovery

HTML page
↓
<link rel="alternate">
↓
feed URL advertised

Layer 2: delivery

request /feed/
↓
WordPress recognizes feed request
↓
feed handler runs
↓
RSS or Atom content returned

You can modify one layer without modifying the other.

What are WordPress RSS feed links?

WordPress can insert feed-discovery elements into the page’s <head>.

A typical example looks like:

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

Another can advertise the comments feed:

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

What does rel=”alternate” mean here?

The page tells software:

This HTML document
has an alternative
syndication representation.

Applications can inspect these tags instead of guessing where the feed might live.

This is RSS autodiscovery

Feed readers, browsers, crawlers and other applications can use the metadata to discover feeds automatically.

For the broader WordPress behavior, see How WordPress Advertises RSS Feeds by Default.

What generates the normal feed links?

Two important WordPress Core functions are:

feed_links()
feed_links_extra()

The official feed_links() documentation describes the function that outputs links to the general feeds.

The official feed_links_extra() documentation covers contextual feeds.

feed_links() handles the general discovery links

Current WordPress can use it for:

• the main posts feed;
• the general comments feed.

feed_links_extra() handles contextual discovery

Depending on the current request, it can advertise feeds related to:

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

Automatic feed links depend on theme support

The general feed-link function checks whether the current theme supports:

automatic-feed-links

Classic themes commonly enable this using:

add_theme_support(
    'automatic-feed-links'
);

The official add_theme_support() documentation identifies this feature as automatic output of post and comment RSS links in the document head.

Block themes behave slightly differently

Current WordPress automatically enables automatic feed-link support for block themes.

This is another reason not to assume that the absence or presence of one line in a classic theme’s functions.php tells you the complete feed configuration.

Do not use automatic_feed_links() in new code

The older:

automatic_feed_links()

function is deprecated.

The official automatic_feed_links() documentation directs developers toward:

add_theme_support(
    'automatic-feed-links'
);

instead.

What does removing feed links actually do?

Suppose your homepage originally contains:

<head>

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

</head>

You remove the feed discovery output.

The HTML becomes:

<head>

    ...

</head>

The result is:

automatic feed discovery
→ reduced or removed

but:

https://example.com/feed/
→ can still work normally

Removing the feed link does not change routing

It does not normally change:

• WordPress rewrite rules;
• feed query parsing;
• feed templates;
• RSS generation;
• known feed URLs.

Removing discovery is comparable to taking down a sign

Imagine a building with a public entrance.

Removing the sign that points to the entrance does not brick up the door.

The relationship is:

Feed link
→ sign

Feed URL
→ door

You can remove the sign while leaving the door completely functional.

How to remove the standard WordPress feed links

A common implementation removes the corresponding callbacks from wp_head:

add_action(
    'after_setup_theme',
    function () {

        remove_action(
            'wp_head',
            'feed_links',
            2
        );

        remove_action(
            'wp_head',
            'feed_links_extra',
            3
        );
    }
);

Why do the priorities matter?

WordPress’s hook system identifies a callback partly by the priority at which it was registered.

If Core registered:

feed_links
→ priority 2

then attempting:

remove_action(
    'wp_head',
    'feed_links',
    10
);

does not target the same registration.

The official remove_action() documentation explains that the hook, callback and priority need to correspond to the registered action.

Why use after_setup_theme?

You want the removal to occur after the theme has had an opportunity to declare its support and before the frontend head is rendered.

A site-specific implementation can therefore remove the resulting head callbacks without editing the active theme’s files.

Do not edit WordPress Core

Do not remove the callbacks by editing:

wp-includes/default-filters.php

or other Core files.

WordPress updates can overwrite Core modifications, and the hook system already provides the extension mechanism you need.

For the broader topic, see Cleaning Up WordPress’s Default Head Output.

Removing both callbacks is the broad discovery cleanup

This combination:

remove_action(
    'wp_head',
    'feed_links',
    2
);

remove_action(
    'wp_head',
    'feed_links_extra',
    3
);

removes the standard general and contextual feed autodiscovery output generated through those Core callbacks.

You can also remove individual feed-link types more selectively

Modern WordPress includes filters for controlling specific discovery links.

For the main posts feed:

feed_links_show_posts_feed

For the global comments feed:

feed_links_show_comments_feed

Example: hide only the posts-feed discovery link

add_filter(
    'feed_links_show_posts_feed',
    '__return_false'
);

Example: hide only the general comments feed link

add_filter(
    'feed_links_show_comments_feed',
    '__return_false'
);

Contextual feed links have granular filters too

Current WordPress provides filters including:

feed_links_extra_show_post_comments_feed
feed_links_extra_show_post_type_archive_feed
feed_links_extra_show_category_feed
feed_links_extra_show_tag_feed
feed_links_extra_show_tax_feed
feed_links_extra_show_author_feed
feed_links_extra_show_search_feed

For example:

add_filter(
    'feed_links_extra_show_category_feed',
    '__return_false'
);

can suppress category-feed discovery without globally removing every contextual feed link.

Granular discovery control can be better than removing everything

Suppose the site wants:

Main posts feed
→ advertised

Category feeds
→ not advertised

Author feeds
→ not advertised

Using the dedicated filters makes the intention clearer than disabling the complete feed_links_extra() output.

But those filters still do not disable the feed URLs

This:

add_filter(
    'feed_links_extra_show_category_feed',
    '__return_false'
);

does not make:

/category/news/feed/

stop working.

It prevents WordPress from advertising that feed through its standard contextual head output.

What does disabling RSS feeds mean?

Disabling feeds changes the behavior of actual feed requests.

Instead of:

GET /feed/

→ 200 OK
→ application/rss+xml
→ RSS content

a disabled implementation might produce:

GET /feed/

→ 404 Not Found

or another intentionally selected response.

That is an endpoint-level change

The distinction is:

Remove link
→ change HTML discovery

Disable feed
→ change HTTP endpoint behavior

How WordPress processes feed requests

WordPress Core uses:

do_feed()

to determine the requested feed type and invoke the corresponding feed action.

The official do_feed() documentation lists dynamic actions such as:

do_feed_atom
do_feed_rdf
do_feed_rss
do_feed_rss2

RSS2 uses its own handler

WordPress provides:

do_feed_rss2()

The official do_feed_rss2() documentation shows that the function loads either:

• the normal RSS2 posts feed template;
• the RSS2 comments feed template.

The same feed action can therefore cover both normal and comment-feed requests depending on the query context.

A basic feed-disabling example

A simple application-level implementation can intercept the native feed actions before Core’s normal template handlers run:

function project_disable_feed() {

    wp_die(
        esc_html__(
            'Feeds are disabled on this website.',
            'project'
        ),
        '',
        array(
            'response' => 404,
        )
    );
}

add_action(
    'do_feed_rdf',
    'project_disable_feed',
    1
);

add_action(
    'do_feed_rss',
    'project_disable_feed',
    1
);

add_action(
    'do_feed_rss2',
    'project_disable_feed',
    1
);

add_action(
    'do_feed_atom',
    'project_disable_feed',
    1
);

Why priority 1?

The objective is to respond before the normal feed-rendering callback executes.

The sequence becomes:

feed requested
↓
dynamic feed action fires
↓
custom priority-1 handler runs
↓
404 returned
↓
normal feed template never renders

This disables more than /feed/

Because WordPress routes many different feed contexts through the same feed-format handlers, the approach is broader than writing a rewrite rule only for:

/feed/

Blocking only /feed/ is usually incomplete

A site may also have:

/comments/feed/
/category/news/feed/
/tag/security/feed/
/author/jane/feed/
/search/wordpress/feed/

If your code blocks only:

^/feed/$

many other WordPress feed routes may remain available.

Do not forget alternate feed formats

Testing only:

/feed/

normally verifies the site’s default feed behavior.

It does not necessarily prove every supported feed format has been addressed.

The feed handlers worth reviewing include:

RSS
RSS2
RDF
Atom

What response should a disabled feed return?

If a feed has deliberately ceased to exist, an HTTP:

404 Not Found

is a straightforward choice.

The resource is no longer being provided.

Some implementations redirect instead

You may see configurations such as:

/feed/
↓
301
↓
/

or:

/category/news/feed/
↓
301
↓
/category/news/

Redirecting every feed to the homepage is usually semantically weak

A request for:

/category/security/feed/

is not really equivalent to:

/

A blanket homepage redirect can obscure what actually happened to the requested resource.

Choose the response deliberately

The implementation should answer:

Does this feed no longer exist?

Has it moved somewhere equivalent?

Is there a replacement resource?

rather than redirecting everything because redirects superficially look friendlier.

Complete shutdown normally means both layers

If your objective is:

This site should not expose
WordPress RSS feeds

then a complete implementation usually needs:

disable endpoints
+
remove discovery links

Why remove discovery if endpoints already return 404?

Otherwise your HTML can advertise URLs that immediately fail.

For example:

<link
    rel="alternate"
    type="application/rss+xml"
    href="/feed/"
/>

followed by:

GET /feed/
→ 404

creates contradictory discovery metadata.

Why disable endpoints if the links are already removed?

Because feed URLs are predictable.

Existing subscribers, bots, external applications or users can already know:

/feed/

and request it directly.

Removing discovery does not make a public endpoint secret

This is the same general architectural distinction seen elsewhere in WordPress:

remove REST discovery
≠
disable REST API

remove RSD link
≠
disable XML-RPC

remove RSS link
≠
disable RSS

Comparison: remove RSS feed links only

Use this approach when your objective is primarily:

clean up frontend head output
while keeping feeds functional

Typical effects:

• standard feed autodiscovery markup disappears;
• existing feed subscribers continue working;
• direct feed URLs continue working;
• syndication integrations continue working;
• feed readers can still use a known URL.

Comparison: disable RSS feeds only

Use this when your objective is:

stop feed delivery

but you have not yet cleaned up HTML discovery.

Effects:

• feed endpoints stop returning normal feeds;
• existing integrations may fail;
• head markup can still advertise feed URLs;
• users may discover links that lead to disabled endpoints.

Technically possible, but usually incomplete if feeds are meant to be removed entirely.

Comparison: disable feeds and remove feed links

This is the coherent configuration when the site intentionally does not provide feeds.

HTML discovery
→ removed

direct feed requests
→ disabled

TheOneWP Disable RSS Feeds follows this broader model: it blocks the native RSS, RSS2, RDF and Atom feed actions with HTTP 404 behavior and also removes the standard feed-discovery links.

Comparison: keep everything enabled

Do not assume that RSS needs to be removed simply because it is old technology.

A site that uses feeds for:

• readers;
• news aggregation;
• content syndication;
• automation;
• newsletter ingestion;
• monitoring;
• internal integrations;

can reasonably keep them available and discoverable.

When should you remove feed links but keep feeds?

This configuration makes sense when:

• known feed consumers should continue working;
• you want less machine-discovery markup in the page head;
• the site has integrations using fixed feed URLs;
• you do not want to break existing RSS subscribers;
• automatic browser or crawler discovery is unnecessary.

Example

Newsletter service
→ imports /feed/

Existing feed readers
→ subscribe to /feed/

Frontend HTML
→ no RSS autodiscovery

This is a valid configuration.

When should you disable feeds completely?

A full shutdown can be appropriate when:

• the site does not use RSS syndication;
• no external integrations depend on feeds;
• no readers are expected to subscribe;
• the site intentionally minimizes unused public interfaces;
• the organization has another content-distribution architecture.

Audit dependencies before disabling feeds

Check for systems such as:

• email newsletter platforms;
• Zapier-style automations;
• content aggregators;
• mobile applications;
• social publishing tools;
• external search systems;
• internal dashboards;
• podcast or publishing workflows;
• legacy RSS readers.

Existing feed requests can be invisible to editors

A site owner may reasonably say:

"We don't use RSS."

while a server access log shows:

/feed/
→ requested every hour

by a legitimate integration nobody remembered was configured.

Review logs when the consequences matter

Before permanently disabling a longstanding public feed, consider checking:

request URL
user agent
request frequency
referer where available
response status

This can reveal dependencies that are not visible inside WordPress itself.

Removing feed links has a lower compatibility risk

If you only remove discovery tags:

known clients
→ keep working

because the endpoint remains available.

That makes discovery cleanup less disruptive than endpoint shutdown.

Disabling feeds can break real integrations

Once:

/feed/

stops returning RSS, any consumer expecting that data can fail.

The change should therefore be treated as functionality removal rather than cosmetic cleanup.

Does removing feed links improve security?

Not meaningfully by itself.

If:

/feed/

is still public, removing:

<link rel="alternate">

does not create access control.

Feed URLs are predictable

Anyone familiar with WordPress can try common paths such as:

/feed/
/comments/feed/

without first reading your HTML.

Discovery removal is not authorization

The conceptual distinction is:

discovery
→ how software finds something

availability
→ whether it responds

authorization
→ who is allowed to use it

Removing a discovery tag addresses only the first layer.

Does disabling feeds prevent scraping?

No.

It removes one convenient machine-readable content source.

But if articles are publicly available as HTML:

public web page
→ still scrapeable

Do not sell RSS shutdown as anti-scraping protection

Automated systems can retrieve public webpages directly.

Feed removal may change how convenient content extraction is, but it does not make public content private.

Does removing RSS links improve performance?

The amount of HTML removed is tiny.

For example:

two small <link> elements

are not a meaningful frontend performance problem on a normal WordPress site.

Do not disable feeds for speed alone

When WordPress serves a normal HTML page, it does not need to generate and transfer the complete RSS feed simply because the page contains a feed-discovery link.

The link is metadata.

A feed request itself does require processing

When a client explicitly requests:

/feed/

WordPress processes the feed query and renders the corresponding output.

If the site receives significant unnecessary feed traffic, disabling an unused feed can reduce that workload.

But this is different from claiming that deleting two head tags materially accelerates ordinary page rendering.

Does WordPress Reading Settings disable RSS?

No.

WordPress includes feed-related settings under:

Settings
→ Reading

such as the number of syndication items and whether a feed displays:

full text
or
excerpt

Those settings configure feeds.

They do not mean:

disable the feed system

Showing excerpts does not secure feed content

This setting:

For each post in a feed,
include: Excerpt

changes what the feed contains.

It does not stop the feed from being public.

Setting the feed item count low does not disable feeds

Likewise, reducing:

Syndication feeds show the most recent

does not disable the endpoint.

Does robots.txt disable RSS feeds?

No.

A robots.txt directive can tell compliant crawlers not to crawl selected URLs.

It does not provide HTTP access control.

A user can still request the feed directly unless the endpoint itself is changed.

Do not use robots.txt as a substitute for endpoint shutdown

The difference is:

robots.txt
→ crawler instruction

disabled feed
→ application response

RSS feeds are not XML sitemaps

These are separate machine-readable resources.

RSS
→ syndication / content updates

XML sitemap
→ URL discovery for search engines

Disabling RSS does not mean you should disable your sitemap.

Removing RSS autodiscovery does not remove sitemap discovery either.

RSS is not the WordPress REST API

Likewise:

/feed/

and:

/wp-json/

belong to different systems.

Disabling RSS does not automatically disable:

• REST API routes;
• Block Editor communication;
• API authentication;
• plugin REST endpoints.

RSS is not XML-RPC

Disabling feeds does not automatically affect:

/xmlrpc.php

and removing RSS discovery does not remove XML-RPC discovery or functionality.

Comments and comments feeds are separate concerns

WordPress can provide:

• a site-wide comments feed;
• per-post comments feeds.

A site may reasonably want:

Posts RSS
→ enabled

Comments RSS
→ disabled

or the opposite policy depending on its publishing model.

Disabling comments does not automatically describe every feed decision

Even when new comments are disabled, historical comment data may still exist.

If the objective is to remove discussion functionality comprehensively, review comments and comments feeds separately.

TheOneWP Disable Comments addresses the broader comments system rather than pretending that an RSS setting controls all discussion functionality.

How to inspect current RSS discovery links

Open the public page source.

Search for:

application/rss+xml

or:

rel="alternate"

Example discovery markup

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

Inspect more than the homepage

Because feed_links_extra() is contextual, inspect:

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

A homepage test is not enough

You might remove:

general feed link

while still exposing:

category feed discovery
author feed discovery
post comments feed discovery

on other page types.

How to test whether the feed itself is still available

Request the endpoint directly.

For example:

curl -i \
    https://example.com/feed/

Enabled feed example

HTTP/2 200
Content-Type: application/rss+xml

followed by XML content.

Disabled feed example

HTTP/2 404

or whatever response your implementation deliberately uses.

Test both discovery and endpoint behavior

A correct verification sequence is:

1. Inspect page source.

2. Search for RSS discovery links.

3. Request /feed/ directly.

4. Check HTTP status.

5. Check response body.

6. Test comments feed.

7. Test contextual feeds.

8. Test alternate feed formats
   where relevant.

Test the main feed

https://example.com/feed/

Test the comments feed

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

Test a category feed

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

Test a tag feed

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

Test an author feed

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

Test a search feed when relevant

WordPress can also generate feeds for search requests.

The exact URL depends on permalink and query structure, so test the actual URL returned by WordPress rather than inventing assumptions around one installation.

Use get_feed_link() when you need the generated URL

WordPress provides:

get_feed_link()

The official get_feed_link() documentation returns the permalink associated with a feed type.

For example:

$rss2 =
    get_feed_link(
        'rss2'
    );

$atom =
    get_feed_link(
        'atom'
    );

Do not hardcode feed URLs unnecessarily

WordPress can operate with different permalink configurations.

Use Core URL-generation functions when writing code that needs to discover the site’s actual feed structure.

Permalink structure can change feed URL appearance

With pretty permalinks, you commonly see:

/feed/

Without them, feed access can also use query parameters.

This is another reason endpoint handlers are generally more comprehensive than blocking one literal URL path.

What if a plugin registers its own feed?

WordPress allows custom feeds to be registered using:

add_feed()

A plugin can therefore create a feed name beyond the standard Core formats.

Standard RSS shutdown code may not cover custom plugin feeds

If the website contains plugins or custom code that register additional feeds, audit them separately.

The question is not only:

Did I disable Core RSS2?

It is:

Which feed endpoints
does this specific site expose?

Custom feeds can be application dependencies

A plugin-defined feed may exist specifically for:

• product exports;
• syndication partners;
• mobile applications;
• custom publishing workflows.

Do not block it merely because its URL happens to contain the word:

feed

Server-level blocking vs WordPress-level disabling

You can theoretically block feed paths at:

• CDN;
• reverse proxy;
• Nginx;
• Apache;
• WordPress application layer.

Application-level blocking understands WordPress feed routing

Using the feed actions means WordPress has already classified the request as a feed request.

This can cover several WordPress feed URL patterns without manually maintaining a list of every path.

Server-level rules run earlier

A server or edge rule can stop the request before WordPress executes.

That may be useful for:

• very high unwanted traffic;
• infrastructure-controlled policies;
• sites where feed access should never reach PHP.

But server rules can be easier to get wrong

A broad regex containing:

feed

might also affect legitimate URLs unrelated to WordPress syndication.

Define rules around the site’s actual routing.

Removing discovery through CSS does nothing

You cannot hide:

<link rel="alternate">

using visual CSS in any meaningful way because it is metadata inside:

<head>

rather than visible page content.

Remove the corresponding WordPress callback instead.

JavaScript removal is also the wrong layer

This approach:

load page
↓
JavaScript finds link element
↓
JavaScript removes it

is inferior to preventing the server from outputting it in the first place.

Machine clients can inspect the original HTML before or without running your JavaScript.

Remove discovery server-side

Use:

WordPress hooks
→ no tag generated

rather than:

generate unwanted tag
→ remove in browser later

Do not remove automatic-feed-links theme support solely to disable feeds

Removing:

automatic-feed-links

changes automatic discovery output.

It does not itself disable feed routing.

Theme support belongs to the discovery layer

Think of:

automatic-feed-links
→ should the theme advertise feeds?

do_feed_* handlers
→ what happens when feed requested?

Do not confuse feed-link removal with noindex

A feed discovery link is not equivalent to:

<meta
    name="robots"
    content="noindex"
>

They serve different purposes.

Do not add nofollow to solve RSS availability

A rel="alternate" feed-discovery link is metadata describing another representation.

Adding arbitrary:

nofollow

does not replace proper feed configuration.

Does removing RSS links affect SEO?

Removing RSS autodiscovery generally changes syndication discovery rather than normal HTML-page indexing architecture.

It does not remove:

• canonical URLs;
• XML sitemaps;
• normal internal links;
• page titles;
• structured data;
• indexable HTML content.

Do not market RSS-link removal as a major SEO optimization

A website with substantial technical SEO problems will not suddenly become healthy because two RSS discovery tags disappeared.

Feed behavior can still matter operationally

For example, unwanted feeds can:

• create additional crawlable URLs;
• serve content to aggregators;
• support legacy integrations;
• generate server traffic.

Whether that matters depends on the website.

Changing feed policy on an established site

Before:

Feeds enabled for 10 years

After:

all feeds return 404

is a bigger change than:

remove HTML discovery links

because existing external subscribers can already know the feed URLs.

A staged migration can be sensible

For an uncertain environment:

Phase 1
→ remove discovery links

Phase 2
→ monitor feed requests

Phase 3
→ identify legitimate consumers

Phase 4
→ disable feeds if safe

This gives you more information before removing functionality.

Keep feeds if they have a real job

RSS remains useful when the site needs a simple, open and standardized stream of recently published content.

Do not remove functioning infrastructure solely because it looks old.

Disable feeds if they have no job

If:

• nobody subscribes;
• no integration consumes them;
• no automation uses them;
• the organization does not want syndicated copies;

then disabling them can simplify the site’s public surface.

How TheOneWP separates the two behaviors

TheOneWP provides two intentionally different modules.

Disable RSS Feed Links

TheOneWP Disable RSS Feed Links targets feed discovery.

The verified implementation removes:

feed_links
from wp_head
at priority 2

and:

feed_links_extra
from wp_head
at priority 3

It does not alter the feed endpoints

The module changes:

HTML discovery
→ removed

while leaving:

/feed/
→ operational

unless some other site configuration changes it.

That distinction is intentional

The module is appropriate when the objective is:

do not advertise feeds
but keep them available

Disable RSS Feeds

TheOneWP Disable RSS Feeds addresses the endpoint layer as well.

The verified implementation intercepts the standard native feed actions for:

RSS
RSS2
RDF
Atom

at an early priority and returns an HTTP:

404

instead of normal feed output.

The module also removes standard discovery links

This produces the complete shutdown model:

feed links
→ removed

feed endpoints
→ 404

The two modules solve different requirements

Behavior	Disable RSS Feed Links	Disable RSS Feeds
Remove standard RSS discovery links	Yes	Yes
Keep native feed endpoints working	Yes	No
Block RSS	No	Yes
Block RSS2	No	Yes
Block RDF	No	Yes
Block Atom	No	Yes
Return 404 for native feeds	No	Yes
Change published posts	No	No

The content itself remains unchanged

Neither operation requires deleting:

• posts;
• comments;
• categories;
• tags;
• authors;
• custom post types.

The changes affect feed discovery and/or feed delivery.

Which one should you use?

Use discovery removal when your requirement is:

"I don't want WordPress
advertising RSS feeds
inside the page head."

Use feed disabling when your requirement is:

"I don't want WordPress
serving RSS or Atom
feed content at all."

Do not choose based on the module names alone

Choose based on the intended HTTP behavior.

Ask:

If somebody manually visits /feed/,
what should happen?

If the answer is:

"The RSS feed should load."

remove discovery only.

If the answer is:

"The RSS feed should not exist."

disable the feed endpoint too.

Testing remove-feed-links configuration

After enabling discovery cleanup:

1. Clear page cache.

2. Clear server cache.

3. Clear CDN cache where necessary.

4. Open homepage source.

5. Search for application/rss+xml.

6. Inspect a single post.

7. Inspect category archive.

8. Request /feed/ directly.

Expected result

HTML RSS discovery
→ absent

/feed/
→ still returns feed

Testing disabled-feed configuration

After disabling feeds:

1. Clear caches.

2. Request /feed/.

3. Check status.

4. Request /comments/feed/.

5. Check category feed.

6. Check tag feed.

7. Check author feed.

8. Check Atom where relevant.

9. Inspect frontend HTML.

10. Confirm discovery links are gone.

Expected result for a complete shutdown

HTML RSS discovery
→ absent

native feed request
→ 404

Cache can confuse testing

A page cache can continue serving old HTML containing:

<link rel="alternate">

after the server-side configuration has changed.

Feed responses can also be cached

A CDN or full-page cache may temporarily continue returning an old successful feed response.

When testing, inspect:

• HTTP status;
• cache headers;
• response body;
• origin behavior where necessary.

Do not test only while logged into WordPress

Some cache systems bypass caches for authenticated administrators.

You might see:

new behavior
while logged in

but anonymous users and crawlers receive:

old cached behavior

Use curl for an anonymous request

curl -i \
    https://example.com/feed/

and inspect the real public response.

Common mistake: removing feed links and claiming RSS is disabled

This is the main error.

feed_links removed
≠
feed endpoint removed

Common mistake: disabling feeds but leaving discovery tags

This creates HTML that advertises broken resources.

Common mistake: blocking only /feed/

WordPress has many contextual feed URLs.

Common mistake: forgetting comments feeds

Main post feeds and comment feeds can use the same format handlers in different query contexts.

Common mistake: forgetting Atom, RDF or legacy RSS

Blocking only the default RSS2 route may not express a full feed shutdown.

Common mistake: forgetting plugin-defined feeds

Custom feeds registered by extensions need a separate audit.

Common mistake: using automatic_feed_links()

The function is deprecated for new implementations.

Common mistake: modifying WordPress Core

Use:

hooks
filters
actions

rather than editing Core files.

Common mistake: treating head cleanup as access control

A missing discovery tag does not make the resource private.

Common mistake: treating robots.txt as feed shutdown

robots.txt instructs compliant crawlers. It does not disable endpoint access.

Common mistake: calling feed removal a major security improvement

It can reduce unused public functionality, but it does not replace actual WordPress security controls.

Common mistake: calling feed removal anti-scraping protection

Public HTML remains available.

Common mistake: disabling RSS without checking newsletters

RSS-to-email systems frequently depend directly on feed URLs.

Common mistake: forgetting automation platforms

A simple feed can power surprisingly important workflows that nobody remembers until Monday morning, humanity’s preferred time for rediscovering undocumented infrastructure.

Common mistake: assuming no visible RSS button means no RSS consumers

Feed consumers do not require a visible frontend RSS button.

Common mistake: testing only the homepage

Contextual discovery links can appear on archive and singular pages.

Common mistake: testing only in the browser

Use HTTP tools to verify status codes and response bodies directly.

Common mistake: ignoring response semantics

A disabled endpoint returning:

200 OK
+
"Feeds disabled"

is not the same as returning an appropriate error status.

Common mistake: redirecting every feed to the homepage

The homepage is generally not an equivalent representation of every feed URL.

Common mistake: confusing RSS with the REST API

They are separate interfaces.

Common mistake: confusing RSS with XML sitemaps

They serve separate discovery purposes.

Common mistake: changing feed settings without documenting why

Future maintainers should know whether the site intentionally:

keeps feeds

hides discovery

disables feeds

or
uses a custom feed architecture

Disable RSS feeds vs remove feed links checklist

• Define whether the objective is discovery cleanup or endpoint shutdown.
• Understand that feed links and feed endpoints are separate systems.
• Check whether the active theme supports automatic feed links.
• Remember that block themes enable automatic feed-link support automatically.
• Do not use deprecated automatic_feed_links() in new code.
• Understand the role of feed_links().
• Understand the role of feed_links_extra().
• Use remove_action() with the correct priority.
• Use granular feed-link filters when only selected discovery types should be hidden.
• Do not assume discovery filters disable feed URLs.
• Understand the role of do_feed().
• Review do_feed_rss.
• Review do_feed_rss2.
• Review do_feed_rdf.
• Review do_feed_atom.
• Choose an intentional HTTP response for disabled feeds.
• Do not block only the main /feed/ URL.
• Check the site-wide comments feed.
• Check per-post comment feeds where relevant.
• Check category feeds.
• Check tag feeds.
• Check author feeds.
• Check search feeds.
• Check custom taxonomy feeds.
• Check custom post-type archive feeds.
• Audit plugin-defined custom feeds.
• Check newsletter integrations.
• Check automation systems.
• Check content aggregators.
• Check external applications.
• Check server logs when dependencies are uncertain.
• Do not confuse Reading Settings with feed disabling.
• Do not confuse excerpt mode with feed security.
• Do not use robots.txt as access control.
• Do not treat RSS and REST as the same interface.
• Do not treat RSS and XML-RPC as the same interface.
• Do not treat RSS and XML sitemaps as the same resource.
• Do not describe discovery-link removal as a major performance optimization.
• Do not describe RSS shutdown as complete anti-scraping protection.
• Clear page cache before testing.
• Clear server cache where relevant.
• Clear CDN cache where relevant.
• Test anonymously.
• Inspect HTML source.
• Inspect HTTP status codes.
• Inspect the response body.
• Document the site’s intended RSS policy.

Related guides

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

Final recommendation

Do not treat RSS feed discovery and RSS feed delivery as one setting.

The clean mental model is:

feed_links()
feed_links_extra()
→ discovery layer


do_feed_*
→ delivery layer

If you only want cleaner frontend markup while preserving existing subscribers and integrations, remove the standard feed discovery links and leave the endpoints alone.

HTML discovery
→ removed

/feed/
→ still works

If the site genuinely should not expose native WordPress feeds, disable the actual feed handlers as well.

HTML discovery
→ removed

/feed/
→ disabled

Before doing that, audit the website for newsletters, aggregators, feed readers, automation platforms and custom integrations. RSS infrastructure is easy to overlook precisely because it often works quietly for years without anybody opening its settings page.

TheOneWP Disable RSS Feed Links is designed for the first use case. It removes WordPress’s standard feed_links and feed_links_extra head output while leaving feed generation untouched.

TheOneWP Disable RSS Feeds is designed for the second. It blocks the standard native RSS, RSS2, RDF and Atom feed handlers with HTTP 404 responses and also removes the normal feed-discovery links so the site’s HTML does not continue advertising endpoints that have been intentionally disabled.

The practical question is therefore not simply:

"Do I want RSS links?"

It is:

"Should applications still
be able to retrieve RSS
when they already know
the feed URL?"

That answer determines whether you need discovery cleanup, endpoint shutdown or both.