Entities, experts and available evidence set the cluster boundary. Keyword similarity can reveal demand, but it can't decide what the brand is qualified to publish.

Each sourced audience question receives one page job. A named expert or credible source must be ready before that page enters the plan, and a set of questions held back from the design gets used to test whether the architecture holds. Overlapping pages consolidate around one entity-backed cluster, and every planned page has a named expert or source lined up before it's written. Content leads and SEO managers deciding what to consolidate, retire or greenlight in a cluster that has grown beyond its approved scope.

Figure building a tower of topic blocks around a central entity badge representing topical authority

Some of the 500+ brands we've worked with

See all references
  • BMW
  • Findeks
  • Yves Rocher
  • Memorial
  • İstanbul Gedik Üniversitesi
  • Country Floors
  • Bundle
  • Amazon
  • Shell
  • Hyundai
  • PepsiCo
  • Red Bull
  • Decathlon
  • MediaMarkt
  • Bayer
  • Sanofi
  • EY
  • KPMG
  • GE
  • 3M
  • Domino’s
  • Lexus
  • Trendyol
  • Hepsiburada

Strategy and editorial owners set scope, page jobs and evidence requirements. Drafting the map and testing it is our work. Approving the architecture is theirs.

How we hold ourselves to it

  • Entities set the boundary
  • One job per page
  • Expert before expansion
  • Tested on unseen questions
  1. Set entity-led cluster boundaries

    Strategy and domain owners use the approved entity graph to define defensible clusters and name the adjacent topics that remain out of scope. Domain and strategy owners set the cluster vocabulary and excluded adjacent topics.

    An entity-led topic graph with explicit scope and named exclusions.

  2. Map questions to distinct page jobs

    Before format or target terms enter the discussion, the content strategist assigns each sourced audience question and decision stage to one primary page job. The content strategist and audience owner confirm question provenance, intent and the accountable destination.

    A question-to-page matrix, with one accountable owner per question.

  3. Audit overlap, gaps, and evidence depth

    Reviewers compare intent, evidence depth and orphaned questions across the existing pages. Consolidation is usually the first remedy for genuine overlap. Domain and editorial reviewers judge the findings and separate intentional differentiation from genuine duplication.

    An overlap and evidence-gap register with consolidate, retain, create, or retire decisions.

  4. Assign experts and source requirements

    Editorial owners attach a named specialist, evidence requirement and claim boundary to every planned page before setting production priority. Subject-matter, editorial and legal owners take responsibility for the publication limits.

    An expert and source assignment map, with readiness status per planned page.

  5. Validate with questions nobody wrote for

    An independent reviewer maps audience questions that weren't used in the design. Ambiguous destinations and broken paths go back into the architecture before it ships. An independent reviewer applies the original one-owner-page rule and reopens anything that fails it.

    A validation report from the questions we held back, showing where the architecture holds and where it doesn't.

The architecture gives writers a sequence they can use. Its coverage measure shows which audience questions already have named expertise or adequate source evidence.

  • Topical cluster architecture

    A defensible hub-and-supporting-page model grounded in entities, audience decisions, and named experts.

  • Consolidation and creation roadmap

    Sequences consolidation, retirement, evidence development, and new page creation by documented user need and readiness.

  • Internal-link and hierarchy specification

    Hub relationships, contextual links, and next-question paths defined for each page role.

  • Supported cluster coverage

    The count runs against the agreed set of cluster questions. A question only counts as covered once adequate evidence or a named expert supports its page.

  • Cluster recheck schedule

    A cluster that was defensible a year ago doesn't stay assumed defensible without a recheck, and the schedule fixes when that recheck happens.

Fifty related pages exist. Three compete for the same question, while none traces back to an entity or expert the brand can defend.

A good fit when

  • Pages overlap without anyone noticing — Two articles answer the same buyer question and split authority, yet both remain because each still gets traffic.
  • The cluster has no approved entity anchor — The pages have no approved product, service or documented expertise anchoring their shared scope.
  • Nobody owns the claims being made — A comparison page makes a technical claim with no named author, no cited source, and no specialist who'd defend it if challenged.
  • An approved entity graph already exists — The method needs agreed entities and relationships. If the graph is still open, Entity Relationship Mapping comes first.
  • Approved entities draw the cluster boundary — Products, services and relationships set scope, and the plan names adjacent demand that falls outside it.
  • Each page gets one distinct job — One page owns each question and journey stage. Competing pages merge so authority stops splitting across them.
  • Expertise is ready before publication — A named specialist, first-party data or credible source is assigned before production, so claims publish with support.

Better handled as other work when

  • You want authority from volume alone — A cluster is an editorial model, not a shortcut. More pages on topics the brand can't support only add liability.
  • Page volume is not evidence of authority — A large cluster without distinct expertise is not success. It is the failure this method is meant to prevent.
  • Rankings and citations stay outside the guarantee — The architecture consolidates supported expertise, but an external system decides whether to grant authority.
  • InLinks

    shows which entities the existing pages already cover, which is where the overlap audit starts

  • Screaming Frog

    surfaces the existing pages already competing for the same topic space

  • AlsoAsked

    maps the sourced audience-question tree the cluster's page jobs get assigned from

  • AnswerThePublic

    spreads the demand around a subject wide enough to see where the cluster boundary should fall

  • SparkToro

    shows where an audience already reads, which tests whether a cluster has a reader behind it

  • Airtable

    the cluster map itself, showing editors what to merge, write, and hold back

Choose one disputed question from the cluster. We map the entity boundary, decide the primary page job with your owners and test the result against questions we held back from the design.
Map the disputed topic

Does a well-structured cluster guarantee rankings or AI citations?

No. It makes the brand's supported expertise easier to follow, but external systems still decide what to rank or cite.

Why can't I just build a cluster from keyword research?

Keyword similarity can show related demand. It doesn't establish which entity owns the topic, whether two pages have distinct jobs or who can support their claims. Those decisions need the approved entity graph and named expertise. Without them, more pages can add overlap without adding authority.

How much of this is automated versus editorial judgment?

Mapping questions, comparing page roles and flagging overlap can be automated, and so can the pass that tests questions held back from the design. The decisions can't. Strategy and editorial owners decide which clusters the brand can credibly own and which experts stand behind each page, and an independent reviewer decides whether a failure reopens the architecture.

Which evidence makes an architecture defensible?

Supported cluster coverage counts a question only after named expertise or adequate evidence backs it.