Topic clusters for SEO: hubs, spokes and the links between them
A topic cluster is a hub page for a broad question plus spokes for narrow ones, linked both ways. How to build one from your own Search Console queries.
LLaunchScaler·Published ·7 min read
A topic cluster is a set of pages on one subject: a hub page that answers the broad question and links to every narrower page, and spoke pages that each answer one specific question and link back to the hub with descriptive anchor text. Build clusters from the queries your site already appears for in Search Console, and add links between sibling spokes only where a reader would want the next page.
That structure does two jobs. It gives readers a path from a broad question to the detail they need, and it gives every page on the subject internal links from related pages. This guide builds one cluster end to end, with the linking rules for each kind of page.
What is a topic cluster in SEO?
A topic cluster is a hub page plus the spoke pages it links to, all about one subject. The hub, often called a pillar page, gives a complete short answer to the broad question and then a section per subtopic, each linking to the spoke that covers it in depth. Each spoke answers one narrow question fully and links back to the hub.
Clusters are a way of organising internal links, not a Google feature. Google's link guidance explains why the links matter: Google uses links to find pages and as a signal of what they are about, anchor text "tells people and Google something about the page you're linking to," and "every page you care about should have a link from at least one other page on your site." A cluster guarantees that every spoke is linked from its hub, in the section about its subject, and links back to it.
Page
Answers
Links out to
Linked from
Hub
The broad question, briefly, then one section per subtopic
Every spoke, from the section that covers it
Navigation, related hubs, every spoke
Questions, answered
What people ask about this
01
What is a topic cluster in SEO?
A topic cluster is a group of pages on one subject: a hub page (also called a pillar page) that answers the broad question and links to every narrower page, and spoke pages that each answer one specific question and link back to the hub.
02
What is the difference between a pillar page and a hub page?
Choose cluster topics from your own Search Console queries. Group the queries your site already appears for by subject; a subject with many queries across different intents is a cluster, the broadest query in it is the hub, and the narrower questions are spokes. A generic keyword list tells you what exists; your queries tell you where Google already sees you as relevant.
Export the Queries tab from the Performance report for the last 3 months.
Label each query with a subject (two or three words) and an intent (how-to, troubleshooting, comparison, definition, pricing).
Count queries per subject. Subjects with the most queries and impressions are your cluster candidates.
Keep three to six clusters, the subjects closest to what your product does.
Within each, pick the broadest query as the hub topic and group the rest into spoke topics, one per distinct intent.
On sites with a large volume of queries, Search Console Insights now offers Query groups, which Google announced in October 2025 and computes with AI to group similar queries. They are a useful first pass, but check them against intent, since a group can mix questions that need different pages. The full grouping method is in turning Search Console queries into a content plan.
How do you build one topic cluster end to end?
Build the hub first, then the spokes it links to, in order of how many searchers each spoke serves. The example below builds a cluster for a scheduling app on the subject "team availability," from queries the site already appears for.
These are the queries, grouped by intent, with the page each group gets:
Query group
Page
Role
"how to see team availability", "team availability calendar"
How to see your team's availability in one place
Hub
"share availability with clients", "send availability link"
How to share your availability with clients
Spoke
"availability across time zones", "schedule meeting different time zones"
Scheduling across time zones
Spoke
"sync google and outlook calendar availability"
Combining Google and Outlook calendars
Spoke
"availability not updating", "calendar busy times wrong"
Fixing availability that shows the wrong times
Spoke
"team availability tools compared"
Team availability tools compared
Spoke
Then build it in this order:
Write the hub: answer "how to see team availability" in the first two sentences, then one H2 per spoke topic with a 40 to 60 word answer and a link to the spoke.
Write the spokes, highest-impression group first. Each opens with its own direct answer and links back to the hub in its first few paragraphs.
As each spoke publishes, update the hub section that covers it so the link goes live the same day.
Add sibling links where the reader's next question is another spoke: the sync guide links to the fix guide, because someone who has just combined two calendars may next need to fix busy times that look wrong.
Keep the hub useful on its own. A reader who never clicks a spoke should still leave with a correct short answer to every subtopic, and a reader who wants more should find the link exactly where the short answer stops. A hub that is only a list of links serves neither reader.
What are the linking rules between hubs and spokes?
The hub links to every spoke from the section that covers it; every spoke links back to the hub; siblings link to each other only where the reader's next step is on the other page. Use anchor text that describes the destination, not "click here" or "read more." That is the whole rule set.
Google's link guidance gives the anchor text rules in detail:
Good anchor text is "descriptive, reasonably concise, and relevant to the page that it's on and to the page it links to."
Generic anchors such as "click here," "read more" or "website" are its examples of bad anchor text.
Read the anchor out of context. If you cannot tell what the linked page is about, the anchor needs more words.
Do not stuff keywords into anchors; Google reminds you that keyword stuffing violates its spam policies.
Give each link context: the words around it matter, and links chained next to each other lose it.
On numbers, Google is deliberately vague: "There's no magical ideal number of links a given page should contain. However, if you think it's too much, then it probably is." A hub with one link per spoke section, and spokes with one link back plus one or two sibling links, stays well clear of that.
Use crawlable links: Google says it can generally only crawl a link if it is an <a> element with an href attribute, so links added as click handlers on other elements may not be followed. Internal linking for a new blog covers the rest of the linking rules.
Do you need a separate URL folder for each cluster?
No. Clusters are defined by links and content, not URLs. Google's SEO starter guide says grouping topically similar pages in directories matters mainly for sites with more than a few thousand URLs, because it can help Google learn how often each directory changes. A small blog can keep flat URLs such as /blog/share-availability.
If you do use folders, keep them stable. Changing URLs to fit a new cluster structure means redirects for every moved page, which costs more than the folder gains on a small site.
How do you know a topic cluster is working?
A cluster is working when the hub and spokes gain impressions for the cluster's queries and the spokes pick up queries you did not plan for. Check it monthly in the Performance report, filtered to the cluster's pages, comparing the last 28 days with the 28 days before.
Filter Pages by the cluster's URLs, or with a regex that matches them.
On the Queries tab, look for new queries related to the subject; each is a candidate spoke or a section to add.
Check each query's Pages tab. If the hub and a spoke both appear for one narrow query, make the spoke the clear answer and have the hub link to it with that wording.
If a spoke gets no impressions after two months, check it is indexed, then whether its question is one people search.
When a cluster runs out of new questions, start the next one. The SEO content strategy for a SaaS shows how clusters fit into a month's plan and calendar.
Get a month of articles already grouped into clusters
LaunchScaler's content engine builds the grouping into its plan. It reads your own Search Console queries first, the searches you already rank for just off page one, and lays out a month of articles "grouped into a handful of subjects your product owns," on a calendar where any day can move to another open day. It writes one article a day from your product, and by default every draft waits for your review before it publishes. Approved drafts go to WordPress, Webflow, Ghost, Shopify, Notion, Medium or a signed webhook. It is $99/mo per website, with 3 days free and thirty articles a month. Start the engine and add your hub-and-spoke links as each draft is approved.
They are two names for the same thing: the page at the centre of a cluster that covers the broad topic and links to every spoke. What matters is that it answers the broad question on its own and links to each spoke with descriptive anchor text.
03
How many articles should a topic cluster have?
As many as there are distinct questions within the topic that people actually search. For a small site that can be five to fifteen spokes per hub. Stop when the next spoke would repeat one you already have.
04
Should spoke pages link to each other?
Where it helps the reader. A spoke about setting something up can link to the spoke about fixing it when it breaks. Do not link every spoke to every other spoke by default; Google's link guidance says if a page has too many links, it probably does.
05
How do I choose topics for clusters?
From your own Search Console queries, not a generic keyword list. Group the queries your site already appears for by subject; subjects with many queries become clusters, and the broadest query in each becomes the hub.
Only after a significant update. Keep the original published date, add a visible Updated date, match dateModified to it, and move lastmod at the same time.
Create and publish a Webflow CMS post with the Data API v2: a cms:write token, the collection's field slugs, HTML rich text and the rate-limit headers.
The Application Passwords section disappears when WordPress can't detect HTTPS or a plugin disables it. Every cause, how to spot it, and the exact fix.
