Topical clustering is the content architecture that replaced the old "write a blog post for every keyword" model. The shift started around 2018 with HubSpot's early writing on pillars and clusters, and by 2024 it had become the default playbook for any content program serious about organic traffic. The reason is simple: Google's topical authority model rewards sites that cover a topic in depth, not sites that cover many topics in shallow breadth.
This is the pattern library for how I architect topical clusters on DTC content sites. Five patterns, each addressing a specific decision in the architecture: how to pick the pillar, how deep to go on the spokes, how to link between them, how to handle adjacent clusters, and when to retire a cluster that is not working.
- Best mattress firmness for side sleepersSpoke / 590 mo
- Hip pain relief for side sleepersSpoke / 480 mo
- Shoulder pressure on a side sleeperSpoke / 320 mo
- Memory foam vs hybrid for side sleepingSpoke / 260 mo
- Pillow height for side sleepersSpoke / 210 mo
- Side sleeper alignment basicsSpoke / 170 mo
The underlying model
A topical cluster is a single pillar page that covers a broad topic, surrounded by 10-30 support pages (spokes) that each cover one narrow subtopic in depth. The pillar links to every spoke. Every spoke links back to the pillar. Spokes link to 2-3 semantically-related sibling spokes.
Google's crawl and ranking behavior on a well-built cluster is distinct. The pillar page accumulates authority from inbound external links and distributes it to spokes. The spokes rank for their specific long-tail queries. The pillar ranks for the broader head term. The whole cluster signals topical authority on the subject.
Done wrong, a cluster is a pillar page and a loose collection of posts that happen to be about the same topic. Done right, it is a tightly-linked content library where each piece serves a specific function in the architecture.
Pattern 1: pillar selection by search volume times intent depth
The pillar topic is the single most important decision in a cluster. The right pillar sits at the intersection of three things: search volume worth chasing, content you can credibly cover, and reader intent that matches what you sell.
The mistake I see most often in DTC engagements is picking a pillar that has high volume but does not match buyer intent. A mattress brand picking "sleep" as a pillar is wrong; "sleep" is too broad, attracts tire-kickers, and has 200 commercial competitors. A mattress brand picking "side sleeper mattress guide" as a pillar is right; specific, commercial-intent adjacent, and covers a cluster of real buyer questions.
The volume-times-intent-depth heuristic is: pick the pillar where the multiplication is highest, not where the individual factors are highest. A 2,000-monthly-search pillar with high commercial intent beats a 50,000-monthly-search pillar with low intent almost every time.
Pattern 2: spoke depth before spoke breadth
The failure mode of a cluster is too many thin spokes. A pillar with 50 spokes each at 400 words reads like a directory. A pillar with 15 spokes each at 1,500-2,500 words reads like a library.
The depth target I use is: every spoke should be the best article on the web for its specific query. Not "one of the top five." The single best. That is the bar that justifies a spoke. If you cannot produce the best article, the spoke is not worth writing yet. Skip it, ship something else, come back when you have more to say.
Depth also means actual claims backed by actual experience or data. A spoke that says "layering works best with merino" without any underlying reasoning is thin. A spoke that explains the thermal dynamics, the thickness tradeoffs, and the specific layering rules across three climate bands is deep.
Pattern 3: internal linking topology
Inside a cluster, the linking topology is hub-and-spoke with sibling cross-links. Each spoke:
- Links up to the pillar at least once, ideally in the first third of the article
- Links to 2-3 sibling spokes with semantic relevance (use embeddings to pick them, see internal linking automation that stays safe)
- Does not link to every sibling
The pillar:
- Links out to every spoke, in-body, with descriptive anchors
- Links to 1-2 adjacent clusters where the topics touch
- Carries a "related cluster" block at the bottom if the adjacency is meaningful
The anti-pattern is the "every page links to every other page" cluster, which produces a dense graph that looks automated (covered in the linking article linked above).
Pattern 4: adjacent-cluster bridging
Clusters do not live in isolation. A DTC apparel brand might have a "fit guides" cluster, a "care guides" cluster, and a "materials" cluster. These topics touch each other. A care guide for linen naturally references the materials cluster. A fit guide for a specific fabric references both.
The pattern I use is: 1-2 contextual links per spoke to pages in adjacent clusters, chosen for semantic relevance. Not a dedicated "explore other topics" block (that looks mechanical). Body-context links inside sentences that would make sense even if the link were removed.
This bridging reinforces the entity graph. A site that links its own content together in ways that track real-world topical relationships gets more credit for topical depth than a site where every cluster is an island.
Pattern 5: retire clusters that do not earn their rent
A cluster that has been live for 18 months and is still not ranking for its target head term is probably not going to rank with more time. The signal is clear in the first 6-12 months, not the second 12. Clusters that miss should be pruned, not expanded.
Pruning options:
- Merge the cluster into an adjacent, stronger cluster
- Consolidate the spokes into a shorter pillar with inline subsections
- Delete and redirect to the most relevant alternative cluster
The worst choice is to leave a failing cluster live and add more thin spokes hoping the volume helps. It does not. Google reads the cluster-level signal and the drag continues.
The audit I run on client engagements flags clusters with low engagement, low rankings, and low inbound links after 18+ months as prune candidates. The prune pass is usually the single highest-impact change in a multi-year content program.
“The failure mode of a cluster is too many thin spokes. A 15-spoke cluster with depth beats a 50-spoke cluster without.
”
Common mistakes in DTC cluster architecture
Four patterns I see repeatedly.
Pillar on a too-broad topic. "Fashion," "wellness," "nutrition." These never rank because they are not searchable head terms with clear intent. Narrow the pillar.
Every spoke pointing at the product, not the topic. Spokes that exist only to funnel to a PDP read like sales pages. Google and readers both catch this. The spoke should answer a topical question first and mention the product in passing, if at all.
No canonical pillar URL. A pillar that shares a URL pattern with the blog (/blog/pillar-name/) is fine. A pillar that lives under /pages/ while the spokes live under /blog/ breaks the topology. Keep the cluster on one URL path if possible.
Cluster on a topic the brand has no authority to cover. A mattress brand writing a cluster on skincare looks off-brand and ranks poorly. Stick to clusters where the brand has real, verifiable authority.
How to scope a cluster before you start
The scoping template I use on a cluster kickoff has five lines:
- Pillar page title and target head term (with monthly search volume)
- List of 15-25 candidate spoke queries with their monthly search volumes
- Target spoke word count (usually 1,200-2,000)
- Internal linking pattern (hub, siblings, adjacent clusters)
- Edit timeline and ship cadence
If you cannot fill those five lines in an afternoon, the cluster is not ready to start. That is a feature, not a bug. Clusters that get half-planned tend to fail.
Where this fits
Topical cluster architecture sits downstream of entity SEO and upstream of internal linking automation. The cluster hub frames the broader program. Internal linking automation covers the edge layer on top of the topology. Entity SEO for ecommerce covers how clusters contribute to entity recognition in Google's knowledge graph.
If you want a cluster audit on your existing site (crawl structure, depth, linking, prune candidates), the DTC stack audit covers it. For the broader product ladder, see /products.
Cross-cluster adjacencies worth reading: shopify hub architecture for 2m brands for the Shopify storefront side, and the creative-tech operator playbook for the role that typically owns this work end to end.
Sources and further reading
- HubSpot Pillar Cluster model, original 2018 documentation and 2024 update
- Google Search Central: topical authority guidance, 2024-2025
- Koray Tuğberk GÜBÜR writing on topical maps and semantic SEO