Chapter 8: GSO Content Architecture
Chapter 7 built the research layer: prompts mapped into categories, grouped into intent clusters, assessed for coverage, and matched against existing content. That research has to land somewhere, and where it lands matters as much as the research itself. GSO content cannot be a pile of undifferentiated posts, however individually well-written each one is. It has to be a semantic system: silos that group genuine topical relationships, pillars that frame those relationships, spokes that resolve them, functional page types matched to what each prompt category actually needs, templates that make the whole thing repeatable, and internal links that make the relationships explicit. This chapter is that system.
- GSO content architecture is a semantic system made of silos, pillars, spokes, functional page types, templates, and internal links, not a pile of blog posts
- Silo boundaries come from intent clusters built in Chapter 7, not from an invented category taxonomy
- Pillars explain the system; spokes answer the questions; conflating the two roles is the most common architectural failure
- Definitional, comparative, and evidentiary needs often warrant dedicated functional page types rather than a generic spoke template
- Modular templates make architecture repeatable without forcing content into a mechanical, detectable sameness
- Internal linking is a structural signal, not decoration, communicating genuine relationships to both readers and retrieval systems
Why Content Needs Architecture, Not Just Volume
A large body of individually excellent pages is not the same thing as a well-architected silo. Generative systems reading source evaluation, covered in Chapter 3.3, look for topical coherence: sustained, structured coverage of a subject, not a scattering of unrelated high points.
Architecture is what turns volume into coherence. It determines whether a domain’s content demonstrates depth a system can recognize, or whether it reads as a collection of disconnected efforts that happen to share a domain name. Every element in this chapter, from silo boundaries down to individual internal links, exists to make that coherence explicit rather than something a reader or a system has to infer from scattered evidence.
Semantic Silos
A semantic silo groups content by genuine topical relationship, determined by real intent clusters rather than by an invented category taxonomy or a navigational convenience. This boundary decision comes first, because every pillar, spoke, and link built afterward inherits whatever silo structure gets drawn here.
A silo that is too broad dilutes topical authority across subjects an expert wouldn’t group together. A silo that is too narrow fragments one coherent need across artificial divisions. Chapter 8.1 covers how to draw this boundary correctly and how to audit existing content against it.
Pillar Pages
Pillars explain the system. A pillar page’s job is framing a topic’s full scope and connecting to every spoke that resolves a piece of it, not delivering granular answers itself. The most common pillar failure is scope creep: a preview section gradually absorbing enough detail that it functions as a shallow embedded spoke, serving neither the framing role nor the depth role well.
This framework’s own chapter pages, including the one you are reading now, are a working demonstration of the pattern. Chapter 8.2 covers correct pillar sizing and the pillar-to-spoke link structure that makes a silo legible.
Spoke Pages
Spokes answer the questions. A spoke resolves one specific intent cluster completely, built from the extractable blocks established in Chapter 4.5, and should never require reading its pillar first to make sense. The target relationship between spokes and intent clusters is close to one-to-one; a spoke serving two unrelated clusters at once tends to underserve both.
A spoke covering two genuinely distinct needs is usually two spokes that got merged prematurely and should be split. Chapter 8.3 covers spoke scoping discipline and the diagnostic test for catching premature merges.
Functional Page Types
Not every information need fits the pillar-spoke shape well. Definitional prompts call for glossary structure. Comparative and evaluative prompts call for genuine parallel structure, not sequential narrative. FAQ pages serve as their own dedicated architectural asset beyond the FAQ section every spoke already carries. Evidence pages hold data and citations that support claims reused across multiple spokes.
Each of these functional types mirrors a prompt category from Chapter 7.2, and matching type to category systematically prevents the common mistake of forcing every content need into the same generic template. Chapter 8.4 covers all five types and their structural requirements.
Modular Templates
Templates make architecture repeatable without becoming rigid. A good template encodes structural requirements, which sections a page type needs and what job each one accomplishes, without dictating exact wording. Over-specified templates produce the exact mechanical sameness this framework’s writing standards exist to prevent.
Each functional page type warrants its own template, built inductively from pages that have already worked well rather than invented in the abstract. Chapter 8.5 covers what to encode, what to leave flexible, and how templates should evolve as platforms change.
Internal Linking
Internal links make structural claims, not just navigational suggestions. Pillar-to-spoke links claim silo membership. Spoke-to-spoke links claim a relationship between two resolved needs. This is a direct extension of the entity relationship work in Chapter 6.2: an unstated relationship between related pages reads as ambiguity to a generative system, the same way an unstated author-organization relationship does.
Link structure requires ongoing maintenance as content grows, not a one-time setup pass. Chapter 8.6 covers linking patterns, cross-silo linking without diluting boundaries, and how to audit for architectural gaps.
From Architecture to Infrastructure
Everything in this chapter assumes the architecture actually reaches the systems meant to read it. A perfectly bounded silo, a well-framed pillar, spokes built from clean extractable blocks, and a deliberate internal link structure all depend on one more condition: that generative systems can technically access, render, and parse the pages this chapter has just described how to build.
That access layer is not a given, and it fails in specific, diagnosable ways. Chapter 9 picks up directly from here, covering the infrastructure and technical readiness conditions that determine whether the architecture built in this chapter is actually reachable.
Building the System, Not Just the Pages
Michael Rubinstein treats content architecture as the difference between a domain that generative systems can read as a coherent body of expertise and a domain that reads as a pile of individually decent pages with no legible relationship between them. Most sites with years of content history have far more of the second than the first, not because the individual content is weak, but because nobody deliberately built the system connecting it.
ScribePress is built around this chapter’s full structure by default: silo boundaries drawn from real intent clusters, pillars and spokes scoped to their correct roles, functional page types matched to prompt category, and internal linking generated as part of publication rather than as an afterthought pass.
Learn more about the work behind this framework at michael-rubinstein.com.
Frequently asked questions
GSO content architecture is the semantic system, silos, pillars, spokes, functional page types, templates, and internal links, that organizes content so generative systems can recognize sustained topical depth rather than a scattering of disconnected pages. Even excellent individual content underperforms without this structure, since source evaluation reads topical coherence as a signal, and coherence has to be built deliberately rather than assumed from content volume alone.
Silo boundaries come from the intent clusters built in Chapter 7, grouped by genuine topical relationship, rather than from an invented category taxonomy or navigational convenience. This ensures the architectural boundary reflects how a subject actually breaks down rather than how an organization chart or planning meeting happened to categorize it.
A pillar page frames a topic's full scope and links to every spoke that resolves a piece of it, without itself delivering granular answers. A spoke page resolves one specific intent cluster completely and should never require reading its pillar first to make sense. Conflating the two roles, most often a pillar absorbing spoke-level detail through scope creep, is the most common architectural failure this chapter addresses.
Different prompt categories imply different structural shapes: definitional prompts need immediate, scannable definitions rather than narrative buildup, and comparative prompts need genuine parallel structure across options rather than sequential prose. Forcing every need into a generic spoke template serves neither well, which is why glossary, comparison, FAQ, and evidence pages exist as distinct functional types.
Templates avoid this by encoding structural requirements, which sections a page needs and what job each one accomplishes, rather than encoding exact wording or sentence structures. A template that dictates specific phrasing produces detectably uniform content across every page built from it; a template that only specifies structure leaves a writer's voice fully intact while still ensuring consistency.
Every internal link makes a structural claim about how two pages relate, functioning similarly to the entity relationship signals covered in Chapter 6.2. Generative systems read link structure as part of how they understand a domain's topical coherence, which means unlinked but genuinely related content represents a missing signal, not just a minor navigational inconvenience.
The principles scale down as well as up. A small site with only a handful of silos still benefits from drawing genuine boundaries around real intent clusters, scoping pillars and spokes to their correct roles, and linking related content deliberately. The main difference at smaller scale is that templates and audit processes can be lighter-weight, since the coordination challenge of a large, multi-writer operation is less pressing.
Correctly built architecture still depends on infrastructure: generative systems have to be able to access, render, and parse the pages this chapter describes how to structure. Chapter 9 covers that access layer in full, including the specific, diagnosable ways infrastructure failures can prevent well-architected content from ever reaching the systems it was built for.
Put the framework to work
ScribePress
Turn GSO strategy into publish-ready content, straight into WordPress.
Visit ScribePress →Howling Raccoon
The generative-search visibility crawler that audits how AI reads your site.
Visit Howling Raccoon →