How to plan topic clusters for your blog

Many small-brand blogs grow the way a garage fills up. There is a post about pricing from March and a trade-show recap from June. Somewhere in there sits a how-to a customer once asked for, beside an announcement nobody read. Each one made sense on the day it went up. Together they make a pile, and neither a reader nor a search crawler can tell what the site actually knows.

A topic cluster fixes the pile. You pick one subject your business should be known for and write one broad page that covers it. Then you write a set of narrower pages, each answering one question inside that subject, and link the lot together so the relationships are obvious. Planning one takes an afternoon and a spreadsheet. This is how to spend the afternoon well.

What a topic cluster is, and what it can't do

HubSpot's research team set out the model in 2017, and its basic shape still holds. There is a pillar page that covers a broad subject. Around it sit cluster pages, usually called spokes, that go deep on subtopics. Descriptive internal links run in both directions between them. The habit it replaced was one keyword, one isolated article, repeated until the calendar ran out.

It is worth being plain about the limits early. Google does not list topic clusters as a ranking factor. A cluster is an arrangement of pages. What Google does document is that it reads internal links to understand how pages relate and which ones a site treats as important, and that its systems aim to reward helpful content written for people. A cluster supports the first and gives you a frame for the second. It cannot guarantee rankings, traffic or a mention in an AI assistant's answer. Those depend on things outside your site, such as what other sites say about you, and on whether your pages are accurate in the first place.

The case for a cluster is that it forces decisions a small team otherwise puts off. Every article gets a job and a boundary. Readers get a path from a broad question to a specific one, and crawlers get the same path. You also stop writing the same post twice under different titles, which is the quietest waste on a one-person content calendar.

Choose a pillar your business can own

The pillar test has two halves. The subject must be broad enough to split into at least five to ten distinct subtopics. It must also be specific enough to tie straight back to what you sell. Fail the first and you have an article. Fail the second and you have an encyclopedia entry that brings in readers who will never buy from you.

Take a company selling inventory software to online shops.

The same logic works for a service business. A bookkeeping firm that mostly serves restaurants should build its pillar on bookkeeping for restaurants, and leave "small business finance" to the banks.

Plan one cluster and finish it before you plan a second. A half-built cluster is a pile with a better name.

Find spokes in the questions people already ask

You do not need to guess what the spokes should be. The questions are already sitting in three places.

Google Search Console is the first. Look at the queries your existing pages appear for, especially the ones you never wrote for on purpose. Impressions on a query with no page built to answer it are a spoke waiting to be written. Your support inbox and sales notes come next. The questions customers send in their own words often make better spoke titles than anything a keyword tool suggests. Keyword tools are still useful for checking how people phrase a question and roughly how often they ask it.

As you list candidates, sort them by what the reader is trying to do. Some are learning ("what is a reorder point"). Some are comparing options before a purchase ("inventory software for small Shopify stores"). Some are trying to get a task done ("how to run a cycle count"). A cluster made only of definitions attracts students. One made only of comparison pages reads like a brochure. Mix the stages so the cluster serves someone at every point between curiosity and purchase.

If you would rather not build the spreadsheet by hand, there are tools for it. Rune, which publishes this journal, plans clusters from keyword, competitor and Search Console data alongside what your site already covers. Whichever route you take, deciding which questions matter to your customers is an editorial call, and it stays with you.

Draw the boundaries before anyone writes

This step is easy to skip, and it saves the most work. For every spoke on the list, write a single sentence stating the question it answers. Then check that sentence against every other spoke and every post you have already published.

You will find overlaps. "What is a reorder point" and "how to calculate a reorder point" will share most of their paragraphs, so they are one article. An old post that half-answers a planned spoke should be rewritten into that spoke, or merged into it with a redirect. Two pages chasing the same question compete with each other, and the reader lands on whichever one happens to surface, which is not necessarily your better one.

The opposite mistake is over-clustering: slicing one coherent idea into five thin posts so the diagram looks fuller. Google's guidance on helpful content asks whether a page offers substantial value and original analysis beyond what is already available. Five pages of three hundred words each, all circling the same point, struggle to pass that test. If a spoke cannot carry a complete answer on its own, it belongs inside another article as a section.

Write spokes that stand on their own

A spoke should answer its question fully, early and accurately, as if the reader will never see another page on your site, because many won't. Treat it as a destination. A spoke that exists mainly to point at the pillar wastes the reader's click.

This matters more now that AI assistants search the web. These systems generally work with specific passages of a page rather than the whole site, so a paragraph that answers a question cleanly has something to offer and a paragraph that says "see our complete guide" has little. Nothing guarantees a passage gets picked up. Still, a spoke written to be useful on its own is the same spoke a human reader arriving from search wants to find.

The pillar has a different job. It gives the overview, covers each subtopic in a paragraph or two, and links out to the spoke for depth. Resist pasting whole spokes into it. A pillar that repeats every spoke in full competes with its own cluster.

Wire the links so they can be followed

Google's documentation is specific about what counts as a link it can crawl: an HTML <a> element with an href attribute. A JavaScript click handler on a styled box is not a crawl path, and neither is a product name mentioned in plain text. Check your CMS here. Some related-post widgets and card layouts render links in ways a crawler cannot follow.

The pattern itself is simple. Every spoke links to the pillar using descriptive anchor text, such as "our guide to e-commerce inventory management", never "read more". The pillar links to every spoke. Spokes link to each other where their subjects genuinely meet, so the cycle-count article mentions reorder points and links there. Forced cross-links between every pair of spokes help nobody.

Google also says it uses navigation and internal link patterns to judge which pages a site treats as important, so put the pillar somewhere prominent, ideally reachable from your main navigation. Its starter guide recommends grouping topically similar pages in directories, for example keeping the whole cluster under /inventory-management/. If your URLs already exist elsewhere, weigh that against the cost of moving them. Changing live URLs means setting up redirects, and a tidy folder is not worth broken links.

Publish in an order that makes sense

You can release a cluster all at once or one article at a time as each clears review. For a team of one or two, the second is usually the only honest option.

Write two or three of the strongest spokes first, then the pillar, because the pillar summarizes them and is easier to write once they exist. Publish the pillar with the spokes you have and link to each new spoke the day it goes live. Updating the pillar every time is part of the job, and it is the step that slips first when the calendar gets busy, so put it on the checklist.

When the cluster is complete, review it in Search Console as a group. If you used a directory, filter by that path. Look for spokes that appear for queries belonging to a sibling, which usually means a boundary needs redrawing, and for questions the cluster still does not answer. Those become the next spokes, or the start of the next pillar.

A topic cluster is mostly a set of editorial decisions made before writing starts: which subject you will own, which questions belong to it, where each article stops. The links and folders are bookkeeping that make those decisions legible. Plan one, finish it, then look at what readers did with it. If you want to see how the first two articles of a cluster might read in your own voice before giving it an afternoon, Rune's free preview writes two illustrated articles from your site and a short brief.