Open the Page indexing report on a WordPress site and sort the not-indexed URLs by pattern rather than by count. On a good number of them a whole block of rows ends in /feed/. The site owner did not create those URLs, does not know what they are, and reasonably assumes something is broken.
Nothing is broken. This is one of the few report patterns where the correct response is to read it once, understand it, and leave it alone.
Where the URLs come from
WordPress ships feeds as core functionality, not as a plugin feature. The WordPress feeds documentation lists what comes built in: an RDF/RSS 1.0 feed, RSS 0.92, RSS 2.0, Atom, and a comments RSS 2.0 feed that carries only comments and none of your content. Themes expose them through bloginfo() and most themes link at least one of them from the head or the footer.
That is the part people know about. The part that produces the row count is that the same machinery applies per object. Every post can have its own comments feed through post_comments_feed_link(). Every category, tag, author and search result has a feed URL too, because feeds hang off the query, not off a fixed list of pages.
So a site with 60 posts, 12 categories and 90 tags is not publishing one feed. It is publishing a feed for each of those things, all returning valid XML with a 200 status, all linked from somewhere in the theme. Google finds them, fetches them, and then has to decide what to do with an XML document whose entire content is a copy of pages it already has.
The answer it usually reaches is crawled, currently not indexed: fetched successfully, not selected for the index. Which is correct. A feed is not a page a searcher wants.
Which status you get, and what each one means
Three appear, and they mean different things.
Crawled, currently not indexed. The usual one. Google fetched the feed and chose not to index it. This is the intended outcome. There is nothing to fix and no benefit to be had from fixing it.
Duplicate without user-selected canonical. Turns up when the feed’s content is close enough to a page Google already holds. Also fine on a feed, though it is worth checking that the same status is not also appearing on your actual posts, where it means something entirely different. That case I covered separately in duplicate without user-selected canonical.
Indexed. Rare and worth a look. A feed URL sitting in the index is usually a sign the site is linking to it prominently, or that an external aggregator picked it up. Even then it is cosmetic rather than harmful.
What none of these are is a quality signal about your site. Google is not counting your feeds against you. It is doing the same triage on them that you would.
The fix people reach for, and why it backfires
The instinct is to disallow /feed/ in robots.txt. It stops the crawling, the rows stop appearing, the report goes quiet.
It also converts a harmless status into a worse one. A disallowed URL that something links to can be indexed from the link alone, and now you have feed URLs in Google with no snippet instead of feed URLs cleanly excluded from it. You have also made the situation permanent, because Google can no longer fetch the URL to reconsider it.
If a feed genuinely must be gone, the tool is an X-Robots-Tag: noindex header on the feed response, which works on XML where a meta tag cannot. Google’s block indexing documentation covers the header form. That is a real fix for a real reason, such as a comments feed leaking content from a members area. It is not a fix for a report that looks untidy.
Disabling feeds entirely is the other option some plugins offer, and it is the one I argue against most often. Feeds are how readers subscribe, how aggregators pull posts, and how a number of syndication integrations work. Turning off a working feature to change a number in a report you did not have to read is not a trade worth making.
Seven impressions, and what they told me
This one came out of my own Search Console data rather than from a client. Across 1 to 28 August 2026 this site picked up 7 impressions for the query crawled+currently+not+indexed+feed, sitting at an average position of 90. Seven impressions is nothing as traffic. As evidence it is quite specific: people are typing the exact three-word status and the word feed together, which means they are looking at the report, they have already worked out the rows share a pattern, and the answer they are getting is a page about the status in general rather than about their feeds.
That gap is the whole reason this post exists. The generic answer to crawled-currently-not-indexed is about page quality and crawl budget, and applying it to a feed URL sends someone off to improve content on a file that is not content.
The one thing worth doing is a count. If feed rows are a handful, ignore them. If they run into the hundreds on a small site, that is not a feed problem either, it is a taxonomy problem showing up through the feeds, because each of those URLs implies a category or tag archive behind it. The archives are the thing to look at, and the decision there is a different one, which I set out in should you noindex WordPress category and tag pages.
Sources
- WordPress Advanced Administration Handbook, WordPress Feeds, for the built-in feed types and the per-post comments feed, checked 29 August 2026
- Google Search Console Help, Page indexing report, for the crawled-currently-not-indexed and duplicate reasons, checked 29 August 2026
- Google Search Central, block search indexing with noindex, for the X-Robots-Tag header on non-HTML responses
- Google Search Console, performance data for sc-domain:shahidali.co, 1 to 28 August 2026, for the query figure quoted above