Sign in Start free

Decide One Page or a Cluster

This is expensive to get wrong in both directions. Split a topic Google treats as one and the pages compete for the same result; merge a topic Google treats as several and you rank properly for none of them. Teams normally settle it by how much there is to say, which is a fact about your material rather than about the SERP. The evidence is in the results pages for the sub-queries and takes about an hour to read.

CATEGORY
Content strategy
FORMAT
page-or-cluster-shape-decision.md
STEPS
7
PRICE
Free - no account
WHEN TO REACH FOR THIS

Use when a topic could plausibly be one long page or a hub with several supporting pages, and the team is deciding by word count or by copying a competitor.

The skill file

page-or-cluster-shape-decision.md 
---
name: page-or-cluster-shape-decision
description: Use when a topic could plausibly be one long page or a hub with several supporting pages, and the team is deciding by word count or by copying a competitor.
---

# Decide One Page or a Cluster

This is expensive to get wrong in both directions. Split a topic Google treats as one and the pages compete for the same result; merge a topic Google treats as several and you rank properly for none of them. Teams normally settle it by how much there is to say, which is a fact about your material rather than about the SERP. The evidence is in the results pages for the sub-queries and takes about an hour to read.

## What you need first

- the full query list for the topic including question phrasings, with volumes
- the live top 10 for the head query and for at least 4 sub-queries, checked manually
- your realistic capacity for this topic over the next two months

## Method

1. Pull the top 10 for the head term and for each sub-query. Where the same URLs rank across all of them, Google is treating this as one page and one page is what you should build.
2. Where sub-queries return different URLs from the same domains, that is a cluster: those sites hold the head term with a hub and the sub-queries with dedicated pages, which is the structure being rewarded.
3. Open the ranking pages and check whether any single one covers several sub-queries in its own headings. A page holding three sub-queries under H2s is telling you those sub-queries are sections, not pages.
4. Test each sub-query for independent format need. If answering it properly requires a different page type such as a calculator, a comparison table or a downloadable template, it needs its own URL whatever the SERP overlap suggests.
5. Size the cluster against capacity before committing. A hub with two of five spokes live usually performs worse than the single page it replaced, so if the whole set cannot ship inside two months, build one page now and split it later.
6. For a cluster, write the URL structure and the internal links in both directions before drafting: the hub links down to every spoke using the spoke target phrasing, each spoke links up using the hub phrasing. Retrofitting these after publication is how spokes end up orphaned.
7. For a single page, record which sub-queries were folded in and the impressions threshold at which you would split one back out, so the decision gets revisited on evidence rather than reopened as an opinion.

## What this produces

A per topic shape decision naming single page or hub plus spokes, with URLs, internal link directions, and the condition that would reverse it.

## Where this goes wrong

- splitting a topic into a cluster because it yields more pages to report against, then watching the spokes cannibalise the hub on the head term
- shipping the hub first and leaving spokes unfinished, so the hub is a thin index page linking to almost nothing
- copying a competitor structure when their hub ranks on domain strength rather than on the structure itself

---

From the QuQi skill library - https://www.quqi.io/skills/page-or-cluster-shape-decision
Free to download · no account, no email

What you need first

  • the full query list for the topic including question phrasings, with volumes
  • the live top 10 for the head query and for at least 4 sub-queries, checked manually
  • your realistic capacity for this topic over the next two months

Method

  1. 01 Pull the top 10 for the head term and for each sub-query. Where the same URLs rank across all of them, Google is treating this as one page and one page is what you should build.
  2. 02 Where sub-queries return different URLs from the same domains, that is a cluster: those sites hold the head term with a hub and the sub-queries with dedicated pages, which is the structure being rewarded.
  3. 03 Open the ranking pages and check whether any single one covers several sub-queries in its own headings. A page holding three sub-queries under H2s is telling you those sub-queries are sections, not pages.
  4. 04 Test each sub-query for independent format need. If answering it properly requires a different page type such as a calculator, a comparison table or a downloadable template, it needs its own URL whatever the SERP overlap suggests.
  5. 05 Size the cluster against capacity before committing. A hub with two of five spokes live usually performs worse than the single page it replaced, so if the whole set cannot ship inside two months, build one page now and split it later.
  6. 06 For a cluster, write the URL structure and the internal links in both directions before drafting: the hub links down to every spoke using the spoke target phrasing, each spoke links up using the hub phrasing. Retrofitting these after publication is how spokes end up orphaned.
  7. 07 For a single page, record which sub-queries were folded in and the impressions threshold at which you would split one back out, so the decision gets revisited on evidence rather than reopened as an opinion.

What this produces

A per topic shape decision naming single page or hub plus spokes, with URLs, internal link directions, and the condition that would reverse it.

Where this goes wrong

  • splitting a topic into a cluster because it yields more pages to report against, then watching the spokes cannibalise the hub on the head term
  • shipping the hub first and leaving spokes unfinished, so the hub is a thin index page linking to almost nothing
  • copying a competitor structure when their hub ranks on domain strength rather than on the structure itself

Use this skill in your own AI

The download is a plain markdown file with the name and trigger in its frontmatter. Where an assistant supports skills it can load itself, that frontmatter is what it reads to decide this one applies.

Claude Code Save it as ~/.claude/skills/page-or-cluster-shape-decision/SKILL.md and Claude loads it on its own when what you are doing matches the trigger line. Put it in .claude/skills inside a project instead if the whole team should have it.
Claude Upload the file in the skills section of your settings. Once it is there it applies itself in any conversation where the trigger fits, so you do not have to remember it exists.
ChatGPT There is no skills format to install into, so paste the file contents into a Project instruction or a Custom GPT instead. It then applies to every chat in that project rather than only the one you paste it into.
Anything else Paste the markdown into the chat before your question. It works in any assistant, it just has to be pasted again each time.

Questions about this skill

When do I settle this on the SERP rather than on how much there is to say?

Always, because how much there is to say is a fact about your material rather than about the results page. Reading the top ten for the head term and four sub-queries takes about an hour. It is worth that hour because the error is expensive both ways: split what Google treats as one page and your pages compete for the same result.

What do I need in hand before starting?

The full query list including question phrasings with volumes, the live top ten for the head query and at least four sub-queries checked by hand, and your realistic capacity for this topic over two months. Without the capacity figure you commit to a hub with five spokes, ship two, and end up with a thin index page linking to almost nothing.

What do I end up with, and which part of it gets used?

A written shape decision naming single page or hub plus named spokes, with URLs and the internal links in both directions set before drafting. Those link directions are the part that gets used, because retrofitting them after publication is how spokes end up orphaned. For a single page, the recorded impressions threshold is what reopens the decision on evidence rather than opinion.

What ruins this most often?

Splitting a topic because a cluster yields more pages to report against. The spokes then cannibalise the hub on the head term and you rank properly for none of it, having spent several times the effort of one page. Copying a competitor structure is the sibling error: their hub may rank on domain strength rather than on its shape.

More in Content strategy

Build a Topical Map From Real Demand

Use when you have a subject area but no defensible list of what to publish, and keyword exports...

Prioritize by Effort Against Realistic Win

Use when your content backlog is longer than your capacity and you need to decide what gets buil...

Decide Build New or Refresh Existing

Use when a target query is one you already have a page for and you are unsure whether to rewrite...

Competitor Gap Analysis Without Fooling Yourself

Use when you want to learn from competitors' content but keep producing a list of topics you hav...