---
name: category-tree-and-facet-design
description: Use when deciding whether a demand cluster deserves its own category page, an indexable facet, or no page at all, and the tree has grown by merchandiser request rather than by design.
---

# Category Tree And Facet Design

Category trees grow one request at a time until there are 900 nodes, half of them holding four products, and nobody can say why any of them exists. The obvious correction, building a page for every keyword cluster with volume, produces thin grids that compete with each other and with the facets underneath them. The decision is not what to create, it is which of three containers a cluster belongs in, and that depends on inventory depth and permanence as much as on search demand.

## O que precisa primeiro

- Live product counts per node of the current tree, counted in stock now rather than at launch
- A demand set clustered by intent, with the head term and the modifiers for each cluster
- Search Console impressions and organic entrances per existing category and facet URL, 6 months
- The merchandising rules that decide which products land in which node, so you know what is automatic and what is hand-curated

## Método

1. Count live products per existing node before adding anything. Nodes holding fewer than about 5 products cannot support a page that beats a competitor grid, and they are the merge candidates.
2. Sort each demand cluster by whether its modifier describes an attribute you hold as structured data or a use case you do not. Attribute clusters belong in facets; use case clusters need a curated category because no filter produces that set.
3. Apply a permanence test to the survivors: it is a category if the set of products would still make sense in two years, and a facet if the set is simply whatever the filter returns today.
4. Set an inventory floor per node and write down what happens when a node falls below it. Without a stated rule the thin nodes accumulate again inside a year.
5. Map each surviving cluster to exactly one node and confirm no two nodes claim the same head term. Two categories serving one intent split links and impressions and neither wins.
6. Decide URL depth before building. Nesting every attribute produces paths nobody maintains, while a flat path with hierarchy carried only in breadcrumbs is easier to restructure later; this trade-off is argued seriously on both sides and the right answer depends on how often your tree changes.
7. Ship the merge and redirect list for the failed nodes in the same release as the new ones, not as a follow-up that never gets prioritised.

## O que isto produz

A revised category tree with a stated inventory floor per node, a facet whitelist, and a merge and redirect list covering the nodes that did not qualify.

## Onde isto corre mal

- Creating a category for every modifier with search volume, leaving dozens of near-identical grids drawn from the same few hundred products
- Building use case categories that are generated by a filter, so membership changes every time stock moves and the page never settles
- Deleting thin nodes without redirects because they had little traffic, then losing the internal links and breadcrumb paths that pointed at them
- Deciding the tree from keyword volume alone without checking what the catalogue can actually fill

---

Da biblioteca de competências da QuQi - https://www.quqi.io/pt/skills/category-tree-and-facet-design