What you will learn
A cluster is not a pile of similar phrases. It is a useful map of related customer tasks, the pages that answer them, and the links that help people move between them. This lesson joins research and architecture so you do not create pages that compete with one another or disappear into a flat archive.
Why this matters
Many sites grow through campaigns, product launches, and one-off articles. Over time, customers cannot tell what the business offers, important pages receive few internal links, and several pages address the same question. Architecture turns accumulated content into a coherent experience.
A roadmap makes trade-offs explicit. The team can start with pages that have a clear task, credible proof, and a route to implementation instead of chasing every variation from a research tool.
From demand to destination
Start with related tasks, not keywords alone. A hub gives orientation; detail pages provide focused help. Internal links explain the relationship between them. The roadmap releases a coherent branch rather than an isolated collection of URLs.
Core concepts
Clusters follow jobs, not strings
Group queries when the same page could genuinely satisfy the underlying task. Split them when a customer needs a different answer, format, audience, or action. Similar wording does not always mean the same intent; different wording can describe the same job.
Use it when: Could one well-designed page answer these queries without becoming vague or overloaded?
Hubs orient; detail pages resolve
A hub helps a visitor understand the landscape and choose a path. Detail pages answer narrower questions, compare options, explain a use case, or support an action. Give each level a clear job so the site does not repeat itself.
Use it when: Does this page help a customer orient, decide, or act—and is that role obvious?
Internal links carry meaning
Links should help people and crawlers discover relevant next steps. Use descriptive anchors, visible context, and routes that reflect real relationships. Do not treat internal links as decoration or a way to force every page toward one target.
Use it when: Would a person understand why this link is here and what they will find next?
Roadmaps include dependencies
A valuable topic may need product input, original research, legal review, design components, engineering support, or local data. Record those dependencies before you promise a publication date.
Use it when: What must exist before this page can be accurate and useful?
The practical method
- 01
Build a demand inventory
Combine customer language, search data, sales questions, support gaps, and competitor observations. Keep the source and confidence for every meaningful pattern.
- 02
Group by customer task
Create provisional clusters around decisions such as compare options, solve a problem, understand pricing, check eligibility, or choose a service.
- 03
Choose the right response type
For each cluster, decide whether the best response is a hub, guide, comparison, category, product page, tool, local page, or documentation update.
- 04
Map roles and links
Draw the parent, child, sibling, evidence, and next-action relationships. Remove pages that have no distinct role or route.
- 05
Score the first release
Assess customer value, business fit, evidence, effort, dependency risk, and measurement readiness. Prioritize a useful connected slice.
- 06
Validate with people
Test navigation and draft outlines with customers, sales, support, and subject experts before scaling the architecture.
Guided workshop
Turn research into a topic cluster with clear destinations
Your deliverable: a topic-to-URL map that shows which page owns each task, how supporting pages link, and what should not be created.
Practice scenario
Practice scenario: A cybersecurity firm has fifteen articles about vendor risk, several product pages, and a new request for a ‘vendor risk management’ hub. The articles overlap, use different definitions, and often link to the home page. Buyers cannot tell which page explains the process, which page compares tools, or which page helps them start a project.
The team maps customer tasks before it maps keywords. It identifies a foundational guide, a practical checklist, an implementation page, a comparison page, and a controlled set of supporting definitions. It also marks three old articles that should be consolidated instead of expanded.
The new map makes ownership visible. Each URL has one main job, a clear internal-link role, and a reason to exist beyond attracting another variant of the same phrase.
Build it step by step
Start with a subject boundary
Write what the cluster includes, what it does not include, and which business capability makes the company credible to publish it. This protects the map from expanding into unrelated topics.
- Record
- a one-paragraph cluster boundary
- Decision it supports
- whether a proposed page belongs in this cluster
- Risk to check
- treating every adjacent phrase as a content opportunity
List customer tasks, not page titles
Describe the questions a person has at different stages: understand the problem, compare approaches, plan implementation, verify risk, or request help. Add evidence from interviews and result-set observations.
- Record
- a task inventory in customer language
- Decision it supports
- which tasks require separate destinations
- Risk to check
- naming pages before understanding the task
Assign one primary URL per task
Choose a canonical destination that will own the core answer. Note its format, audience, commercial role, and proof requirements. Flag collisions where two existing pages compete for the same job.
- Record
- a task-to-URL ownership table
- Decision it supports
- what to keep, merge, redirect, or newly create
- Risk to check
- creating several pages that all answer the same question
Design supporting links deliberately
Plan links that help a reader move from a broad question to a more specific decision. Use descriptive anchor text and place links where the next step makes sense in the content.
- Record
- an internal-link path sketch
- Decision it supports
- how support pages reinforce rather than duplicate the primary URL
- Risk to check
- adding unrelated links only to distribute authority
Sequence the work by readiness
Prioritize pages with strong customer evidence, available subject expertise, clear source material, and a realistic maintenance owner. Do not publish a large cluster just because the map exists.
- Record
- a roadmap with readiness notes
- Decision it supports
- which pages can be built well this quarter
- Risk to check
- using a volume estimate as the only priority signal
Review the cluster after publishing
Check whether the pages remain distinct, links still lead to useful next steps, and customer questions expose a missing route. Update the map when the product, market, or customer language changes.
- Record
- a quarterly cluster review note
- Decision it supports
- whether the architecture still matches real journeys
- Risk to check
- assuming site architecture is permanent after launch
Working template
- Cluster boundary: Define the subject, audience, business relevance, and exclusions. A subject expert should confirm that the team can support the topic.
- Customer task: State the question and decision stage in plain language. A reader should be able to see why the task differs from nearby topics.
- Primary URL: Name the one page that owns the main answer and describe its page role. A content owner should agree not to create a competing duplicate.
- Supporting route: List the supporting page, link context, and customer reason to continue there. A UX or content reviewer should see a logical journey.
- Evidence needed: List experts, sources, product facts, examples, or tools required before publication. The production team should know whether the page is ready to draft.
- Lifecycle decision: Choose create, improve, merge, redirect, retain, or retire with a short reason. A reviewer should be able to audit the choice later.
Quality review before you ship
- Trace a route from a broad customer problem to the most specific helpful page. Every step should reduce uncertainty or offer a credible next choice; remove links that only repeat the same topic label.
- Review hub and child pages together. The hub should help a reader orient themselves, while each child page should earn its place with a distinct question, evidence set, and job to do.
- Before creating a new cluster, name the source of expertise and a maintenance owner. A large diagram is not an information architecture unless someone can keep its claims current and useful.
Decision rules for the real world
Two pages have the same customer job
Do: Choose the stronger destination and make the relationship explicit through consolidation or clear differentiation.
Avoid: Do not keep both vague pages because each has some traffic.
A support page starts attracting the main query
Do: Review whether it should become the owner or link more clearly to the primary answer.
Avoid: Do not add more pages before resolving the conflict.
A topic has demand but no trustworthy source material
Do: Keep it on the research list until an expert, evidence, or original contribution is available.
Avoid: Do not publish a generic summary to fill the gap.
A cluster becomes too large
Do: Split by a meaningful customer journey or product boundary, then assign ownership again.
Avoid: Do not create a hub so broad that it stops guiding choices.
Coach notes
- A topic cluster is an operating map, not a promise that every box will become a page.
- Clear destinations make internal links more useful because each link has a customer reason.
- A good map often recommends fewer pages, not more pages.
Worked example: a commercial solar installer
Research finds demand around system types, financing, tax incentives, roof suitability, industry examples, maintenance, and vendor comparison. The existing site has a flat blog archive, a generic service page, and campaign pages with no clear relationship.
The team creates a commercial solar hub that explains the buying path. It links to system-type guides, financing questions, industry pages with real project evidence, a roof-readiness assessment, and an incentive guide with strict update ownership. Pages that simply repeat a city name are not included.
Make it stronger
Use content inventories as maintenance tools
Add page purpose, owner, last substantive review, evidence type, cluster, internal-link status, and performance notes. An inventory should guide decisions, not become a spreadsheet nobody opens.
Protect against cannibalization
When two pages chase the same task, decide whether to differentiate their purpose, merge them, or use one as supporting evidence. Check query overlap and user paths before changing titles alone.
Design for unfamiliar navigation
Menus cannot show every relationship. Add contextual modules, breadcrumbs, related links, and clear calls to action so visitors can enter from any page and still orient themselves.
Lesson artifact
Topic cluster and destination map
Design one small topic branch and a six-item roadmap.
Customer tasks: List five related tasks and the evidence that they belong near one another.
Page roles: Choose one hub and up to four supporting pages. State the distinct purpose and audience of each.
Link map: Show the parent, sibling, evidence, and next-action links a visitor should encounter.
Release plan: Pick the first coherent slice. Include owner, dependencies, proof needed, quality checks, and measures.
Before you move on
- I grouped demand by customer task, not word similarity alone.
- Every proposed page has a distinct role and useful information.
- The hub and detail pages guide a visitor through a real decision.
- Internal links explain genuine relationships between pages.
- My roadmap includes proof, ownership, dependencies, and a validation plan.
Lesson progress
Finished this lesson?
Save your place on this device so it is easy to pick up where you left off.
Not marked complete yet.
Put the lesson into practice.
Create a free Spacebrain account and use the SEO suite with your own data providers.