Hubs, clusters and support pages
Choose page roles around the work a reader needs to do.
A hub introduces a subject and helps readers choose a useful route. A support page develops a bounded task in more detail. A bridge connects related tasks when the reader needs an explanation of how to move between them. These are editorial roles, not fixed search engine page types.
Free learning from Semantec SEO.
Define the entry, supporting and bridge roles.
An entry page gives a reader enough orientation to understand the subject, recognize the available tasks and choose a route. It can answer the introductory question itself. It should not become a list of links with no explanation of what those destinations offer.
A supporting page answers a focused question that needs its own explanation, example or evidence. Its opening should make sense to a visitor who arrives directly. A support page is not automatically less useful to the reader than the entry page; it simply has a narrower job in this plan.
A bridge task helps someone move from one decision to a related one. For example, understanding growing conditions can lead to comparing suitable watering arrangements. Often a short explanation and a contextual link within an existing page can do that work. Create a separate bridge page only if the transition has an independent, detailed answer.
A cluster is a proposed group of related pages connected by these tasks. Calling a resource a hub or a spoke does not grant it a ranking property. Choose roles to make the website understandable, then check that the pages and links perform their stated jobs.
Collect the inputs before drawing a cluster.
Start with the website purpose, intended audience, candidate questions, source records and current page inventory. Record what the business can explain or provide. A commercial service may support a learning cluster, but the lessons must still answer their promised questions.
Write one task statement per proposed resource: who needs the answer, what they need to decide, which conditions change it and what useful action follows. Compare statements for overlap before inventing titles. A different keyword spelling does not establish a new task.
Inspect existing destinations and useful media or tools. A current resource may already own the answer. Keep its route as a candidate, record any missing material and avoid creating a second page simply because a planning sheet has an empty row.
Worked example: one entry page and two support pages.
Consider a fictional educational website explaining small greenhouse planning. The scenario and proposed questions below are invented for teaching. They are not a horticultural recommendation, a search volume study or a report about a client.
The entry task is “understand the decisions needed before planning a small greenhouse”. Its answer introduces site conditions, watering needs, scope limits and the two deeper tasks. It does not claim a particular greenhouse is suitable for a real property.
Support A serves “record the growing conditions that constrain the plan”. It explains what needs observing, how to keep a site record and which unknowns need a qualified source. Support B serves “compare watering arrangements against the stated requirements”. It explains the comparison record and the facts to verify for any named arrangement.
The entry page links to A at the point where it explains site conditions and to B when introducing watering requirements. A refers to B after the reader has recorded the conditions that affect watering. B links back to A if those conditions remain unknown, and both offer a return to the entry overview. The relationship is explained in text instead of leaving the reader to infer it from a diagram.
| Resource | Main task | What it includes | What it leaves elsewhere |
|---|---|---|---|
| Entry overview | Understand the planning decisions | Definitions, boundaries, summary of conditions and watering tasks | Detailed records and comparison criteria |
| Support A | Record site conditions | Observation fields, source needs, unresolved constraints | Detailed watering comparison |
| Support B | Compare watering arrangements | Requirements, comparison fields, evidence checks | Full explanation of recording site conditions |
Explain why this example uses two support pages.
Two support pages follow from two distinct answers in this example. Recording conditions and comparing watering arrangements require different inputs and produce different records. Neither task is adequately completed by a short label in the overview, so each has a candidate destination.
The count is not a quota. If the overview can explain both tasks clearly with the necessary detail, a single resource may be enough. If research reveals a distinct task with its own evidence and audience, another page may be justified. Do not add pages merely to make the cluster look symmetrical.
Count supported tasks after deciding the boundaries. Do not start with a target number of spokes and expand the subject until it fits. An empty or repetitive support page weakens the reader journey even if it satisfies the layout of a planning diagram.
Keep the bridge proportionate to its answer.
In the example, the transition from a site record to watering comparison can be a short paragraph in Support A: explain which recorded conditions affect the comparison, name the next task and link to Support B. That is a bridge function without a new URL.
A distinct planning checklist might later deserve its own page if it combines the outputs into a new decision and has supported instructions. The editor would first define that task, identify its required facts and check for an existing owner. “Related topic” alone is not enough.
Avoid forcing every visitor through the entry page. Someone who already knows their conditions should be able to use the comparison directly. Provide concise background and a clear return route without duplicating the entire cluster on every page.
Review the links and the page roles together.
Use ordinary links with useful anchor text that names the destination task. Link where the next explanation is relevant. Check the destination, the return route, any fragment identifier and the consistency of the label after publication.
A directory or navigation menu can provide a broad route. Contextual links add the reason to follow it at a particular point in the answer. More links are not automatically more useful; remove repeated links that interrupt reading without adding a route.
Google’s link documentation explains crawlable anchor links and descriptive link text. The roles and the two page count here are editorial decisions, not requirements from that documentation.
Handle shared detail and changing cluster boundaries.
A short definition can appear on the entry page and again as necessary orientation on a supporting resource. Keep its meaning consistent and give the full explanation one accountable owner. Necessary repetition is different from publishing two interchangeable full answers.
Some resources serve tasks in more than one cluster. Choose their main role and owner, then link to them from each relevant parent. Copying the resource into every branch creates maintenance work and can confuse the intended destination.
When the topic or offer changes, reassess the tasks, sources, links and page boundaries. A published overview does not establish that all its proposed support pages are complete. Keep incomplete sources and unresolved tasks visible in the project record.
Use a role record before briefing or release.
For each candidate, record its task, main role, owner URL, required evidence, example, incoming link, return route, exclusions and current state. Ask another editor to explain the difference between the resources using only those records. If the roles still blur, revise the boundaries before drafting more pages.
Use page or content block decisions when a supporting answer may fit within an existing resource. Use topic ownership when two candidates claim the same answer. Return to the topical mapping overview or the learning overview.