Hub and Spoke Content Strategy: How I Built Topic Hubs for My Own Site

For a long time, this blog was what most small business blogs are: a list of posts, newest first, with category filters.

That works for regular readers. It doesn’t help someone arriving from Google who wants to learn a topic properly, and it doesn’t show search engines that the posts belong together. So I rebuilt it around a hub and spoke structure. Here’s what that means, how I did it, and what I’d do the same way again.

What is a hub and spoke content strategy?

A hub and spoke strategy organises content around topics. Each topic has one hub page that gives the overview and links out to more detailed spoke pages, and each spoke links back to the hub.

Think of a bike wheel. The hub sits in the middle, the spokes run out from it, and everything is connected.

The hub answers “where do I start with this topic?” It’s broad, organised and links to everything relevant.
The spokes answer specific questions in depth: one post, one question.
The links run both ways, so readers and search engines can always get from detail back to overview, and from overview to detail.

You’ll also hear it called topic clusters or pillar pages. The labels differ, but the idea is the same.

Does hub and spoke help SEO?

It helps in two ways, neither of them instant.

First, it shows topical authority. Ten disconnected posts about SEO look like ten separate articles. The same ten posts organised under a hub, linking to each other and back, look like a site that covers the subject properly. That’s the signal I wanted, and it’s the reason I built it.

Second, it helps crawling and internal linking. Every spoke is one click from its hub, and the hub is linked from across the site, so no post is left stranded. On a small site that Google is cautious about, that matters. I wrote about getting stuck posts indexed in “Discovered – Currently Not Indexed”.

It isn’t a shortcut. A hub full of thin posts is still thin. In fact, I merged five thin posts before building the hubs, so every spoke was worth linking to.

How I built the hubs

I created three guides, one for each of the main topics the site covers:

Here are the decisions that shaped them.

A reading order, not a category page

My blog already had category filters, and a category page is just a list. If a hub only repeats that list, it adds nothing, and Google has no reason to treat it as a separate page worth indexing.

So each hub is a reading order. The SEO guide, for example, runs in four steps:

Start here: can Google find you? Indexing, site speed, structured data.
Local search. Google Business Profile and reviews.
Fix what’s already there. Content audits and keyword cannibalisation.
Deciding what to spend. SEO costs, and SEO versus Google Ads.

That’s the order I’d actually advise someone to work through it in, and the order is the value.

A note on every spoke

Each post in a hub has a one-line note explaining why to read it at that point, for example “What to fix on your Google Business Profile first, and what to skip.” Those notes are what make the hub a guide rather than an index, and they’re unique content that doesn’t exist anywhere else on the site.

Links in both directions

Every post that belongs to a guide links back up to it, and the guides are listed in the blog sidebar and the site footer. Readers who land on a single post from Google can see there’s a whole path through the topic.

Structure search engines can read

Each hub carries CollectionPage and ItemList schema listing the posts in order, plus breadcrumbs, and the hubs are in the sitemap. It’s the same principle as the rest of my schema work: say in data what the page already says in words.

Built not to break

Hubs refer to posts by their URL slug. If I merge or retire a post, the hub quietly skips it rather than showing a broken link. That keeps the site tidy, but it can leave a section thin, so updating the hubs is now part of my routine whenever posts change.

What’s happened so far

The hubs have only just gone live, so there are no results to report yet. I’ll be watching three things in Search Console: whether the guide pages get indexed, whether they start appearing for broader topic searches, and whether impressions spread more evenly across the posts inside each hub.

What I’d tell you

Organise around topics, not dates. A blog sorted newest-first hides your best work the moment you publish something new.

Fix the spokes before building the hub. Merge or improve thin posts first. A hub only shows authority if the posts behind it have some.
Make the hub a guide, not a list. Put the posts in a deliberate order and say why each one matters. If it’s just links, it’s a category page.
Link both ways. Hub to spokes, and every spoke back to the hub.
Keep it maintained. Every time you merge, retire or publish a post, check which hub it belongs to.

FAQ

What is a hub and spoke content model?

It’s a way of organising website content around topics. A central hub page gives an overview of a topic and links to detailed spoke pages, each covering one specific question, and each spoke links back to the hub.

What is the difference between hub and spoke and topic clusters?

They’re essentially the same idea under different names. “Topic cluster” and “pillar page” usually describe the same structure: one broad page connected to a group of detailed, related pages.

Does hub and spoke content help SEO?

It can. It helps search engines see that your content covers a topic in depth (topical authority), and it improves internal linking so every page is easy to find and crawl. It won’t make weak content rank, though.

How many spoke pages should a hub have?

There’s no fixed number. It should be enough to cover the topic’s main questions properly. My SEO hub has ten posts; the other two are smaller and will grow. A hub with only one or two spokes is usually a sign the topic needs more content first.

Should a hub page be a blog post or a separate page?

A separate page usually works better. A hub needs to be kept up to date as new spokes are added, and it has a different job from a post: it guides rather than answers. I built mine as their own guide pages rather than as blog posts.