Get the map of pages and links your subject needs, before anyone writes a word of any of them.

Topic Cluster Strategy decides which pages a broad subject needs, what distinct job each page owns, and how the set should link together. The deliverable is the architecture and the build sequence that follows from it. You walk away with a page-by-page architecture where each proposed page has demand behind it, an implementable link contract, and a build order that follows the dependencies.

Cluster graph showing pillar and supporting pages connected by a link contract

Some of the 500+ brands we've worked with

See all references
  • Sanofi
  • PWC Türkiye
  • Domino’s
  • Axa Sigorta
  • BAT
  • Koleksiyon Mobilya
  • Amazon
  • BMW
  • Shell
  • Hyundai
  • PepsiCo
  • Red Bull
  • Decathlon
  • MediaMarkt
  • Bayer
  • EY
  • KPMG
  • GE
  • 3M
  • Lexus
  • Trendyol
  • Hepsiburada
  • Yandex
  • Pegasus Airlines

Each step narrows a broad subject into a set of pages that deserve to exist.

  1. Map the full topic universe

    We lay out every distinct question and subtopic inside the subject, sourced from customer questions and search demand. Before the topic list closes, a strategist compares it with the customer questions that prompted the work.

    A topic universe grounded in observed demand.

  2. Draw the boundary between pages

    Overlapping topics get merged. Topics with separate jobs get split, so nothing becomes two competing pages saying the same thing. A strategist signs off on every merge or split decision before the boundary gets locked.

    A page-boundary matrix with no unintentional overlap.

  3. Build the cluster graph

    Pillar and supporting pages get mapped into a graph showing how they relate to each other and to any existing URLs already covering part of the ground. A strategist reviews how new pages connect to existing URLs before the graph is treated as final.

    A cluster graph connecting new and existing pages.

  4. Write the link contract

    We specify exactly which pages link to which, and why. A strategist confirms every specified link serves a reader before the contract ships to production.

    A link contract ready to hand to production.

  5. Sequence the build

    Pages get ordered by dependency and priority, so foundational pieces get written before the supporting pages that link to them. A strategist confirms the build order follows the page dependencies before it's treated as final.

    A build sequence with priority and dependency noted.

  6. Prepare the individual briefs

    Each page in the sequence gets enough of a starting brief that the next production step isn't starting from scratch. A strategist reviews each brief starter before handing it to SEO Content Briefs.

    Brief starters for each page, ready for SEO Content Briefs to finish.

The diagram is a draft until the evidence holds

Agents help us compare a large set of candidate pages, find overlaps, and sketch possible link patterns. That makes the graph quicker to assemble. It doesn't tell us whether a page deserves to exist. A Zeo strategist tests each proposed page against demand, then decides the boundaries, links, and build order. Pages that merely make the diagram look complete don't make the plan.

The plan exists so nobody has to guess whether a page belongs, or where it should link.

  • a topic cluster map with linked nodes

    Cluster graph and page-boundary matrix

    The full map of pillar and supporting pages, with overlaps resolved before anything gets written.

  • a content brief with checklist marks

    Link contract

    Exactly which pages connect to which.

  • an editorial calendar grid

    Build sequence and brief starters

    The order pages should get written in, plus enough of a head start that briefing each one is fast.

We call it done when: every proposed page has a distinct job backed by demand, the link contract is specific enough to implement, and the sequence follows the page dependencies.

This plans which pages should exist and how they connect. Building the pages themselves is a separate step.

A good fit when

  • A subject is big enough that one page can't cover it, and several pages risk overlapping or competing with each other.
  • Every proposed page needs evidence of demand, and you want the cluster graph to cut anything that only makes the diagram look complete.
  • Related pages exist, but nobody has defined which source should link to which destination or why the connection helps a reader.

Better handled as other work when

  • You want a page created for every conceivable subtopic regardless of whether demand supports it.
  • The plan is to copy a competitor's site structure rather than build one that fits your content and expertise.
  • You're looking for the pillar pages to be written as part of this. That's a separate production method.
  • Ahrefs

    the full topic universe pulled and pre-clustered before boundaries get drawn by hand

  • Keyword Cupid

    the SERP-based test for exactly where one page's boundary ends

  • Screaming Frog

    renders the live link structure as a graph, checked against the contract

  • Airtable

    the cluster graph and its link contract: hub and spoke rows, explicitly linked

  • Notion

    the build sequence across the whole cluster, before any single brief is written

Show us the subject and any pages already covering it. We can work out the page boundaries, link plan, and build order before production starts.
Talk to a Content Marketing specialist
Two people shaking hands on the start of the work

Do you write the pillar pages as part of this?

Page production sits outside this method. We finish the architecture first, then SEO Content Briefs usually define each page in the sequence.

How many pages does a typical cluster include?

It depends entirely on how big the subject is. We'd rather map a smaller, tighter cluster that's fully justified than pad it out to look comprehensive.

What if we already have some pages that fit into the cluster?

Existing pages that already serve the subject get a role in the graph.

Can this replace a full site redesign?

No. This is scoped to one subject’s content architecture. A full site redesign is much bigger. It is a different kind of project.