You know the pages. Your CMS generates a URL every time someone adds a tag to a post. Each tag URL shows the tag name, a short intro (often "Posts tagged with X"), and a list of post titles. Some tag pages have 20 posts. Most have 2 or 3. A few have 1. A handful have zero, left over from a deleted post.
Every one of those tag pages is in your sitemap. Every one of them gets crawled. Google does not index the low-content ones and de-prioritizes crawling on your site as a whole because it has learned the average URL on your domain is thin. This is the zombie tag page problem, and it is one of the most common causes of "we publish good content but organic traffic is flat" on WordPress-style sites.
Here is why it happens, why the sitemap-side fix is not enough, and where the actual fix lives.
Photo by Polina Zimmerman on Pexels
Why the CMS generates tag pages by default
Every major CMS emits a tag or taxonomy archive URL for every unique tag on every post. This is a legacy design decision from a decade ago when tag pages were considered a UX feature - a way for visitors to browse related content across posts.
That UX assumption was true when a blog had 30 posts and 8 tags, all curated. It is false when a blog has 500 posts and 400 tags, most of which were added ad hoc by different authors over years. Now the tag structure is a graveyard, and the CMS keeps emitting sitemap entries for each one because the code that generates the sitemap does not know which tags are useful and which are not.
WordPress with Yoast, WordPress with RankMath, Ghost, Shopify blogs, and most enterprise CMSes all exhibit this pattern in their default configurations. Google Search Central has written extensively on the general principle behind faceted navigation and thin auto-generated pages.
Why zombie tag pages hurt
Three mechanisms:
First: crawl-budget waste. Google allocates a per-site crawl budget based on the site's authority and its perceived crawl efficiency. Every request Googlebot spends on a thin tag page is a request it did not spend on a real post. On a small site with authority, this is negligible. On a mid-sized site where you are trying to get 100 new posts crawled and indexed each month, it is significant.
Second: quality signal contamination. Google looks at the aggregate quality of URLs it crawls on a domain to inform its overall crawl and ranking decisions. If 40 percent of what it sees is thin tag pages, it is inferring things about your average content quality that are not what you want.
Third: cannibalization. Tag pages that do get indexed sometimes rank for the tag term ahead of your best content on that same term. Now a search for "SEO audit" returns your tag archive of "seo audit" (three thin post titles) instead of your comprehensive 2500-word SEO audit guide. This is one of the more frustrating variants of keyword cannibalization.
The sitemap-side fix does not stick
The instinct is to remove the tag pages from the sitemap. This is correct as far as it goes, and it does reduce the "thin content in sitemap" signal.
But it does not fix the crawl-budget problem. Google still discovers the tag pages through internal links (the CMS emits tag links on every post that has a tag) and through the site's tag navigation. The sitemap removal helps at the discovery-priority layer. It does nothing at the crawl-discovery layer.
Nor does it fix the cannibalization problem. The pages still exist. They still respond with content. Google still indexes some of them. They still compete with your posts.
The CMS-side fix is what actually works
Three configuration changes at the CMS level solve the problem end to end.
One: add <meta name="robots" content="noindex, follow"> to tag archive pages. The noindex tells Google not to index the page (fixing the cannibalization). The follow tells Google to still follow the links on it to the individual posts (preserving internal-link authority). Most SEO plugins have a checkbox for "noindex taxonomy archives" that does exactly this.
Two: exclude tag archives from the sitemap. The same SEO plugin will let you exclude them by URL pattern.
Three: reduce or remove tag-page internal links from your site templates. If your post templates emit a link to each tag as a small chip at the bottom of each post, consider removing them. They provide little UX value on a site where visitors do not actually browse by tag, and each tag chip is an internal-link vote for a URL you would rather not have Google spending crawl budget on.
All three together produce the outcome the sitemap-only fix reaches for. And unlike the sitemap-only fix, they are durable - future posts added with future tags do not re-populate the graveyard because the taxonomy archive is set to noindex and excluded by pattern.
The exception: when tag pages are actually useful
Some sites use tags strategically as a curation layer, with 10 or 20 tags total, each of which has a substantive intro (300+ words), a curated list of high-quality posts, and internal links from other high-authority pages. These tag pages can rank and can be a legitimate SEO asset.
If your site is one of these, do not blanket-noindex. Manually noindex the graveyard tags and keep the curated ones indexable. The distinction is usually clear when you look at the pages.
The audit workflow to identify which tag pages are curated vs zombie is part of the broader sitemap indexation audit at https://137foundry.com, which covers the identification step in more detail.
What "zero organic traffic despite good posts" often actually is
Sites in this state usually think the problem is content quality, or backlinks, or on-page SEO. They spend months improving those things and organic stays flat.
The audit almost always finds one of three underlying issues:
- A graveyard of thin tag pages contaminating the site's quality signal
- A CMS-generated crawl trap (paginated archives, author pages, date archives)
- Legacy URLs from a migration that Google is still hitting, wasting crawl budget
None of these show up on a normal content or backlink audit. All of them are found in the sitemap-vs-indexation gap analysis. The detailed walkthrough of the sitemap audit covers how to spot each pattern.
Photo by Leeloo The First on Pexels
The three checks that catch this
If you are not sure whether your site has this problem, three quick checks:
- Look at your sitemap URL count and your indexed URL count (from Search Console). If indexed is under 70 percent of sitemap, you probably have this problem in some form.
- Scan your sitemap for tag or taxonomy URLs. If they are there, they are almost certainly contributing to the problem.
- In Search Console's Pages report, filter to "Crawled - currently not indexed" and look at the URL patterns. If tag pages dominate the list, you have your answer.
Any of the three signals is enough to start the audit. Google Search Console gives you all three for free.
The fix workflow in one paragraph
Noindex the taxonomy archives at the CMS level. Exclude them from the sitemap at the plugin level. Optionally remove tag chip links from post templates. Resubmit the sitemap. Wait three weeks. Watch the indexation rate climb. Rankings on the pages that used to be cannibalized by the tag archives improve. Crawl budget shifts to real content.
That is the fix. It is not glamorous, and it does not involve writing more content. But it is often the highest-ROI SEO change a mid-sized site can make in a single day of work.
For the full audit and fix workflow the 137Foundry technical SEO service runs end to end, along with the related writeups at Moz and Ahrefs on similar patterns.
Kill the zombie tag pages. Watch the traffic move. That is the work.
Top comments (0)