Spoke Pages: Answering the Questions

If a pillar's job is to frame the system, a spoke's job is to actually resolve one piece of it, completely, without requiring anything else to make sense first. That last condition is the one spokes most often fail. A spoke that assumes the reader has just come from its pillar, that opens mid-argument or references "the approach discussed above," is not doing spoke work correctly, no matter how good its content is. This page defines what a spoke page resolves, how narrowly it should be scoped, and how it connects to the extractable-block discipline this framework has built throughout.

What a Spoke Page Resolves, and How Narrowly It Should Be Scoped

A spoke page exists to resolve one specific question or need completely. Not to touch on it, not to gesture toward an answer while directing the reader elsewhere for the real substance, but to actually deliver the depth that question deserves within the page itself.

The scoping discipline this requires is narrower than most content plans naturally produce. A spoke titled around a broad theme, “email marketing best practices,” is usually not scoped to one need at all; it is a pillar wearing a spoke’s URL. A properly scoped spoke reads more like “how to structure a welcome email sequence for a B2B trial signup,” specific enough that a reader arriving with that exact need finds a complete answer, and specific enough that the page has no ambiguity about what it is for. This precision is not a limitation. It is what makes the page genuinely useful to both a human reader and a retrieval system trying to match it against a real prompt.

The Relationship Between One Spoke and One Intent Cluster

The intent clusters built in Chapter 7.3 are the direct source of spoke scope. One intent cluster, one spoke, is the target relationship, not a rule without exceptions but the default assumption a practitioner should start from.

This relationship matters because an intent cluster already represents a coherent underlying need, distinct wording collapsed into one real question. A spoke built to resolve that cluster inherits its coherence: the page has one clear job, matching one clear need, which is exactly the condition that makes a page’s fragments cleanly retrievable for the range of prompt phrasings that cluster contains. A spoke that tries to serve two clusters at once loses this coherence, and a reader or a retrieval system encountering it has to do extra work to figure out which parts of the page apply to their actual need.

Spokes as Collections of Extractable Blocks

A well-built spoke is not a single continuous argument. It is a collection of extractable blocks, in the sense established in Chapter 4.5, each one independently interpretable, all serving the single intent cluster the spoke exists to resolve.

This means a spoke’s internal structure should be legible at the paragraph level even while the whole page stays tightly scoped to one need. A definition block stating the core concept clearly. A claim block backed by its own evidence. An explainer block breaking a process into self-sufficient steps. These blocks work together to resolve the spoke’s one job thoroughly, but each one also survives extraction on its own, which is what lets a spoke serve both the reader who reads start to finish and the generative system that lifts one paragraph out of context. Scope discipline and block-level modularity are not separate concerns; a spoke that is properly scoped to one intent cluster makes it much easier to keep every block inside it genuinely relevant, rather than padding the page with tangential material that dilutes both the scope and the extractability.

Why a Spoke Should Never Require Reading the Pillar First

A spoke that only makes sense to a reader who has just come from its pillar has failed one of the basic requirements of spoke architecture, regardless of how good its content otherwise is. Most readers, and every retrieval system extracting a fragment, will encounter a spoke without that context.

This means a spoke needs to state its own subject clearly, the same self-containment discipline that applies at the paragraph level in Chapter 4.5, applied now at the page level. A spoke can and should link back to its pillar, since that link provides valuable orientation for a reader who wants the broader context the spoke doesn’t attempt to provide. But that link is for orientation, not comprehension. If removing the link back to the pillar would make the spoke confusing or incomplete, the spoke has not been written as a properly self-contained resolution of its own intent cluster.

Spoke-to-Spoke Relationships Within a Silo

Spokes within the same silo often have real relationships to each other beyond their shared pillar: one spoke might be a natural next step after another, or two spokes might address closely related decisions a reader is likely to be weighing together.

These relationships are worth making explicit through internal linking, covered fully in Chapter 8.6, rather than left for a reader to discover by returning to the pillar and choosing again. A spoke about choosing a running shoe for wide feet and a spoke about breaking in new running shoes without blisters are both independently complete, but a reader of the first is plausibly interested in the second, and linking between them directly serves that reader better than routing them back through the pillar every time. This kind of linking also reinforces the silo’s topical coherence for the reasons covered in Chapter 8.1: it demonstrates that the domain’s content genuinely relates, not just that it shares a pillar page.

When a Spoke Is Actually Two Spokes That Got Merged Prematurely

A spoke that covers two genuinely distinct needs under one URL is a common and specific failure, usually arising because the two needs seemed related enough during planning to combine, even though they serve different intent clusters with different resolutions.

The diagnostic test mirrors the one used for silo boundaries in Chapter 8.1: would a reader arriving for one of the two needs find the other half of the page irrelevant to them. If yes, the page is trying to serve two audiences with one asset, and both are likely underserved as a result, since the page cannot lead cleanly with either need’s specific answer. The fix is usually straightforward once diagnosed: split the page into two properly scoped spokes, each resolving its own intent cluster, and link them to each other if the relationship from the previous section genuinely exists. This is a more common failure than under-scoping, since the instinct to combine related-seeming content into one page is a natural one that runs directly against the one-cluster, one-spoke discipline this chapter establishes.

Building Spokes That Actually Resolve, Not Just Touch On

Michael Rubinstein treats spoke scoping discipline as the place where most content teams’ good intentions quietly erode, because combining two related needs into one page always feels efficient in the planning meeting and only reveals its cost later, in a spoke that never quite satisfies either reader who arrives at it.

ScribePress scopes every spoke to a single intent cluster by default, generating one properly bounded page per resolved need rather than combining related needs for the sake of a shorter content calendar, because the coherence that produces is what makes a spoke reliably retrievable for the range of prompts its cluster actually contains.

Learn more about the work behind this framework at michael-rubinstein.com.

Put the framework to work