Topic clusters: a pillar page and the notes that should point back

Give the pillar a job the notes do not steal

The pillar explains the map: what the topic covers, who it is for, and which deeper note to open next. If the pillar tries to be every supporting article, the notes have nothing left to rank for.

Each supporting page should target one question the pillar only introduces. If two notes have the same title intent, merge them before you draw the cluster diagram.

Link like an editor, not like a grid

The pillar links to every note that is part of the map. Each note links back to the pillar and to the one or two notes a reader needs next. That is enough.

Do not add a block of every cluster URL, with the same anchor, at the bottom of unrelated pages. The homepage does not need to repeat the whole cluster either.

• One pillar per topic you actually cover.
• Supporting pages with distinct queries.
• Links up to the pillar and sideways only when useful.

Name the cluster in the architecture

A URL folder can reflect the cluster, but the links do the work. A flat URL with clear internal links is better than a deep folder nobody links to.

Review the cluster when you publish. New pages should say which pillar they belong to before they are drafted, or they will become orphans with overlapping titles.

Do topic clusters rank better than standalone posts?

They help readers and crawlers see how pages relate. The pages still need to be the best answer for their own query. The diagram alone does nothing.

How many supporting pages does a cluster need?

As many as there are distinct questions you can answer well. Three strong notes beat fifteen thin ones written to fill a wheel.