- Hypothesis
- A set of articles published as a complete, interlinked cluster around one topic will earn more impressions, more ranking queries and better average positions per article than the same number of articles on unrelated topics published in the same period on the same site.
- Method
- Two arms of [N] articles each, matched on length, quality process and estimated demand; one arm forms a cluster with a hub, the other is scattered across unrelated topics. Tracked per article via Search Console.
- Measure
- Impressions per article, number of distinct queries per article, share of articles with a top-10 position for their primary query, and growth in impressions for the hub.
- Duration
- 6 months post-publication.
Hypothesis
If topical authority is real, the cluster arm should outperform the scattered arm per article, even though both arms have the same number of pages, the same writing process and the same domain behind them. The mechanism I expect: the hub and its spokes reinforce each other through internal links and shared entities, so Google forms a clearer picture of what the site knows, and individual spokes rank for more queries than they would in isolation.
What would falsify it: if per-article impressions, query counts and positions are similar across arms, then on this site, over this window, completeness is not the lever and each page is being judged on its own. If the scattered arm wins, that would suggest demand matters far more than coverage, and I would have to revise my topical authority framework.
Why I tested it
I build content programmes around clusters because the logic is sound and because I have seen it work in practice. But "seen it work" is not the same as isolating it. Cluster builds usually arrive with better briefs, better internal links and more editorial attention than scattered posts, so the comparison is never fair. This test tries to make it fair.
It also answers a budget question I get from SaaS and D2C founders in India: is it better to publish ten articles on one subject or ten articles on ten subjects? The publishing more is not the answer note argues for depth. This is the test behind the opinion.
Method
Choose a topic the site has not covered
The cluster topic must be new to the site, so there is no prior authority to inherit, and must be mappable to a defined set of subtopics with the hub-and-spoke structure described in the topic clusters guide.
Build matched arms
Cluster arm: one hub plus [N] spoke articles covering the subtopic map. Scattered arm: [N] articles on unrelated topics, chosen so that estimated demand per primary query is comparable to the cluster spokes. Same brief template, same writer pool, same length band, same review.
Control internal linking
Cluster spokes link to the hub and to adjacent spokes. Scattered articles receive the same number of inbound internal links from the most relevant existing pages, so link count is equal and only link topology differs.
Publish on the same schedule
Articles from both arms are interleaved over the same weeks, so neither arm benefits from a freshness burst or suffers from a quiet period.
Track per article
Search Console API, per URL, weekly: impressions, clicks, distinct queries, average position, and position for the primary query. The hub is tracked separately.
Confounders: core updates during a multi-month window are likely rather than possible, so both arms are read against each other on every update date. Seasonality is handled by matching demand profiles at selection, and by comparing arms rather than comparing to baseline. The largest risk is unequal article quality, which is why the brief, writer and review steps are identical and why I do not know which arm an article belongs to when reviewing it.
Implementation
The cluster is designed before anything is written. I map the topic into subtopics, assign a primary query and intent to each, and define the hub as the page that answers the broad question and routes to each spoke. The scattered arm is simply a list of unrelated primary queries with matching intent and demand.
# per-article tracking record (pseudocode)
article.arm = "cluster" | "scattered"
article.primary_query = "..."
article.publish_week = W
article.inlinks_count = K # equal across arms
article.inlinks_topology = "hub+spokes" | "contextual-unrelated"Both arms live in the same content section and template, with the same schema and the same sitemap. Nothing identifies an article's arm to a reader or a crawler apart from its topic and the links between pages.
How to read the results
The primary view is per-article impressions over time, averaged within each arm, with the hub excluded so the cluster is not credited for an extra page. The second view is distinct queries per article, which gets at whether cluster spokes rank for a broader set of queries than isolated pieces. The third is the share of articles with a top-10 position for their primary query.
A cluster effect should grow over the window rather than appear at launch, because it depends on the hub and spokes being crawled and connected. If both arms track together for months, the effect is absent or too small to matter at this scale. A difference counts only if it exceeds the article-to-article spread within an arm.
Data
Weekly impression, query count, and position datasets are being collected across cluster and scattered arms.
Result
Tracking comparative growth curves between clustered and isolated articles. Full results will be published once the multi-month evaluation completes.
What I learned
Early trendlines suggest interlinked clusters achieve faster rank stability for supporting terms; full insights to follow.
Conclusion
Final conclusions on topic clustering dynamics will be published once the full test cycle concludes.
Whichever way it falls, the design decisions above are the ones that make a cluster test believable: a topic the site has not covered, matched demand, equal link counts and blind review. The topical authority guide explains the theory, and the SaaS organic growth case study shows a cluster programme inside a full content SEO engagement.