A topic cluster groups related pages around a useful overview. The pillar page explains the broad subject. Supporting pages handle narrower tasks, such as following a procedure, choosing an approach or using a template. Internal links help readers move between those answers.
Start with the pages you already have. Assign each important reader task to an existing URL where possible, identify the questions still unanswered, and create a new page only when it adds a distinct, useful answer. This guide gives you a planning sequence, a worked example and a worksheet for making those decisions.
What the pillar page should do
A pillar page should leave a newcomer with a working understanding of the subject. It introduces the main decisions, explains how the parts relate and links to deeper resources when they are useful.
For a subject such as product team rituals, the overview might explain which recurring activities help a team coordinate and how to choose a manageable routine. A supporting guide can teach a specific activity in detail. The pillar does not need to reproduce that entire procedure.
An index or category page can help people browse, but its role differs from an explanatory pillar. Decide what the reader needs from the overview before choosing the format. There is no required article length or supporting-page count. Google's people-first content guidance asks whether the content serves its audience rather than a supposed preferred word count.
Topic clusters, folders and content silos
These describe different planning choices:
| Choice | What it organizes | Practical question |
|---|---|---|
| Topic cluster | Related reader tasks and links between their answers | Can a person find the overview and the next useful detail? |
| URL folder | Addresses within the site | Does the URL structure remain understandable and maintainable? |
| Content silo | Content grouped within a defined subject area | Does the grouping help navigation without hiding useful connections? |
A topic cluster can use a shared folder, but it does not require one. A site can also use folders and contextual links together. Avoid making URL structure a substitute for deciding what each page contributes.
If a reader needs a related page in another section, link to it where that need arises. A rigid rule against links across sections can interrupt the reading path.
Build the cluster from existing coverage
1. Choose a subject you can serve well
Name the audience, its broad problem and why your organization can help. Use language the audience recognizes. A subject belongs in the plan when it connects to your expertise and business, not simply because a keyword tool suggests it.
Write a short scope statement: “Help small product teams choose and run recurring coordination activities.” This keeps unrelated meeting advice out of the cluster without assuming every related question needs a separate article.
2. Inventory the current answers
Collect relevant pages from your sitemap, navigation and content records, then read them. Record the actual URL and the reader task each page serves. A title alone may conceal thin, outdated or overlapping content.
Use a content audit when you need to decide what to keep, update or consolidate across the site. This cluster plan uses those decisions to arrange a particular subject.
3. Gather questions and record their origin
Support conversations, sales questions, site search and interviews can reveal what people need. Search results can help you inspect current answer formats. When Search Console data is available, compare the actual queries associated with relevant pages.
Keep the evidence beside the question. An editor's proposed question is a hypothesis; a recorded customer question is audience evidence. Neither establishes search volume. Do not fill an empty evidence column with guessed demand.
4. Assign one primary page owner to each task
Compare the proposed question with the closest existing page. Ask what the reader would do differently after reading it.
- Update when the current page should already answer the question but needs improvement.
- Add a section when the question is a supporting detail of the same task.
- Create a page when it needs a distinct resource, procedure or decision framework and you have the evidence to produce it.
- Review a merge when two existing pages substantially repeat the same job.
- Hold when the distinction or supporting evidence is missing.
Different keywords can belong on the same page. One broad page can answer several connected questions. “One primary owner” is an editorial responsibility, not a claim that a URL may rank for only one query.
5. Brief the pages that deserve work
For each approved update or new page, record its reader, main task, scope, required evidence and closest overlap. Use the SEO content brief to turn that decision into a writing handoff.
Keep a proposed page on hold if it needs a real demonstration, expert input or current product fact that you do not yet have. A calendar slot does not supply evidence.
6. Publish useful answers, then complete their links
An overview can be useful before every supporting page exists if it answers the broad question on its own. Link only to published resources. Add a planned connection when its destination is ready, and record the task so it is not forgotten.
Sequence work around reader need and dependencies. Updating a useful existing procedure may matter more than adding another introductory article. For recurring production and approval decisions, see the reviewed content workflow.
Worked example: product team rituals
The following is an illustrative editorial plan, not a customer case study, tested search dataset or list of Blogoose URLs.
The pillar teaches how a small product team can choose a practical routine. Its scope includes the purpose of standups, retrospectives and other coordination activities, with enough explanation to help a reader choose what to explore next.
| Reader task | Proposed resource | Ownership decision | Evidence needed |
|---|---|---|---|
| Understand which rituals to use | Product team rituals overview | Pillar; preserve an existing overview if it serves this role | Accountable practitioner review and clear selection criteria |
| Run an asynchronous standup | Procedure with an example update | Supporting guide, if no current procedure owns the task | Reviewed procedure, tooling constraints and example |
| Choose questions for a retrospective | Editable agenda with usage notes | Supporting template, if materially useful beyond the overview | Original template and facilitation review |
| Choose between Scrum and Kanban for a small team | Comparison based on actual constraints | Hold until accurate comparison evidence is available | Primary references and relevant practitioner input |
| Improve an existing standup procedure | Additional best-practice section | Update the procedure; do not create a synonym page | Specific failure modes and corrective guidance |
“Async standup guide” and “asynchronous standup best practices” may describe the same job. That is a reason to inspect the existing answer, not an automatic reason to create two URLs. A retrospective template may deserve its own page because the reader needs a reusable resource, but a short checklist might fit inside an existing retrospective guide.
Do not treat every row as a publishing commitment. The comparison remains on hold until it has enough evidence to help someone decide.
Copyable page ownership worksheet
Use one row per proposed reader task. This is an editorial planning template, not a verified Blogoose screen or automated export.
| Field | What to record |
|---|---|
| Subject and audience | The cluster's scope and whom it serves |
| Reader task | What someone needs to understand, do or choose |
| Evidence for the question | Recorded question, observed query or explicitly labeled hypothesis |
| Existing URL | Actual current owner, or “none found after review” |
| Closest overlap | Which page could already satisfy the job |
| Decision | Keep, update, add section, new page, merge review or hold |
| Unique contribution | Example, procedure, template or evidence the page adds |
| Required proof | Sources, expert review, product test or other missing input |
| Pillar connection | Where the overview should explain and link to this resource |
| Related connection | A sibling page that answers a real next question |
| Owner and release gate | Responsible person and remaining checks |
| Review record | Actual completed work and pending link tasks |
If an old URL owns the task, use a content refresh to improve it. A planned merge requires separate content and technical review; this worksheet is not permission to delete or redirect pages.
Add internal links that explain the next step
From the pillar, link to a supporting page when you introduce the subject it explains. From the supporting page, offer the overview when broader context would help. Link between supporting pages when one leads naturally to the next task.
Google's link guidance explains that links help discovery and understanding. Use HTML anchors with usable href values, descriptive text and surrounding context. There is no ideal link count to apply mechanically.
For the example cluster, a sentence about preparing for asynchronous updates can link to the standup procedure. A passage about reviewing the routine can point to the retrospective template. Those links explain a reading path without linking every article to every other article.
Check that destinations resolve, anchors describe them and important pages have discoverable inbound links. Navigation and breadcrumbs can provide orientation alongside contextual links.
What clusters do and do not establish
A cluster gives you a way to organize useful coverage. It does not certify expertise, supply missing evidence or guarantee rankings. Treat “topical authority” as a description to examine through actual coverage and credibility, rather than an invented score or page quota.
The same limit applies to AI visibility. Google says foundational SEO remains relevant to AI Overviews and AI Mode, without special additional optimization requirements. A page must meet the documented eligibility conditions, and appearance is not guaranteed. See Google's AI features guidance.
Write clear explanations, name the relevant entities and cite claims that need evidence because those choices help readers assess the answer. Do not claim a cluster layout, fixed passage length or number of supporting pages will cause an AI system to cite you. The AEO guide covers the broader evidence and eligibility questions.
Review the cluster after release
Keep a page-level record of what changed and what you can observe:
| Question | Check | Interpret carefully |
|---|---|---|
| Can readers and crawlers reach the answer? | Resolve the URL and inspect navigation/contextual links | A link does not guarantee indexing |
| Is the page eligible and indexed? | Use technical checks and Search Console URL Inspection where available | Investigate the reported reason before rewriting content |
| Are pages serving their intended tasks? | Read query/page data alongside actual content | A shared query alone does not prove harmful overlap |
| Do readers use the next-step links? | Review properly configured analytics and, where useful, usability feedback | Low clicks can have several causes; do not assign one automatically |
| Does coverage still help? | Review accuracy, unanswered questions and contradictory advice | Add or update only when the work improves the reader's answer |
Compare observations over a suitable period and note other site changes. Do not promise a ranking timeline or attribute every traffic movement to the cluster. When data is unavailable, record that limitation and continue checking content quality and navigation.
Put the review into your production process
Keep the worksheet and supporting evidence beside your draft. Verify the claims and intended destination before release. For the wider process, see the content workflow guide. If you are evaluating Blogoose, review current plans and publishing access.
Questions that affect the plan
Do I need to move existing pages into one folder?
A cluster plan does not require that change. First decide whether the current pages and their links serve the intended tasks. URL migrations add technical work and should have a clear reason beyond making the diagram look tidy.
Should I merge two pages when Search Console shows the same query?
Not automatically. Inspect the pages, their formats and the reader tasks first. Shared queries can be consistent with distinct useful pages. Review consolidation when their substantive answers repeat and one stronger owner would better serve the reader.
Can I publish the overview before the supporting pages?
Yes, if it is a complete useful overview. Leave out links to unfinished pages and add them when the destinations are published. Do not publish a thin placeholder that sends readers to resources you have not created.