Content strategy: topic clusters and briefs

Pillar and cluster planning, mapping keywords to URLs, writing a brief that produces the page you planned, and preventing cannibalisation.

Pillar and cluster planning

A topic cluster is one broad pillar page and a set of focused pages that each answer a narrower question, all linked to each other. It works because it demonstrates depth on a subject rather than scattering single pages across unrelated topics.

Layer	Role	Length	Targets
Pillar	The overview that defines the topic and routes to detail	Long, structured, one H1, many sections	The broad head term
Cluster page	One question answered completely	Focused, 800-2000 words	A specific long-tail phrase
Supporting asset	A tool, template or calculator	Varies	Link-worthy and shareable
Update	An existing page refreshed with new data	Same URL	Terms it already ranks for

Cluster: DNS operations

Pillar    /guides/dns                     primary: dns guide
  Spoke   /guides/dns/ttl                 primary: dns ttl
  Spoke   /guides/dns/record-types        primary: dns record types
  Spoke   /guides/dns/email-records       primary: spf dkim dmarc
  Spoke   /guides/dns/troubleshooting     primary: dig command examples

Link rules
  pillar -> every spoke, in body copy, descriptive anchor
  spoke  -> pillar, once, near the top
  spoke  -> two or three sibling spokes, only where genuinely useful

Publish the pillar first or last - either works - but plan all of it before writing any of it, or the spokes will overlap.
One page per intent. If two planned pages would answer the same question, merge them at the planning stage, not after both are indexed.
Leave room for updates. A plan with no maintenance budget produces a site that decays quietly.

The content brief

BRIEF: DNS TTL and caching
URL:        https://example.com/guides/dns/ttl
Primary:    dns ttl
Secondary:  what is ttl, negative caching, ttl propagation
Intent:     informational, developer troubleshooting a cutover
Audience:   developer who knows DNS basics but not cache layers

Must answer
  1. which layers cache a record and for how long
  2. what lowering TTL does and does not fix
  3. how negative caching differs (SOA minimum)
  4. a safe cutover sequence with realistic timings
  5. how to verify what a given resolver is serving

Must not
  - repeat the record-type list from /guides/dns/record-types
  - include a provider comparison table (that is a commercial page)

Links out:  /guides/dns, /guides/dns/record-types, /guides/dns/troubleshooting
Success:    impressions for "dns ttl" and "ttl propagation" in 8 weeks

A brief that only lists keywords produces a page that reads like a keyword list. The sections that make it useful are the ones that say what must be answered, what must be excluded to avoid duplication, and how success will be judged.

Cannibalisation and updating

Export queries for the topic from Search Console and group them by the URL that received impressions.
If two URLs collect impressions for the same query in the same week, that is cannibalisation - the engine is unsure which page to serve.
Decide which page is the better answer to that intent, then either merge the content into it and redirect the other, or differentiate the weaker page's angle and reduce the overlap.
Never fix cannibalisation by adding a canonical from one live page to another that does not cover the topic; you lose the weaker page's traffic without gaining anything.
Re-check 30 days after the change. Positions usually move before clicks do.

Situation	Action	Why
Two thin pages, same intent	Merge into one	One strong page beats two weak ones
Old page ranking 5-15 with outdated data	Update in place, keep the URL	Preserves accumulated signals
Old page ranking 5-15 but the topic moved	Write a new page, redirect the old	Refreshing cannot fix a wrong answer
Page with traffic, no conversions	Improve the next step, not the copy	The query was satisfied; the page did its job
Seasonal page out of season	Keep it live, update before the season	Removing and restoring loses everything

💡

The most reliable growth lever for an established site is updating what already ranks, not writing the next new page. Pages sitting on positions four to fifteen are already close - a better answer, current data and a clearer structure regularly moves them into the top three.

FAQ

How often should content be refreshed?

Review pages that depend on facts, prices, versions or dates at least twice a year, and after any product change. Evergreen conceptual pages can go much longer if nothing has changed.

Can one page rank for many keywords?

Yes, and that is normal. A well-built page usually collects dozens of related queries. What it cannot do is serve two different intents well - that is what needs a second page.

Keyword research and search intent Site architecture, URLs and internal linking

Last refreshed 2026-09-18.

Content strategy: topic clusters and briefs

Pillar and cluster planning

The content brief

Cannibalisation and updating

FAQ

Related