We publish an article advising people to check how many tag archives their WordPress site has indexed. When someone audited this site, we had 437 of them in our sitemap — 296 with exactly one post and none with a description. This is what we found when we actually applied our own advice, and what we removed.
What we found
The audit was prompted by an external review of our own blog. It was a fair hit: we were telling readers to audit their tag archives while submitting several hundred of ours to Google without ever having looked at them.
| Measure | Before |
|---|---|
| Tag archives in sitemap | 437 |
| Tags with exactly one post | 296 (68%) |
| Tags with two or fewer posts | 327 (75%) |
| Tags with a description | 0 |
| Near-duplicate slug groups | 39 |
| Robots directive on tag archives | None — all indexable by default |
The near-duplicates were the clearest symptom of how this happens. We had aeo and aeo-2026, ai-search and ai-search-2026, singapore-sme and singapore-sme-2, and three separate variants of zero-click-search. Nobody decided to create those. They accumulated because articles were published with tags generated per post rather than chosen from an existing set.
Why it matters, and why it is not a penalty
There is no penalty for having many tags. The problem is more mundane: each archive is a URL competing for attention with the posts it lists, and a sitemap is a statement about which URLs you consider worth indexing. Submitting 437 near-empty archives says something about the site that is not true.
The compounding effect was the part we had not considered. When we published thirty new posts in a single session, 407 of those 437 tag archives were re-dated in the sitemap, because each new post touched the tags attached to it. Our one-day publishing footprint was not thirty URLs. It was more than six hundred.
What we did
- Backed up the complete tag-to-post mapping first, so every change is reversible.
- Merged the year-variant and numeric duplicates. Posts were moved to the canonical tag before the duplicate was removed, so no article lost its categorisation. 41 duplicate tags were merged away.
- Deleted tags left with a single post. An archive listing one article is not a destination; the article itself is. 266 were removed.
- Wrote descriptions for the surviving significant tags. 44 archives with five or more posts now have a real description instead of an empty one.
| Measure | Before | After |
|---|---|---|
| Tag archives | 437 | 130 |
| Removed from the index surface | — | 307 |
| Archives with descriptions | 0 | 44 |
What we did not do
We did not delete tags with genuine inventory. An archive collecting fifty posts on one subject is a real page with a real purpose, and several of ours are. The cut was aimed at archives that existed by accident.
We also did not switch tag archives to noindex globally. That is a single setting and it would have been faster, but it would have left several hundred pointless URLs in place and simply hidden them. Removing a URL that should not exist is a better outcome than concealing it.
How to check your own
- Open your tag sitemap. It is usually at
/post_tag-sitemap.xmlor listed inside your sitemap index. - Count the entries. If the number is close to your post count, tags are being generated rather than chosen.
- Sort your tags by post count in the admin. Everything with one post is a candidate for removal.
- Look for year variants and numbered duplicates —
-2,-2026. These indicate the same tag was created more than once. - Check whether any archive has a description. If none do, none of them were ever intended as destinations.
Our one-day publishing footprint was not thirty URLs. Thirty posts re-dated 407 tag archives, and we had never looked at any of them.
The honest lesson
The advice in our WordPress article was correct. We had simply never applied it here, because tag archives are invisible from the front end — nobody visits them, nothing looks broken, and the problem only appears when someone reads your sitemap.
That is the same reason the most damaging technical problems go undiagnosed: they produce no symptom a person would notice. It took an outside audit to make us look at our own, which is a reasonable argument for having someone audit yours.
Frequently asked questions
Should I noindex WordPress tag archives?
Not automatically. The test is whether the archive is a real destination: does it have a coherent set of posts, a genuine description, and a reason for someone to land on it? An archive listing a single post is none of those things and is worth removing or excluding.
Is having too many tags an SEO penalty?
No, there is no penalty for tag count. The problem is dilution and crawl waste – many thin, near-identical URLs competing with the posts they list, and a sitemap that tells search engines to treat them all as pages worth indexing.
Is it better to delete a tag or noindex it?
Deleting removes the URL entirely, which is the cleaner outcome for a tag that should never have existed. Noindexing keeps the URL for site navigation while excluding it from search. We deleted the single-post tags because they served no navigational purpose either.
Does deleting a tag affect the posts it was on?
No. Removing a term removes the association, not the content. The posts keep their other tags, their categories and their URLs.
How did the tags get created in the first place?
Mostly by bulk publishing with tags generated per article rather than chosen from an existing set. That produces year-variant duplicates and one-post tags very quickly, which is exactly what we found.
If you want a second pair of eyes on what your site is submitting to Google, send us the domain and we will read your sitemap and tell you what is in it. See how we run technical work, message us on WhatsApp, or send an enquiry.
Sources
Written by Charlotte Zhang, Operations Partner at Kaizenaire Pte Ltd (UEN 201932071D). Charlotte co-founded Kaizenaire with Ken Tan in 2019 and runs client delivery, after four years in operations at OCBC and HSBC.