The diagnostic combines three checks: whether pages in the intended cluster actually rank together for cluster-relevant queries (appearing in the same SERPs, which indicates Google is associating them topically), whether server log files show Googlebot actually traversing the intended hub-to-spoke crawl paths rather than discovering pages some other way, and whether the pillar page independently ranks for the broader head terms it was meant to own. Each check answers a different part of the question, and together they distinguish a cluster that’s functioning as designed from a set of pages that merely happen to be linked together without Google treating them as a cohesive topical unit.
Check one: SERP co-occurrence for cluster-relevant queries
If a hub-and-spoke cluster is working as intended, pages within it should show up together, or at least both appear somewhere in the results, for queries that span the cluster’s topic. Pull rankings for a representative set of cluster-adjacent queries, not just each spoke’s exact target keyword, and check whether multiple pages from the cluster appear in the results, or whether Google consistently treats them as entirely separate entities with no apparent topical relationship in how it ranks them. Genuine cohesion tends to show up as: the pillar ranking for broad queries, individual spokes ranking for their specific long-tail variants, and minimal unexpected competition between spokes for queries that should be clearly differentiated. If spokes are cannibalizing each other for the same queries, or if the pillar never appears for the broad terms it was built to target, that’s evidence Google isn’t reading the cluster as a coherent structure, whatever the internal linking looks like on paper.
Check two: log file analysis of actual crawl paths
Internal linking only concentrates signal if Googlebot is actually following those links. Server log analysis (isolating verified Googlebot requests by user agent and reverse DNS/IP verification) shows the real crawl paths being used to discover and re-crawl cluster pages. Compare this against the intended architecture: are spoke pages being crawled via the pillar’s internal links at meaningful frequency, or is Googlebot reaching them through some other path (an XML sitemap listing, an unrelated navigation element, external links) with the intended hub-spoke links rarely or never actually followed? If log data shows Googlebot largely ignoring the hub-to-spoke link paths in favor of other discovery routes, the architecture isn’t functioning as the mechanism it was designed to be, even if it exists in the HTML. This can happen for mundane reasons: links buried below the fold, links rendered only via JavaScript that isn’t executing reliably within Googlebot’s rendering pass, or a sitemap that’s making the internal links redundant as a discovery path.
Log analysis at this level of granularity requires isolating requests by verified Googlebot user agent strings and cross-checking the requesting IP against Google’s published IP ranges or reverse-DNS verification, since a raw user-agent string alone is trivially spoofable by other crawlers and scrapers. Once the verified Googlebot requests are isolated, the practical check is a referrer-adjacent analysis: look at request timing and sequence to see whether spoke URLs tend to get fetched in temporal clusters following a pillar-page fetch, which is consistent with Googlebot discovering and following the pillar’s outbound links in that crawl session, versus spoke URLs being fetched on their own schedule with no apparent relationship to pillar fetch timing, which is more consistent with discovery through the sitemap or some other independent path. A few weeks of log data is usually necessary to see a reliable pattern, since a single day’s crawl activity can look coincidental in either direction.
A specific edge case worth checking directly: sites that submit a comprehensive XML sitemap listing every page, including all spokes and the pillar, can inadvertently make their internal hub-spoke links crawl-redundant, since Googlebot can discover and revisit every URL directly from the sitemap regardless of whether the internal links are ever followed. In this situation, the internal links might still be doing real work in terms of passing anchor text and topical association signals when Google does process them, but the log data may show most actual crawl requests coming in patterns disconnected from the internal link structure, simply because the sitemap makes following those specific links unnecessary for discovery purposes. This doesn’t mean the internal linking is worthless, discovery and signal-passing are different functions, but it does mean log-based crawl-path evidence alone can understate the architecture’s real contribution if a sitemap is doing most of the discovery work. Where this comes up, it’s worth weighting check one and check three more heavily relative to check two, since the crawl-path evidence is structurally less informative on a site with comprehensive sitemap coverage.
Check three: does the pillar independently rank for broad head terms
The clearest single signal of successful concentration is whether the pillar page itself ranks for the broad, category-level query it was built to own. If the pillar never appears for that query, or ranks far weaker than the spokes’ aggregate topical relevance would suggest it should, that’s a sign the internal linking isn’t successfully concentrating topical signal onto the pillar the way the architecture intends. Conversely, if the pillar ranks well for the broad term while spokes independently rank for their narrower variants with minimal overlap between them, that’s strong evidence the cluster is functioning cohesively: Google is treating the pillar as the representative page for the topic while recognizing the spokes as legitimate, distinct sub-answers.
Putting the three checks together
A cluster failing check one but passing checks two and three might indicate the internal architecture and crawl mechanics are sound, but the content itself hasn’t yet accumulated enough independent signal to show up together in SERPs, often a matter of time or content quality rather than architecture. A cluster passing check one but failing check two suggests Google may be inferring topical relationship from something other than the intended internal links (shared external backlink patterns, similar content, or sitemap-driven discovery), meaning the architecture might be somewhat incidental to whatever cohesion exists rather than the actual cause. A cluster failing check three specifically, spokes doing fine individually but the pillar not gaining broad-term traction, often points to a pillar page that’s under-built relative to its spokes, more of a link directory than genuine subject-matter content in its own right.
A worked example of combining the three checks
Suppose a cluster was built around a broad topic with one pillar and fifteen spokes, restructured six months ago. Pulling rankings for a representative set of cluster queries shows the pillar ranking respectably for the broad head term, and most spokes ranking for their specific long-tail variants with little overlap between them, a clean pass on check one. Log analysis, however, shows that Googlebot’s crawl requests to spoke URLs correlate weakly with pillar-fetch timing; most spokes are being crawled on what looks like an independent schedule, and further investigation reveals the site’s XML sitemap lists every spoke directly. This is a pass on check three (pillar ranks well for the broad term) and an ambiguous result on check two, not a clean fail, but evidence that the sitemap is likely doing most of the discovery work rather than the internal links.
The correct read here isn’t “the architecture is broken because check two didn’t confirm it.” It’s that the cluster is functioning cohesively by the outcome-based checks (one and three), but the causal story of why is more likely to include comprehensive sitemap coverage as a major contributor alongside whatever the internal links are independently contributing in terms of topical signal and anchor text association. This is a case where over-indexing on a single check would produce the wrong conclusion; the three checks are diagnostic tools that need to be read together, with an eye toward which specific mechanism each one is actually testing, rather than treated as three independent pass/fail gates that need to unanimously agree before drawing any conclusion.
Edge case: clusters that pass all three checks but still underperform expectations
A cluster can pass all three structural checks, ranking together, real crawl-path traversal, pillar independently ranking for broad terms, and still not be driving as much traffic or ranking as strongly in absolute terms as the site owner expected going in. This is a distinct diagnosis from the architecture “not functioning cohesively,” and conflating the two leads to the wrong fix. If the structural checks all pass, the architecture is doing what it was designed to do; the remaining gap is more likely explained by competitive factors outside the architecture’s control (stronger competing domains in that space), insufficient content depth or quality within the cluster relative to what’s ranking above it, or the topic simply being one where the site hasn’t yet built enough independent authority signal regardless of internal structure. Rebuilding or further restructuring the architecture in this situation is unlikely to help, since the diagnostic already confirmed the architecture is functioning; the more productive next step is a content-quality and competitive-gap analysis of the cluster’s actual pages against what’s currently outranking them.
Practical implication
Run all three checks before concluding a cluster architecture “isn’t working” or “is working.” Ranking data alone can be misleading without crawl-path confirmation (a cluster might be ranking despite the architecture, not because of it), and crawl-path data alone doesn’t confirm topical cohesion in Google’s actual ranking treatment. When a cluster fails one or more checks, the fix follows from which check failed: strengthen the pillar’s own content depth if check three fails, fix link placement or rendering if check two fails, and reconsider whether the spokes are genuinely differentiated enough to avoid mutual cannibalization if check one shows unwanted overlap. And when a cluster passes all three checks but still underperforms on raw traffic or ranking strength, resist the urge to keep re-engineering an architecture that’s already confirmed to be working; look instead at content depth and competitive positioning, since that’s where the actual gap is more likely to live.
