Pillar Pages: Explaining the System

Pillars explain the system. Spokes answer the questions. That single sentence resolves more pillar-page confusion than any other principle in this chapter, because most failed pillar pages fail for exactly one reason: they try to do both jobs at once. A pillar that tries to also deliver granular answers becomes too long to frame anything clearly and too shallow to resolve anything completely. This page defines what a pillar's job actually is, narrowly and precisely, so the temptation to make it do more never gets a foothold.

What a Pillar Page’s Job Actually Is

A pillar page’s job is to frame a topic’s full scope: to state clearly what the subject covers, how its parts relate to each other, and where a reader should go for depth on any specific part. It is the map of the silo, not the destination for any single question inside it.

This framing function has a specific, testable shape. A reader landing on a well-built pillar should come away understanding the shape of the whole topic, what the major sub-questions are and how they connect, even if they have not yet read a single spoke. That is a different achievement than answering those sub-questions. A pillar succeeds by making the silo’s structure legible, not by resolving every question that structure contains. This is exactly the framing-versus-answering distinction that defines the pillar-spoke relationship throughout this chapter, and it is worth holding onto as the single test for every pillar page decision that follows.

Why Pillars Fail When They Try to Also Be Spokes

The most common pillar failure is scope creep: a section meant to preview a sub-topic gradually accumulates enough detail that it starts functioning as a spoke embedded inside the pillar, rather than a pointer to one.

This happens for a reasonable-sounding reason. A writer previewing a sub-topic wants the preview to feel substantive, so they add another paragraph of real detail, and then another, until the pillar section has quietly become a shallow version of the spoke it was supposed to link to. The result serves nobody well. The pillar is now too long to frame the topic efficiently, since a reader has to wade through partial answers to see the full shape of the subject. And the embedded mini-answer is too shallow to actually resolve the question, since real depth requires the dedicated space a spoke provides. A pillar section previewing a sub-topic should say enough to make the sub-topic’s importance and shape clear, then hand off. If a pillar section could stand alone as a satisfying answer to its own question, it has become a spoke and should probably be extracted into one.

The Pillar-to-Spoke Link Structure That Makes a Silo Legible

A pillar’s links to its spokes are not decoration. They are the structural mechanism that turns a collection of individually good pages into a legible silo, both for a human reader trying to navigate the topic and for a generative system trying to understand how the domain’s content relates.

Each spoke a pillar links to should be introduced with enough framing that the link’s purpose is unambiguous: not “learn more here” but a sentence that states what specific question that spoke resolves, so the link itself carries information rather than just pointing somewhere. This connects directly to the internal linking principles in Chapter 8.6 and to the entity relationship work in Chapter 6.2: a clear pillar-to-spoke link structure is one of the concrete ways a domain makes its own topical relationships explicit rather than assuming a reader, or a system, will infer them.

Sizing a Pillar Correctly: Comprehensive Framing, Not Exhaustive Detail

Pillar pages should be comprehensive in scope and restrained in depth. Comprehensive scope means the pillar touches every major sub-topic in its silo, so nothing important is missing from the map. Restrained depth means each of those touches is a clear framing, not an attempt to fully resolve the sub-topic on the spot.

This produces a specific, recognizable shape: a pillar reads as broad and clear rather than long and exhaustive. Word count is a symptom of this balance, not a target to hit directly. A pillar that tries to hit a word count by adding depth to individual sections has usually started absorbing spoke-level material, the scope-creep failure described above. A pillar that stays properly scoped tends to land at a length that reflects how many sub-topics the silo genuinely contains, not an externally imposed target.

This Framework’s Own Chapter Pages as a Working Example

This entire framework is built on the pattern this page describes, which makes it a live, checkable example rather than an abstract one. Every chapter page, including the page you would find at the top of this chapter, frames its silo’s full scope and links out to sub-chapters that resolve each piece in depth. Chapter 4’s pillar page, for instance, introduces all five GSO pillars and hands off to five dedicated sub-chapters rather than trying to explain infrastructure optimization or trust architecture in full inside the chapter overview itself.

This self-consistency is not incidental. A framework that argues for pillar-spoke architecture while failing to practice it in its own structure would undercut its own credibility in a way a reader would likely notice. Examining any chapter pillar page in this framework against the criteria on this page, does it frame rather than answer, does it link with clear purpose, is its scope comprehensive without being exhaustive, is a useful exercise for a practitioner building their own first pillar page.

Common Pillar Page Mistakes

Beyond scope creep, several other mistakes recur often enough to name directly. Vague, low-information links to spokes, phrases like “read more” or “learn more” that give a reader or a system no signal about what the destination actually resolves, waste the pillar’s most important structural asset. Pillars that omit a genuine sub-topic because it felt minor at planning time leave a silo with an invisible gap, since nothing on the page signals that anything is missing. Pillars written before their spokes exist tend to describe spokes in vague, aspirational terms rather than accurately, which creates a mismatch once the spokes are actually written. This is the specific reason this framework’s own production sequence writes spokes before their pillar, a workflow choice covered operationally in Chapter 13.4: a pillar can only accurately frame content that already exists.

Framing the System Before Answering the Questions

Michael Rubinstein has enforced spokes-before-pillar as a non-negotiable production sequence throughout this entire framework’s own construction, for the exact reason described above: a pillar written before its spokes exist is guessing at what it’s framing, and guesses read differently than accurate summaries to anyone paying attention.

ScribePress builds pillar pages as the final step in a silo’s production, after every spoke it will link to already exists, so the framing a pillar provides is drawn from real, finished content rather than a plan for content that hasn’t been written yet.

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

Put the framework to work