# Planning a topic cluster from one seed keyword

> Turn one seed into a hub page and the spoke pages under it: research the ideas, group them with tags, record the pages' roles, and audit the links between them.

Source: https://netweft.com/blog/planning-a-topic-cluster
Updated: 2026-10-15

**Research a seed, group the ideas into one broad hub term and the narrower questions under it with tags, give each planned page one group, record the pages as hub and spoke key pages in project context, and audit the cluster for orphan pages once it is live.**

A topic cluster is one broad page, the hub, and the narrower pages that each
answer one part of its topic, the spokes, all linked to each other. It gives a
site one clear answer per question and a path between them, which is easier to
rank and easier to read than many pages that overlap.

## 1. Research the seed

In [Keyword research](/docs/keyword-research), enter the topic as a seed, such
as `email deliverability`, and fetch 200 ideas. One lookup holds up to
360 credits whatever the count, so the largest list costs
no more than the smallest.

Sort by **Volume** and read the **Intent** column. Informational ideas become
spokes; commercial and transactional ones belong on product or comparison
pages, not in the cluster.

## 2. Group the ideas into pages

Most ideas are variants of a few questions. Group them so that each group is
one page:

| Group | Example ideas | Page |
| --- | --- | --- |
| The broad term | email deliverability, what is email deliverability | hub |
| One sub-question | spf record, how to set up spf | spoke |
| Another sub-question | dkim vs dmarc, dmarc policy | spoke |

Save the ideas you keep and tag each one with its page, for example
`cluster: deliverability / spf`. Tags hold up to 60 characters, and the tag
filter on [Saved keywords](/docs/saved-keywords-and-tags) then shows one
page's keywords at a time.

Check **Difficulty** per group. Write the easiest spokes first: they can rank
while the hub is still new, and their links help the hub.

## 3. Record the pages and their roles

In the project's [context](/docs/project-context), add each page under **Key
pages** with its role: `hub` for the broad page, `spoke` for the others, and
the topic of its tag. The [assistant](/docs/project-assistant) and any agent
connected over MCP read this list, so a question such as "which spoke pages
have critical issues in the last audit?" is answered against the plan.

## 4. Link and audit

Every spoke links to the hub, and the hub links to every spoke. Once the pages
are live, run a [site audit](/docs/site-audit) from the hub's URL:

- **Orphan page** means a spoke nothing links to.
- **Page links nowhere** means a page with no links to the rest of the site,
  so it passes nothing on to the hub.
- **Duplicate title** and **Duplicate page content** mean two spokes answer
  the same question; merge them.

## 5. Track one keyword per page

Add each page's main keyword to a rank tracker. One keyword per page is enough
to see the cluster move; the rest of the group follows it. A check at the
default depth costs 40 credits per keyword per device.