How to Build a Hub-and-Spoke Site Architecture for GEO

Why does hub-and-spoke suit AI search?

AI search engines rarely answer from a single page. Google describes its AI Overviews and AI Mode as using query fan-out, issuing multiple related searches across subtopics to build one answer. Other assistants search in a similar way when a question needs more than one source. A hub-and-spoke site gives those searches something to find at each level:

• the hub matches broad questions such as "what are the options for treating anxiety?";
• each spoke matches a narrower question, such as "how long does CBT for anxiety take?";
• links between them show engines and readers how the pages relate, and which one is the main reference.

The structure also prevents a common failure: many overlapping pages competing for the same question, none clearly the best source. How fan-out works in more detail is covered in what query fan-out is and how LLMs use it.

How do you plan hubs and spokes?

Planning which topics and entities your site should cover is covered in how to map topic clusters and entities for AI visibility. Turning that map into an architecture takes four decisions:

1. Choose hubs by buyer need, not by product list. A hub should match a broad question people ask, such as "home extension costs" rather than "our extension services".
2. List spoke questions under each hub from sales calls, support tickets and search data. Each spoke answers one distinct question with enough substance for its own page.
3. Merge thin ideas. If a question can be answered well in a paragraph, it belongs on the hub or another spoke, not on its own page.
4. Decide the entry points: which hubs belong in the main navigation, and which spokes are reached only from their hub.

A typical small site has 3–8 hubs with 5–20 spokes each. Bigger is not better: every spoke must earn its place with information a reader needs.

What should a hub page contain?

A hub that is only a list of links gives engines nothing to cite. A strong hub:

• opens with a direct answer to the broad question in a few sentences;
• compares the main options in a short table: what each is, who it suits, typical cost or time;
• summarises each spoke in one or two sentences with a descriptive link, so the hub is useful even if nobody clicks;
• states the key facts once, such as prices, service areas or eligibility, so spokes can stay consistent with it;
• names who wrote or reviewed it, with relevant credentials;
• ends with the most common questions that do not need their own spoke.

What should a spoke page contain?

Each spoke should work as if it were the only page someone reads. That means a direct answer at the top, then the detail: steps, costs, timelines, exceptions and examples. It should include the facts a reader needs without having to visit the hub. A short link back to the hub near the top gives context for readers who arrived from an AI answer.

A simple spoke template:

How should URLs, navigation and links be set up?

• URLs: put spokes in a folder under their hub, such as /anxiety-treatment/ for the hub and /anxiety-treatment/cbt/ for a spoke. Engines do not require this, but it keeps the structure clear and lets you group pages by folder in Search Console and other reports.
• Breadcrumbs: show the path on every spoke and mark it up with BreadcrumbList structured data.
• Hub to spokes: link every spoke from its hub with anchor text that describes the question it answers.
• Spoke to hub: link back near the top and in the breadcrumb.
• Spoke to spoke: link to two to four siblings where the reader's next question is answered. Linking everything to everything dilutes the signal.
• Plain HTML links: navigation and links injected only by JavaScript are invisible to AI crawlers that do not render scripts.
• No orphans: every spoke should be reachable from its hub and listed in the sitemap.

How do you build silo-based GEO pages for addiction and mental health services?

Addiction and mental health services are a good example of where structure helps and where it needs extra care. People ask very specific questions, often in distress, and engines treat health topics as high-stakes, favouring clearly qualified, accurate sources.

A practical structure for a treatment provider:

• Hub: addiction treatment. Spokes for each level of care (medically supervised detox, residential, partial hospitalisation, intensive outpatient, outpatient), for specific substances where you have genuine programmes, for paying for treatment (insurance, costs), and for families.
• Hub: mental health services. Spokes for the conditions you treat, the therapies you offer (such as CBT or DBT), and how assessment and admission work.
• Location pages only for sites where you actually provide care, each with its own address, services, staff and admissions details.

The extra requirements for this sector:

1. Clinical review. Name the clinician who reviewed each page, their credentials, and the date of their most recent review.
2. Licensing and accreditation. State your licences and any accreditation, such as from The Joint Commission or CARF in the US, on the hub and relevant spokes, and make sure directories show the same.
3. Crisis information. Put emergency and crisis contacts, such as the 988 Suicide & Crisis Lifeline in the US, on every page where someone might be at risk.
4. No guarantees. Avoid success rates or outcome promises you cannot support, and never use patient stories without explicit consent.
5. Consistency. Levels of care, insurance accepted and admission criteria should match across the hub, spokes, your business profiles and treatment directories.
6. No doorway pages. Pages for cities you do not serve, differing only in the place name, break Google's spam policies and undermine trust in the whole site.

More on high-stakes health content is covered in how healthcare and other YMYL businesses can improve AI visibility.

What mistakes weaken a hub-and-spoke structure?

• Hubs that are link lists, which give engines little to quote and are rarely cited for broad questions.
• Thin spokes that repeat the hub with a keyword swapped.
• Cannibalisation, where the hub and a spoke both try to answer the same specific question.
• Contradictory facts between hub and spokes, such as different prices or opening hours.
• JavaScript-only menus and tabs that hide links or content from non-rendering crawlers.
• Orphaned spokes after redesigns, reachable only through site search.

How do you tell whether the architecture is working?

For each hub, list 5–10 broad questions and, for each spoke, 3–5 specific ones. Run them in the AI engines your customers use at regular intervals and record which of your pages are cited:

• the hub should appear for broad questions;
• spokes should appear for their specific questions;
• if the hub is cited for a specific question, the spoke may be too thin or poorly linked;
• if nothing is cited, check crawl access and whether the page directly answers the question.

Group pages by folder in Search Console's performance reports, including the Generative AI performance report, to compare hubs over time.

What do people ask about hub-and-spoke for GEO?

Is hub-and-spoke still relevant for AI search?

Yes. Engines still retrieve individual pages, and a clear structure helps them find the most specific, relevant page for each part of a question.

How long should a hub page be?

Long enough to answer the broad question and summarise each spoke, often 1,500–3,000 words. Detail belongs on the spokes.

Should I rebuild my whole site at once?

No. Start with the topic that matters most commercially, build one hub with its spokes, measure it, then extend the pattern.

Can a spoke belong to two hubs?

It can be linked from both, but give it one home folder and one breadcrumb path, so its place in the structure is clear.