Categories vs Tags: Getting Blog Taxonomy Right

Open the admin panel of almost any blog that's been running for three years and you'll find the same wreckage: 47 categories, most with one post. A tag cloud with 412 tags, 390 of them used exactly once. Nobody planned it. It just accumulated, one "I'll make a new category for this" decision at a time.

The categories vs tags question sounds like a beginner topic. It isn't. Taxonomy decides what your archive pages look like, how link equity flows through your site, and whether Google sees a structured publication or a pile of loosely related posts. Get it right early and it compounds. Get it wrong and you'll spend a weekend two years from now merging archives and writing redirects.

TL;DR: Categories are your table of contents — 5 to 8 broad sections, every post gets 1 or 2. Tags are an index — optional, and only worth creating if at least 3 posts will share them. Most blogs need fewer of both than they think, and blogs under 30 posts arguably need neither.

What's the Actual Difference Between Categories and Tags?

Categories are hierarchy. Tags are keywords. A category answers "what section of this blog does the post live in?" A tag answers "what specific things does this post mention?" A post belongs to one or two categories. It can mention many topics.

The classic analogy is a book. Categories are the table of contents: a handful of chapters that together cover the whole subject. Tags are the index at the back: an alphabetical list of every specific term, pointing to the pages where it appears.

That analogy holds up because it predicts correct behavior:

• A book with 50 chapters of one page each is badly organized. So is a blog with 50 categories.
• An index entry that points to a single page is barely useful. So is a tag used once.

A concrete example. A post titled "Deploying a Laravel CMS on a $5 VPS" might be:

• Category: Self-Hosting
• Tags: laravel, vps, nginx, deployment

The category says where the post lives. The tags say what it touches. One structural, one descriptive.

Why Do Most Blogs Get Taxonomy Wrong?

Because the CMS makes creating taxonomy terms free, and nobody assigns a cost to them until much later. Every term you create spawns an archive page — a real URL that Google can crawl, index, and judge. The cost shows up at crawl time, not creation time.

The two standard failure modes:

Category sprawl. Each new post gets a new category because none of the existing ones feel like a perfect fit. Three years later: 47 categories, an unnavigable dropdown, and 40 archive pages with one post each. The fix is admitting that categories are supposed to be broad. "Tutorials" is a category. "Tutorials about configuring Nginx gzip settings" is a sentence.

Tag confetti. Tags get treated as free-form keywords typed at publish time: "cms", "CMS", "content-management", "content management system" — four tags, one concept, four thin archive pages. WordPress made this famous with the tag cloud widget: 400 one-off tags displayed as a wall of links no human ever clicked.

Both failures come from the same root cause: treating taxonomy as metadata for the writer instead of navigation for the reader. The test for any term: would a reader ever click this archive page and find it useful? If no, the term shouldn't exist.

The SEO Side: Every Term Is a Page

Here's what makes taxonomy an SEO topic rather than a tidiness topic: every category and every tag generates an archive page with its own URL. Those pages get crawled, they consume crawl budget, and they either help or hurt how Google understands your site.

Thin-content risk

An archive page with one post on it is a near-empty page: a title, one excerpt, a link. Multiply that by 400 one-off tags and you've published 400 near-identical, near-empty pages. Google's quality systems evaluate sites partly on the aggregate — a large mass of thin pages drags down the perceived quality of everything else.

Worse, overlapping terms create duplication. If "javascript" and "js" tags both exist and contain mostly the same posts, you've built two competing pages for one topic. You're making Google choose, and it might choose neither.

When should you noindex tag pages?

Default answer: noindex tag archives, index category archives. Tag pages rarely earn search traffic — nobody's query is satisfied by your reverse-chronological list of posts mentioning "nginx." Category pages, done right, can rank, because a curated section page for "Self-Hosted CMS" actually answers a browsing intent.

The nuance:

1. Tag pages, fewer than 5 posts — noindex, or better, delete the tag.
2. Tag pages, well-populated and genuinely distinct from any category — indexable is defensible, but be honest about whether anyone searches for it.
3. Category pages — index them, and invest in them (more below).
4. Paginated archives (page 2+) — leave crawlable, keep self-referencing canonicals; don't canonical page 2 to page 1.

Noindex is the patch, not the cure. If most of your tag pages need noindex to avoid embarrassment, the real fix is deleting most of your tags.

Categories as internal-linking hubs

This is the upside nobody talks about. A good category page is one of the most powerful internal-linking assets you have.

A category archive links to every post in the section, and every post links back via breadcrumbs or post meta. That makes it a hub — two clicks from the homepage, distributing link equity to every post in the cluster and telling Google "these posts belong together, and this page represents the topic."

Internal linking is one of the few SEO levers fully under your control — archive handling is one of the items in our CMS SEO checklist for exactly this reason. A CMS that gives you clean category archives, breadcrumbs, and an XML sitemap has done most of the structural work for you. UnfoldCMS generates category archive pages and includes them in the XML sitemap automatically, with JSON-LD on posts — the hub structure exists from day one without plugins.

Practical Rules That Hold Up

These rules are boring, and they work.

A few of these deserve a defense:

5–8 categories max. If your blog needs more than 8 top-level sections, you're probably running two blogs and should admit it. Fewer categories means each archive page is deeper, which means each one is a stronger hub.

Every post gets exactly 1–2 categories. One is ideal. Two is acceptable when a post genuinely sits on a boundary (a WordPress-alternative comparison that's both "CMS" and "Headless CMS"). Three or more means your categories overlap too much, and overlapping categories produce duplicate-ish archive pages.

The 3-post rule for tags. Before creating a tag, ask: do at least 3 published posts share this term? Not "will someday" — do now. If the answer is no, the tag is a label on a single post, which is to say it's nothing. This single rule kills 90% of tag confetti before it exists.

Prune annually. Taxonomy isn't write-once. Once a year, sort terms by post count and merge or delete everything below the threshold. Twenty minutes of admin work, real crawl-quality payoff.

How Does Taxonomy Build Topical Authority?

Topical authority — Google trusting your site on a subject because you've covered it thoroughly and coherently — is mostly an internal-linking story, and categories are the cheapest way to build the structure.

Most teams build topic clusters manually with pillar pages. But a well-run category is a cluster hub, generated for free:

1. The category page links to every post in the cluster.
2. Every post links back via breadcrumb.
3. The category sits in your nav, one click from the homepage.
4. New posts join the cluster the moment you assign the category.

The catch: a default archive page is a weak hub. It's just a paginated list. To make it pull its weight, add a paragraph or three of editorial copy at the top of each category page — what this section covers, which posts to start with, links to the most important ones. Now it's a curated hub that can rank for the topic term itself, not just a list.

This is also why one or two categories per post matters. Tight category membership produces clean clusters. A post in 5 categories blurs into all of them and strengthens none.

We've written about how flat-file and database CMSs handle structured content differently, and taxonomy is exactly the kind of relational feature where databases earn their keep. For API-first setups, the taxonomy should be queryable too — UnfoldCMS exposes categories over its REST API at /api/v1/categories, so a decoupled frontend can build category navigation from the same source of truth as the server-rendered site.

One honest note: UnfoldCMS deliberately ships categories only — no tag system. After watching a decade of WordPress tag clouds, we think most blogs are better off without the second taxonomy. A flat set of well-chosen categories covers the real navigation need without nesting and without the confetti.

URL Structure: Keep It Flat

Two decisions here, and the answer to both is "the boring option."

Where do archive URLs live? /blog/category/self-hosting/ vs /category/self-hosting/ — either works, and consistency beats cleverness. If your posts live under /blog/, keep the archives under /blog/ too, so the whole publication occupies one clean URL subtree. Don't mix patterns, and don't change the pattern later without redirects.

Should category appear in post URLs? No. /blog/deploying-laravel-vps/ beats /blog/self-hosting/deploying-laravel-vps/. The nested version reads nicely but creates a trap: the day you recategorize the post, the URL breaks or needs a redirect. Flat post URLs make taxonomy a metadata change instead of a migration. There's no measurable ranking benefit to keyword-stuffed URL paths that justifies the fragility.

Flat URLs, taxonomy as metadata, redirects only when you actually rename something. That's the whole policy.

Migrating a Messy Taxonomy (Without Losing Rankings)

If you're reading this with 47 categories already in production, here's the cleanup sequence. The order matters.

1. Export the inventory. Every term, its post count, and its archive URL. A spreadsheet is fine.
2. Design the target. Pick your 5–8 categories on paper before touching the CMS. Map every old term to a new one (or to "delete").
3. Reassign posts. Move every post to its new category. Batch this — most CMSs support bulk edit.
4. Delete the empty terms. Old categories and one-off tags with zero posts left.
5. 301 the dead archive URLs. Every deleted term's archive URL gets a permanent redirect to the closest surviving category — or to the blog index if nothing fits. Skipping this step leaks years of accumulated signals into 404s.
6. Resubmit the sitemap and watch Search Console for a few weeks as the old URLs drop out.

The redirect step is where CMS support matters most. UnfoldCMS handles this with built-in SEO redirects — including an expiry field for redirects that should be temporary — and slug history redirects fire automatically when you rename a category or post slug, so the rename case is covered without manual rules. Whatever platform you're on, verify it can do managed redirects before starting a merge; pruning archives without redirects is how taxonomy cleanups turn into traffic drops. (If you're shopping for a platform that treats this as core rather than plugin territory, it's one of the criteria in our Strapi alternatives roundup.)

Expect a few weeks of ranking wobble on the affected archives. That's normal consolidation, and the post URLs — where your actual traffic lives — shouldn't move at all if you kept them flat.

When You Need Neither

Under roughly 30 posts, taxonomy is theater. A reader can scan a single blog index of 30 titles faster than they can navigate your category dropdown, and search engines don't need archive scaffolding to crawl 30 URLs.

The honest move for a young blog: publish into a flat index, take notes on what natural groupings emerge, and add 4–5 categories around post 30 when the clusters are visible in your real output instead of imagined in advance. Categories extracted from 30 real posts are always better than categories invented before post one.

What you should never do is the inverse — launch with 12 aspirational categories and fill them at a rate of one post per quarter. That's a year of thin archive pages for zero reader benefit.

The Bottom Line

Categories are structure: few, broad, mandatory, indexed. Tags are an index: optional, earned by reuse, noindexed by default. Every term you create is a page Google will judge, so create terms the way you'd publish pages — deliberately.

The mechanics are the easy part. Any decent CMS gives you categories, archives, and a sitemap. The discipline — 5 to 8 categories, 1 or 2 per post, prune yearly — is on you. Set the rules before post ten and your taxonomy becomes the skeleton of your topical authority. Skip it and you'll meet your tag cloud again in three years, spreadsheet in hand.

Related: 10 SEO features your CMS should handle for you · Flat-file vs database CMS · Best Strapi alternatives in 2026