Hub-and-spoke content architecture: build a cluster people can navigate

Keep interventions, hypotheses, assets, observations and decisions in a searchable workspace. Record what is known and what still needs checking.

A hub-and-spoke architecture organises a subject around one broad page and a set of focused supporting pages. The hub explains the territory and helps readers choose a path. Each spoke answers one narrower question completely, then reconnects the reader to the larger topic. The model is useful because it turns a collection of posts into an understandable system—but only when the pages have distinct jobs.

The diagram is not the strategy. Publishing ten articles that repeat the same definition under slightly different titles creates overlap, not authority. A useful cluster begins with evidence about what people need, what the site already covers and where a separate page would genuinely improve the journey.

What belongs on the hub

The hub serves a broad, durable intent. It introduces the problem, defines important concepts, frames the available choices and links to deeper answers. It should be valuable on its own rather than acting as a thin list of links. At the same time, it should not absorb every operational detail that deserves a dedicated page.

A product category page can also function as a hub when it matches the intent. Do not create an informational article merely to compete with a page that already helps users evaluate the product. Decide which page should own the broad query before writing.

What makes a spoke independent

A spoke needs a question it can answer better than the hub. Good candidates include setup procedures, comparisons, troubleshooting, measurement methods and concrete use cases. A heading expanded into 1,500 words is not automatically a valid spoke.

Before approving a page, write its one-sentence promise and compare it with every nearby article. If two pages would have the same introduction, examples and CTA, merge them or sharpen their boundaries. The guide to deciding whether to update a page or create a new article provides a practical decision process.

Search demand helps, but volume alone should not dictate architecture. A low-volume question can be essential to a buyer, while a broad high-volume term may be too ambiguous for a useful page. Combine query evidence with products, customer objections and the next decision the reader must make.

Build the cluster from evidence

Start with an inventory of existing URLs. Record the primary purpose, target audience, current search queries, internal links and last substantial update. Google Search Console reveals the language people already use to find the site; a crawl or sitemap shows what is actually published. Together they expose gaps and collisions.

Then group candidate questions by intent, not by repeated words. “What is BYOK?”, “How do I connect OpenRouter?” and “How do I limit OpenRouter spend?” share a product context but represent definition, setup and cost control. They can support one provider hub without competing for the same job.

Plan links before publishing

Avoid forcing the same anchor text into every page. Describe what the destination helps the reader do. Internal links should clarify the information architecture, not imitate a keyword-density formula.

Measure pages separately and as a system

Evaluate each URL against its own purpose. A setup guide may succeed through engaged visits and product activation; a definition page may earn impressions and assisted discovery. Search Console data can show whether several pages rotate for the same queries, but similar queries are not proof of cannibalisation by themselves.

At cluster level, watch whether the hub gains qualified entry queries, whether spokes attract their intended long-tail needs and whether readers can move to the next useful step. Review the network after major product changes. A cluster that described last year’s workflow can remain internally coherent while becoming factually obsolete.

Common mistakes

The first is building the cluster from a keyword export without inspecting the site. This produces duplicate pages and ignores content that already ranks. The second is choosing a hub so broad that it cannot satisfy a recognisable intent. The third is publishing all spokes together without reviewing claims, links and product availability.

Another mistake is assuming that more pages automatically demonstrate topical authority. Coverage must be useful, accurate and navigable. Five distinct answers with evidence can create a stronger resource than fifty interchangeable articles.

Frequently asked questions

How many spokes should a hub have?

There is no ideal number. Add a spoke when a distinct user task deserves a standalone answer and the site can maintain it. Stop when new pages would repeat existing jobs.

Should the hub target the highest-volume keyword?

Not necessarily. It should own the broad intent that best organises the subject and supports the business. Volume is one input, not the architecture.

Can an existing article become the hub?

Yes. Updating a credible page is often better than creating a new URL. Preserve its useful history, clarify its scope and add links only after the supporting pages exist.

Does hub-and-spoke architecture guarantee rankings?

No. It improves clarity and coverage, but rankings also depend on relevance, competition, technical accessibility, evidence and many external factors.

Turn the map into an editorial decision system

A strong hub-and-spoke model tells editors what each page is for, what it must not duplicate and where the reader should go next. Build it from the live site and audience evidence, then maintain it as the product and market change.

What BeKnow keeps

Keep interventions, hypotheses, assets, observations and decisions in a searchable workspace. Record what is known and what still needs checking.

A change in performance after an intervention does not prove that the intervention caused it. Cross-platform attribution and a complete analytics dashboard are not available today.

Project memory and data imports do not require an AI model key. A compatible external AI client may have its own costs. BYOK applies only to available functions that actually call an external provider.

Next step

Start with one project, one documented change and the evidence needed to review it. Source connections.

Record your first intervention. How it works.