LLM Best Practices

Content Clusters and Pillar Pages

4 min read

View markdown source

Overview

A content cluster is one pillar page plus 5 to 15 cluster pages that each cover one sub-question of the same topic. The pillar accumulates inbound links from its cluster, the cluster routes readers back to the pillar, and the whole group earns topical authority that a flat blog cannot. Build clusters first; chase individual keywords second.

One pillar per topic, and the pillar is the broadest page

The pillar page covers the head term and links out to every sub-page in the cluster.

  • Title format: “Topic: Best Practices” or “The X Guide.” Broad, not narrow.
  • Length: longer than a cluster page, but still atomic. Aim for 800 to 1,500 words.
  • Body: defines the topic, lists the sub-questions, and links to the cluster page that answers each.
  • Wikilink density: every cluster page appears at least once in the pillar body.

A pillar without a cluster is a stub. A cluster without a pillar is a pile of orphans.

Cluster pages handle one sub-question each

Atomic, narrow, and densely linked back to the pillar and to sibling pages.

  • One question per page. If two questions both deserve 500 words, ship two pages.
  • 400 to 700 words per page. Past 700, split.
  • Every cluster page links to its pillar and to two or three siblings.
  • Anchor text uses the linked page’s topic, not “click here.” See internal-linking.

The atomic-page rule is also a cost rule for agents: an LLM follows a wikilink cheaper than it re-reads a 3,000-word page.

A cluster is not a folder; it is a graph. Three link patterns hold it together.

  • Pillar to cluster: the pillar lists every cluster page by name.
  • Cluster to pillar: every cluster page links back to the pillar at least once, usually in the first paragraph.
  • Sibling to sibling: each cluster page links to two or three peers in the same cluster. This is what compounds authority across the group.

Orphan a single page in a cluster and the cluster’s PageRank flow leaks out the missing edge.

Map external topical authority through the pillar, not the leaf

Backlinks earned to cluster pages flow up to the pillar; backlinks earned to the pillar flow down to the cluster. Plan link-earning around the pillar.

  • Outreach, podcast appearances, and guest posts link to the pillar URL.
  • Tools, calculators, and templates live on cluster pages and earn their own backlinks.
  • Internal links from cluster to pillar concentrate authority; do not split it across five pillars on adjacent topics.

This is the rule that decides whether to write a new pillar or extend an existing one. When in doubt, extend.

Audit clusters with the orphan check on every build

A cluster is healthy when every page is reachable and every page links back.

  • Run an orphan check: any page with zero inbound internal links is a bug.
  • Run a depth check: every page within three clicks of the homepage. See the depth rules in internal-linking.
  • Run a coverage check: every sub-question the keyword research surfaced has a page or is on the backlog. See keyword-research.

Wire these into CI; do not run them by hand.

Map this vault as clusters, not as a flat list

The folder structure on this site is the cluster architecture. Each index.md is a pillar; each leaf page is a cluster member.

  • seo/index.md is the SEO pillar. seo/technical.md, seo/content.md, seo/structured-data.md, and the rest are cluster pages.
  • frontend/index.md is the frontend pillar. Astro, React, Tailwind, and shadcn are cluster pages.
  • ai-agents/index.md is the AI-agents pillar. Claude Code, RAG, MCP, and embeddings are cluster pages.

A new page that does not fit an existing pillar is a signal to either extend a pillar or ship a new one. Never create floating pages outside a cluster.

Graph View

Backlinks