Make WordPress Core

Opened 2 years ago

Last modified 8 months ago

#56883 new defect (bug)

Feeds of non-existent tags and categories displays an empty feed instead of 404

Reported by: rafaucau's profile rafaucau Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 6.0.3
Component: Feeds Keywords:
Focuses: template, performance Cc:

Description

I noticed in Google Search Console that Google often visits feeds of tags that no longer exist. It turns out that the RSS feeds still work instead of returning a 404.

Recreating the issue is simple:
Go to the page of the non-existent tag, e.g. /tag/asdsdsad/ and append feed/ to the end of the address, eg. /tag/asdsdsad/feed/. An empty feed will be displayed instead of a 404.

This should return a 404 so that search engine bots can forget about it instead of fetching it every so often.
I have thousands of such deleted tags on my site. It would be better for the environment if the bots didn't waste resources on this.

Attachments (2)

tag.png (36.1 KB) - added by rafaucau 2 years ago.
Non-existent tag
feed.png (44.0 KB) - added by rafaucau 2 years ago.
Feed of this tag.

Download all attachments as: .zip

Change History (3)

@rafaucau
2 years ago

Non-existent tag

@rafaucau
2 years ago

Feed of this tag.

#1 @karl94
8 months ago

Yeah, I think non-existing feed should return 404 too.

This doesn't happen just on tag or categories feeds, but on every archive feed or even comment feeds.

I did a bit of digging and it seems the inhibition of 404 on feeds started in https://core.trac.wordpress.org/ticket/18505
There the reported issue was: empty but valid archives (e.g. existing tag but with no post) have feeds with 404.

I think feeds should behave as their HTML web counterpart:

  • empty tag/category/term/author/post_type archive => empty webpage/feed
  • non-existing tag/category/term/author/post_type archive => 404 on both webpage and feed
  • home with no posts => empty webpage/feed
  • comment feed for non-existing post => 404

While currently they seem to never trigger a 404.

@SergeyBiryukov are you willing to accept a patch that goes in this direction? I think it would be just a change in WP::handle_404() plus some unit tests.

Note: See TracTickets for help on using tickets.