WordPress Tag Archives: Noindex, Delete, or Keep?

WordPress tag archives are indexable from the moment you create the term, and for most of the tags on a typical blog the right answer is to delete them rather than hide them. Noindex earns its place on the handful of archives you genuinely use to move readers around the site; everything else is a tag that should never have existed, and a deleted term cannot quietly compete with the post it was supposed to describe.

This is not a hypothetical problem on this site. WPFairs has 84 posts and more than 800 tags. One theme tutorial here carries 37 of them, including How To Add Breadcrumbs In Generatepress Theme, How To Add Breadcrumbs In Generatepress WordPress Theme and Adding Breadcrumbs In GP Using Hooks Element as three separate terms with three separate URLs. Three near-identical variants of “What is DA and PA in SEO” exist as three more. Each one was a page the site invited search engines to look at, and none of them was ever written for a reader.

What WordPress tag archives actually are

Every term you create in the post_tag taxonomy gets a URL at /tag/<slug>/, renders through your theme’s archive template, and lists the posts carrying that term with pagination. That is the whole feature. WordPress adds no noindex rule to it, because core has no opinion about whether the page is worth indexing.

Core does have an opinion about your sitemap, and it is a more sensible one than most people expect. post_tag is a public, viewable taxonomy, so it appears in wp-sitemap.xml — but the taxonomy sitemap provider queries terms with hide_empty set to true, so a tag attached to zero posts is left out. That detail matters when you audit: your 500 empty tags are not in the sitemap, yet their URLs still resolve, still render a page, and still get crawled, because the tag lists at the bottom of your old posts link to every single one of them.

The content of that page is the problem. A tag archive shows post titles and excerpts that already appear on your home page, in your category archives, in your sitemap and on the posts themselves. When the tag holds one post, you have published a title-only restatement of an article at a second URL. When the tag holds two posts and a near-duplicate tag holds the same two posts, you have done it twice.

If you are on a block theme, the template doing the rendering is archive — or taxonomy-post_tag if your theme ships one — and you can edit it in the Site Editor without touching PHP. Customizing a block theme: theme.json or a child theme? covers where those changes should live so they survive a theme update.

Audit your tags before you decide anything

You cannot make a sensible call from the Tags screen in the admin, because it paginates at 20 and sorts alphabetically. Over SSH, three commands give you the actual shape of the problem in about ten seconds.

# Your 40 busiest tags, post count first.
# Count leads the CSV deliberately, so a comma inside a tag name
# cannot shift the column you are sorting on.
wp term list post_tag --fields=count,term_id,name --format=csv \
  | tail -n +2 | sort -t, -k1 -rn | head -40

# How many tags are attached to nothing at all?
wp term list post_tag --fields=count --format=csv \
  | tail -n +2 | grep -c '^0$'

# Tag names longer than four words. These are almost never real tags.
wp term list post_tag --field=name | awk 'NF>4'

Read the first list from the bottom up rather than the top down. The top is fine — those are your real topics. The bottom is where the decision lives, and on most sites it is a long tail of terms with a count of 1 or 0.

Two numbers are worth writing down before you change anything: how many tags you have in total, and how many have a count above three. On this site the second number is a rounding error against the first. If that ratio holds for you, you are not looking at a tagging system that needs tidying. You are looking at a keyword field that someone used as a notes app, and the cleanup is larger than the tags themselves.

While you are in there, run the counts again from scratch. Term counts drift when posts are deleted or bulk-edited, and an audit built on stale counts will tell you a tag is empty when it is not.

# Recalculate term counts from the actual relationships
wp term recount post_tag category

No SSH access? The Site Health screen will not count your tags, but it will tell you whether you have the tooling and the headroom to do this comfortably — WordPress Site Health: how to find and fix common problems walks through reading it. Without a shell, do the audit in batches from the Tags screen and expect it to take an evening rather than a coffee break.

The criteria I use to decide

State the test before you start applying it, otherwise you will talk yourself into keeping everything. These are the questions I ask about a tag archive, in the order I ask them.

Run those questions against each term and the three-way decision falls out. On a narrow screen the table below stacks into one card per situation.

Notice that “noindex everything” is not on that list, despite being the advice you will read most often. Hiding 800 pages leaves you with 800 pages to maintain, 800 URLs in your internal link graph, and an admin screen you still cannot use. Noindex solves an indexing problem. Most tag bloat is not an indexing problem — it is a data-entry problem that happens to be visible to Google.

How to noindex WordPress tag archives

Pick one method and only one. Two things writing a robots meta tag for the same URL is how you end up with a noindex you cannot find the source of six months later.

If you are not running an SEO plugin, this is the whole implementation. Drop it in a site-specific plugin rather than functions.php so it survives a theme change:

<?php
/**
 * Plugin Name: Noindex Tag Archives
 */

// wp_robots_no_robots() sets noindex, and adds follow while the site
// is public — so internal links from the archive still count.
add_filter(
	'wp_robots',
	function ( array $robots ) {
		return is_tag() ? wp_robots_no_robots( $robots ) : $robots;
	}
);

// The robots meta tag and the sitemap are separate systems.
// Leaving tags in wp-sitemap.xml while noindexing them is
// a mixed signal with no upside.
add_filter(
	'wp_sitemaps_taxonomies',
	function ( array $taxonomies ) {
		unset( $taxonomies['post_tag'] );
		return $taxonomies;
	}
);

The wp_robots filter and wp_robots_no_robots() both landed in WordPress 5.7, so on 7.1 you are well clear of any compatibility question. If Yoast or Rank Math is active, delete this snippet and use the setting instead.

Then verify it, because a robots meta tag is exactly the kind of change that silently fails. Load a tag archive and look at the source:

curl -s https://example.com/tag/your-tag/ | grep -i 'name="robots"'
# Expect: <meta name="robots" content="noindex, follow" />

Seeing two robots meta tags in that output means you have two systems fighting, which is the problem the first paragraph of this section was about. Seeing none means your SEO plugin is filtering the output further down the chain, or page caching is serving you a copy from before the change.

Deleting tags without breaking anything

Work the list in two passes. The first pass prints what would be deleted and deletes nothing:

# Pass 1 — dry run. Read this list properly before going further.
wp term list post_tag --fields=count,term_id,name --format=csv \
  | tail -n +2 | awk -F, '$1==0'

# Pass 2 — delete only the terms attached to nothing.
wp term list post_tag --fields=count,term_id --format=csv \
  | tail -n +2 | awk -F, '$1==0 {print $2}' \
  | xargs -r -n1 wp term delete post_tag

Empty terms are the free win: nothing links to them from a post, they are not in your sitemap, and deleting them costs you nothing. Terms with a count of 1 need a second look, because that one post is still linking to the archive from its tag list, and because occasionally a one-post tag turns out to be a real topic you simply have not written about twice yet.

For merging, reassign before you delete. wp term delete does not move posts anywhere — it drops the relationship and leaves the post with one fewer tag:

# Everything tagged "Best WooCommerce Plugins" should be "woocommerce"
wp post list --tag=best-woocommerce-plugins --format=ids \
  | xargs -r -d' ' -I{} wp post term add {} post_tag woocommerce

# Only now remove the old term
wp term delete post_tag 1234

After deleting, those URLs return 404, and that is the correct outcome rather than a problem to paper over. Google’s guidance for permanently removed pages is a 404 or 410, not a redirect to something unrelated. Redirect only where a tag URL has real inbound links or real traffic, and redirect it to the closest genuine page — a category archive or the single best post — not to your home page. If 404s start showing up in bulk somewhere you did not expect, how to fix 404 errors in WordPress covers tracking down what is still linking to them.

Expect the cleanup to show up in Search Console as a rise in excluded URLs over the following weeks, not as an immediate ranking change. That is the system working.

If your tags only existed for navigation

A fair number of tags exist purely to power a “related reading” list at the bottom of a post. That is a reasonable thing to want and a poor reason to maintain an indexable archive, because the archive is a side effect of the mechanism rather than the thing you wanted.

Core already does this without new URLs. A Query Loop block filtered by taxonomy, placed in your single-post template in the Site Editor, renders related posts from the same tag with no plugin and no archive page involved. It is the first thing to try, and for most sites it is the last.

Where Query Loop gets awkward is hand-picked lists — “these four posts, in this order, on this page” — because it is a query builder, not a curation tool. Disclosure: I build and maintain Post Showcase, which does curated and queried post lists with layout controls, so treat that as an interested recommendation and judge it on the same test as anything else: does it let you delete tags you were only keeping as plumbing? If your lists are rule-based rather than curated, Query Loop is the better answer and you should not install anything.

What cleaning up tag archives will not do

Being honest about this matters, because the most common reason this cleanup disappoints people is that they were sold it as something it is not.

It will not fix your crawl budget, because you almost certainly do not have a crawl budget problem. Google’s large-site crawl budget guide puts the threshold for caring at roughly a million unique pages changing weekly, or ten thousand or more changing daily, and says outright that if your pages are crawled the same day you publish them, the guide does not apply to you. The same document advises against using noindex to save crawl effort at all, on the grounds that Googlebot still has to request the page before it can act on the rule. A 100-post blog with 800 tags has a quality and duplication problem, not a budget one — and that is the honest case for deleting rather than hiding.

There is no duplicate content penalty waiting for you. Thin tag archives are not a manual action, and Google’s spam policies are aimed at doorway pages and scaled content abuse, not at WordPress defaults. The cost is subtler: pages of yours competing with other pages of yours for the same query, and a site where the ratio of real articles to automatically generated listings is unflattering. Framing it as a penalty leads to panic deletions; framing it as competition leads to the right decisions.

It will not speed up your front end. Tag archives are not in the path of a visitor reading a post. What a few hundred thousand rows in wp_term_relationships does slow down is the admin — the tag box in the editor, autocomplete, the Tags screen itself. If the dashboard is your actual complaint, start with diagnosing a slow WordPress admin dashboard, because term bloat is rarely the biggest thing on that list.

It will not recover rankings you lost for other reasons. If traffic fell off a cliff on a specific date, look at that date rather than at your taxonomy. Tag cleanup is maintenance that compounds quietly over months. It is not a recovery play, and anyone presenting it as one is guessing.

What you do get is a site structure you can reason about, an admin that responds, and a set of archives where every one that is indexed is one you would be happy to see in a search result. On this site that means going from more than 800 tags to a controlled vocabulary of a few dozen, one category per post, and a rule that a tag applying to exactly one post does not get to exist. The breadcrumbs tutorial mentioned at the top — adding breadcrumbs in the GeneratePress theme — has been through exactly that treatment, down from 37 tags and six categories to four and one.

Frequently asked questions

Sources

• Large site owner’s guide to managing your crawl budget — Google Search Central, for the site-size thresholds and the advice against using noindex to manage crawl effort
• Block Search indexing with noindex — Google Search Central, for the robots.txt interaction and the recrawl latency
• wp_robots_no_robots() — WordPress developer reference, for what the function sets and the 5.7 version note
• wp term list and the wp term command family — WP-CLI documentation, for the fields and argument order used above
• Yoast SEO settings: Categories & tags — for the admin path and what the search appearance toggle controls
• Rank Math ‘Titles and Meta’ options and settings — for the equivalent robots meta controls