Facets or Categories? Designing a Classification Scheme That Scales

Date:

A good taxonomy is invisible when it works and infuriating when it doesn’t. The trick is to build on an industry standard for completeness and interoperability, then lay a human-friendly navigation over the top — and to keep your filters separate from your tree.

The short answer: adopt a mature industry standard (BISAC, ISCED, the Google Product Taxonomy) as your authoritative backbone, then design a shallow, human-friendly navigation on top and map it to that backbone. Push attributes like price, format and brand into facets (filters), never the tree; keep marketing sets like “Bestsellers” as a separate editorial layer; and freeze your category URLs. That is the whole method, and it scales from a hundred items to a hundred thousand without a rebuild.

Whether you’re organizing a bookstore, a course directory, or a product catalog, the classification scheme is load-bearing: it shapes navigation, search, SEO, and how discoverable each item is. Design it badly and you spend years fighting miscategorized items and dead-end pages. Here’s a method that scales.

Three layers, kept separate on purposeEvery scheme that collapses does it the same way: a facet gets promoted into the tree.
1. Industry standard

Start from one that already exists. It gives you coverage you would not have thought to include.

2. Navigation over it

What a person browses is not the standard's shape. Lay your own tree over it — do not replace it.

3. Facets, kept apart

Color, price and brand cut ACROSS the tree. Put one inside it and the branches multiply past repair.

4. Curated sets

"Gifts under 20" is marketing, not taxonomy. A third layer, with an owner and an expiry date.

A tree you cannot prune is the end state. It is reached one reasonable-looking facet at a time.

Start from an industry standard — but don’t stop there

Resist inventing categories from scratch. Most domains already have a mature, standardized scheme:

A standard buys you two things: completeness (someone has already thought through the edge cases) and interoperability (you can sync with suppliers, feeds, and partners who speak the same scheme). Adopt one as your backbone — the authoritative spine every item maps to.

The catch: standards are built for catalogers, not shoppers. BISAC has thousands of granular headings; nobody wants that as a navigation menu. So the standard is your backbone, not your storefront.

A standard is your backbone, not your storefront.

Lay a user-friendly navigation over the standard

On top of the backbone, design a shallow, human navigation — the menu people actually browse:

  • A top level of a dozen or so broad, recognizable categories (Fiction, Non-Fiction, Children’s…).
  • One or two levels of sub-categories beneath each, using the words your audience uses, not the standard’s formal labels.

Each navigation category maps to one or more backbone nodes behind the scenes. Users see friendly labels and a tree they can hold in their head; your system still knows the authoritative classification for feeds, analytics, and SEO. Keep the visible tree shallow — every extra level halves the number of people who reach the bottom.

Keep filters (facets) separate from the tree

The single most common taxonomy mistake is cramming everything into the hierarchy. Some attributes aren’t where an item lives — they’re ways to narrow a list. Those belong in facets (filters), not the tree:

  • language · author/brand/publisher · format (paperback, ebook, audiobook) · price range · audience/age · rating · publication year.

An item sits in one place in the tree but carries many facet values. This is what lets a shopper start in “Fiction › Mystery” and then filter to “audiobook, under a set price, high rating” without you building a separate category for every combination. Trees answer “where is it?”; facets answer “which of these do I want?”

Trees answer where an item lives; facets answer which of these you want.

Curated and marketing categories are a third thing

“Bestsellers,” “Staff Picks,” “Award Winners,” “Seasonal” — these feel like categories but they’re editorial collections, not classification. Keep them as tags or dynamic lists layered on top, so they can change constantly without disturbing the taxonomy underneath. Never let a marketing label become a permanent branch of your tree.

Never let a marketing label become a permanent branch of your tree.

Governance rules that save you later

  • One canonical category per item. An item may surface in several places, but exactly one node is its authoritative home — otherwise reporting and canonical URLs get ambiguous.
  • Freeze your URLs. Category URLs are the one thing you must not casually change; they accrue SEO value and external links. Decide the structure early and treat it as permanent.
  • Have a deliberate “uncategorized” policy. New items will arrive without a clear home; route them to a holding category and triage, rather than guessing and mis-filing.
  • Prune depth, not breadth. A wide, shallow tree beats a narrow, deep one for both users and crawlers.
  • Map, don’t duplicate. When you adopt a standard, store the mapping (your node → the standard’s node); don’t fork and diverge from the standard, or you lose the interoperability you adopted it for.

Category URLs are the one thing about a taxonomy you must never casually change.

Why this matters for SEO

Category pages are some of your strongest ranking assets — they target broad “best [category]” and “[category] + qualifier” queries. A clean tree gives each a clear topic and a natural internal-linking structure; a messy one produces thin, overlapping, cannibalizing pages. The backbone-plus-navigation approach keeps category pages distinct and purposeful, which is exactly what search engines — and increasingly the answer and generative engines you also need to structure for — reward.

The short version

Adopt an industry standard as your authoritative backbone; design a shallow, friendly navigation on top and map it to the backbone; push attributes into facets rather than the tree; keep marketing collections as a separate layer; and freeze your URLs. Do that, and your classification scheme scales from a hundred items to a hundred thousand without a rebuild. With that skeleton in place, filling it — the work of generating catalog and category content — becomes a repeatable step rather than a bottleneck.

Frequently Asked Questions

Should I use an industry standard like BISAC or invent my own categories?

Adopt a standard as your backbone — it gives you completeness and interoperability with suppliers and feeds. But don’t expose the raw standard to shoppers; lay a friendlier, shallower navigation on top and map it back to the standard behind the scenes.

What’s the difference between a category and a filter?

A category is where an item lives in the tree — an item has one canonical home. A filter (facet) is a way to narrow a list — language, format, price, rating — and an item carries many facet values. Putting attributes that should be filters into the category tree is the most common taxonomy mistake.

How deep should my category tree be?

As shallow as you can manage — usually a top level plus one or two sub-levels. Every extra level sharply reduces how many people reach the items beneath it. Add depth only when a level genuinely has enough distinct items to justify it, and lean on facets instead of deep nesting.

Can I change my category structure later?

You can add and reorganize, but treat category URLs as permanent — they accumulate SEO value and inbound links, so changing them is costly. Decide the URL structure early and freeze it; evolve labels and groupings above that stable foundation.

Share post:

Subscribe

Popular

More like this
Related

How to Merge Spreadsheets by URL (and Why Our Tool Reported 5 Misses That Weren’t)

Matching two spreadsheets on a URL column is the same job as matching a stock list to a price list by product code. It goes wrong in the same two places: how you clean the code, and how you count what didn't match.

Many-to-One: Why a Mapping Backlog Outgrows Its Target Taxonomy

You're mapping a messy source vocabulary onto a clean target taxonomy. The target has about 5,600 slots, so the job must be roughly 5,600 decisions — right? The backlog is already past 8,900, and still climbing.

The Fix That Didn’t Take: When a Content-Hash Gate Skips Your Code Change

You shipped a fix to how one field is computed, re-ran the pipeline across everything, and it reported a clean run. Then the consistency check still flags those records as wrong. The fix is in the code, the rebuild "ran" — and the records never changed. Your own optimisation skipped them.

Your Dedup Scan Is Over-Counting — Because It Forgot What You Already Fixed

The report said 80 duplicate groups still to resolve. You'd been resolving them for days. You run it again after a big batch and it *still* says 80-ish. The backlog isn't stubborn — the scan is counting work you already finished.