Planning topic clusters

Planning Topic Clusters

Overview

Random blog posts are dead in 2026. Both Google's algorithms and LLM retrieval systems reward topical authority — the demonstrable depth of coverage on a single subject — and the cleanest way to build it is the pillar + spoke architecture HubSpot popularized [1][2]. The 2026 evidence is hard: clustered content drives ~30% more organic traffic and 3.2× more AI citations than standalone posts; sites with hub-and-spoke linking see pillar AI citation rates jump from ~12% to ~41% [3][7]. Topic clusters are no longer an SEO nicety — they are the unit of content strategy.

This skill takes a clustered keyword map (output of researching-keywords-pre-launch or finding-underserved-keywords) and produces a publishing plan: pillars, spokes, URL slugs, link graph, calendar.

The Cluster Anatomy

• Pillar page — the comprehensive 3,000–5,000-word guide on the broad topic. Lives at the top of the site at /pillar-topic/. Defines the entity. Links down to every spoke [4][6].
• Spoke pages — 1,500–2,500-word deep dives, one per sub-question. Live at /pillar-topic/spoke-slug/ (mirrors information architecture, gives Google the hierarchy for free) [4][6].
• Internal link graph — every spoke links up to the pillar with descriptive anchor text; the pillar links down to every spoke; spokes link laterally to 2–3 sibling spokes in the same cluster. Bi-directional linking alone increases LLM citation probability by 2.7× [3].
• Cluster size — 8–15 spokes per pillar is the 2026 sweet spot [2][6]. Below 6 spokes the topic isn't pillar-worthy; above 15 the cluster fragments and dilutes the pillar's authority.

The Planning Flow

1. Take the keyword map. Expects clusters already grouped by intent + entity from prior research. (If you only have a flat keyword list, route to researching-keywords-pre-launch first.)
2. For each cluster, identify the pillar term — broadest informational query that subsumes all the others (e.g., for vibecrafting.ai: "AI image prompt engineering" is the pillar; "midjourney negative prompts", "stable diffusion seeds", "prompt weighting syntax" are spokes).
3. Define URL slugs preserving the topic hierarchy: /ai-prompt-engineering/ for the pillar, /ai-prompt-engineering/midjourney-negative-prompts/ for each spoke.
4. Draw the link matrix. A who-links-to-whom table. Rows = source pages, columns = target pages. Pillar row gets a checkmark in every spoke column; every spoke row links back to the pillar plus 2–3 sibling spokes.
5. Set the publishing order. The 2026 consensus: publish 2–3 foundational spokes first, then the pillar, then the remaining spokes [9]. Reasoning: a pillar with no spokes to link to is awkward to write; a pillar with all spokes pre-built is overwhelming and delays first traffic. The 2–3 first cover the most-searched sub-questions and give the pillar real internal-link prey on day one.
6. Output CONTENT_PLAN.md to repo root: cluster map + slugs + link matrix + dated publishing schedule.

The Cluster-Quality Test

Run these three checks before you commit to a cluster. Failing any one means re-cluster.

• One sub-question per spoke. Each spoke answers exactly one question of the pillar. If a spoke title needs "and" or "&", split it.
• Pillar-can't-stand-alone. The pillar should be impossible to write comprehensively without referencing each spoke. If a spoke could be deleted with no pillar consequence, it doesn't belong in this cluster.
• Hard cluster boundaries. Spokes shouldn't blur into adjacent clusters. If "midjourney negative prompts" could plausibly belong to both an AI prompts pillar and a midjourney pillar, you have a clustering ambiguity — pick one home and link the other from afar.

Common Mistakes

• Too-broad pillars ("AI" with 50 spokes) — the cluster fragments and Google can't tell what the pillar is about [6].
• Too-narrow pillars (3 spokes) — not pillar-worthy; merge into a sibling cluster or promote a spoke to the pillar.
• Thin spokes that should be merged — if two spokes share >50% of their search intent, they're one spoke fighting itself for rankings (keyword cannibalization).
• Keyword-only clustering — clustering by literal keyword overlap misses entity and intent boundaries. Cluster by intent + entity, not n-gram similarity [5].
• Forgetting to update the link graph as new spokes ship — every new spoke needs its row added to the matrix and back-edits to 2–3 siblings. This is the #1 cluster-decay failure mode.
• Skipping descriptive anchor text — "click here" links don't give LLMs the semantic signal that makes the pillar citation-worthy [3][8].

Quick Reference

Cluster size:    8-15 spokes per pillar (2026 sweet spot)
Pillar length:   3,000-5,000 words
Spoke length:    1,500-2,500 words
URL pattern:     /pillar-slug/spoke-slug/
Link matrix:     pillar -> all spokes; spoke -> pillar + 2-3 siblings
Publishing:      2-3 spokes -> pillar -> remaining spokes

Lifecycle

• Initial. Plan one cluster per primary commercial intent. Don't try to map the whole site on day 1; ship one cluster, measure, expand.
• Growth. Add new spokes as finding-underserved-keywords surfaces gaps. Each new spoke triggers a back-edit pass on the pillar and on 2–3 sibling spokes to add the new internal links.
• Mature. Re-plan annually. Mature sites usually need to reorganize legacy content into clusters retroactively — sort orphaned posts into existing pillars, merge thin posts that should have been one spoke, and demote deprecated topics.

What's Next

• optimizing-on-page — apply on-page SEO + GEO patterns to each pillar and spoke as it ships (covers the internal-linking execution at the page level).
• analyzing-content-gaps — feeds new spoke ideas into existing clusters as competitors publish.
• building-eeat-and-authority — author entities and trust signals matter more than ever post-March-2026 update [10]; a cluster without a credible author won't capture full topical authority.

Citations and verification tags in SOURCES.md.