Modular Templates for Repeatable Architecture

A template is a genuine tension to manage, not a solved problem. Encode too little structure and every writer rebuilds the same decisions from scratch, producing inconsistent pages that undercut the coherence this entire chapter argues for. Encode too much and content starts reading as mechanically filled-in, losing the natural voice this framework has insisted on since Chapter 2. A good GSO template resolves this tension by encoding structural requirements, not wording, turning the extractable block types from Chapter 4.5 into reusable page-level scaffolding a writer works within rather than a script a writer fills out.

What a Template Should Encode vs. What It Should Leave Flexible

A template should encode structural requirements: which sections a page type needs, what order they belong in, what job each section has to accomplish, and what the extractable block discipline requires of each one. It should not encode exact wording, specific phrasing, or a fill-in-the-blank sentence structure that every page ends up sharing verbatim.

This distinction is the entire difference between a template that helps and a template that harms. “This section states the definition in its first sentence” is a structural requirement, genuinely useful, transferable across any topic the template gets applied to. “This section begins with the phrase ‘When it comes to…’” is wording, and wording templates are exactly what produces the uniform, detectable sameness this framework’s writing standards were built to eliminate. A well-built template tells a writer what a section must do. It should never tell them what sentence to write to do it.

Templates as Scaffolding for Extractable Blocks, Not Scripts

The extractable block types established in Chapter 4.5, definition blocks, comparison blocks, explainer blocks, claim blocks, FAQ blocks, are the actual material templates are built from. A template at the page level is essentially a specified sequence and combination of these block types, matched to what a given functional page type needs.

A glossary template, for instance, specifies a sequence of definition blocks, each following the same self-containment discipline, with no requirement that any two entries share similar phrasing. A comparison template specifies a parallel structure of comparison blocks, one dimension assessed consistently across every option, again with no constraint on the specific language used to describe any given option. This framing, template as block scaffolding rather than script, is what allows a template to genuinely make production more consistent and more efficient without producing the flattened, homogeneous voice that a wording-level template inevitably creates across a body of content written by different people over time.

One Template Per Functional Page Type

Each of the functional page types established in Chapter 8.4, pillar, spoke, glossary, comparison, FAQ, and evidence page, warrants its own dedicated template, because each type has genuinely different structural requirements that a single generic template cannot serve well.

A pillar template needs to encode the framing discipline from Chapter 8.2: comprehensive scope, restrained depth, clear links to every spoke. A spoke template needs to encode the self-containment and one-cluster scoping discipline from Chapter 8.3. A comparison template needs the parallel-structure requirement from Chapter 8.4 that a spoke template has no reason to include. Trying to serve all of these needs from one universal template produces a compromise that fits none of them well, which is why this framework treats template-building as a per-type exercise rather than a single document meant to cover every kind of page a silo might need.

Why Over-Rigid Templates Produce Mechanical Content

A template that over-specifies, dictating exact sentence structures, mandating specific transitional phrases, requiring a fixed word count per section regardless of what the actual content needs, produces content that reads as though it was generated by filling in a form, because in a meaningful sense it was.

This is a genuine risk in template design, not a hypothetical one. The uniform sentence rhythm and detectable AI-cliché patterns this framework’s writing standards work hard to avoid are exactly what an over-rigid template tends to produce at scale, since a fill-in-the-blank structure naturally generates uniformity across everything built from it. The test for over-rigidity is straightforward: read several pages built from the same template back to back. If they feel interchangeable in wording, not just structure, the template has crossed from encoding requirements into encoding scripts, and it needs to be loosened. A template’s job is to make pages structurally consistent, not to make them sound identical.

Evolving Templates as Models and Platforms Change

Templates are not fixed artifacts, finished once and reused indefinitely. As generative platforms evolve, as new functional page type needs emerge, as this framework’s own understanding of what makes content retrievable deepens, templates need periodic reassessment against current reality rather than being treated as a settled decision from years earlier.

This does not mean templates should change constantly or unpredictably, which would undercut the consistency benefit they exist to provide. It means a periodic review, checking whether the structural requirements a template encodes still reflect current best understanding, catches drift before a template quietly becomes outdated while still being applied to every new page. A template that specified structure appropriate to platforms and retrieval mechanics from an earlier point in this field’s development may need updating even if nothing about the underlying writing quality standards has changed.

A Practical Template-Building Process

The most reliable way to build a template is inductive, not deductive: start from pages that have already been written well and performed well, rather than inventing an abstract structure in advance and hoping content fits it.

Identify two or three genuinely strong examples of a given functional page type, ideally ones that have already demonstrated retrieval success where that data exists. Extract the structural pattern they share: what sections appear, in what order, what job each section does, how blocks are sequenced within it. Generalize that pattern into requirements rather than specifics, removing anything that was particular to those examples’ specific topics rather than genuinely structural. Test the resulting template against a new page in the same functional type, and check the over-rigidity signal from the previous section before finalizing it. This process keeps templates grounded in what has actually worked, rather than in what seemed reasonable in the abstract before any content existed to test it against.

Building Consistency Without Building Sameness

Michael Rubinstein has treated the template tension described on this page as one of the more delicate balances in operationalizing GSO at scale, because the failure modes on either side are both real and both costly: no templates produces inconsistent architecture across a growing site, and bad templates produce content a reader can tell was assembled from a form.

ScribePress encodes templates as structural requirements per functional page type exactly as this page describes, generating pages that share consistent architecture and extractable block discipline while varying genuinely in voice and phrasing from one page to the next, which is the specific outcome a wording-level template could never produce.

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

Put the framework to work