Structured Data: What Schema Actually Does and Doesn't Do

Schema markup does not make content AI-friendly by itself. That claim shows up constantly in GSO discussion, usually attached to the implication that adding enough JSON-LD is a shortcut around the harder work of building genuinely clear, well-structured content. It is not a shortcut, and treating it as one wastes engineering effort on markup that confirms very little. Chapter 6.6 already made this exact case for entity-specific schema, Organization and Person markup. This page extends that same "support, not magic" framing to the broader schema landscape, FAQPage, Article, HowTo, and the practical implementation discipline that makes any of it actually useful.

The “Support, Not Magic” Framing, Extended

Chapter 6.6 established the core principle for entity schema, Organization and Person markup: schema formalizes and confirms information a page’s content has already made clear. It does not generate clarity that isn’t otherwise there, and applying it to vague or inconsistent content confirms nothing meaningful.

That principle was scoped narrowly to entity identity in Chapter 6.6, deliberately, because the broader schema landscape deserved its own treatment. The principle itself does not change when applied more broadly. FAQPage schema formalizes a question-and-answer structure that already exists clearly in a page’s visible content. Article schema formalizes authorship and publication information already stated on the page. HowTo schema formalizes a step sequence that is already legible to a human reader. In every case, the markup’s job is confirmation, and a page with unclear or inconsistent visible content gains little to nothing from wrapping that same unclear content in structured data.

The Schema Types That Matter Beyond Entity Markup

Beyond Organization and Person, covered in Chapter 6.6, four schema types carry the most practical weight for GSO purposes. FAQPage schema formalizes question-and-answer content, directly supporting the FAQ section every spoke and pillar in this framework carries, and making that structure explicit and machine-readable rather than requiring a system to infer the Q&A pattern from unstructured prose.

Article schema formalizes authorship, publication date, and topical context for editorial content, connecting the visible byline and date information a page already displays to a structured format. HowTo schema structures instructional content for step-level extraction, formalizing a numbered or sequential process that a page’s visible content should already present clearly. Speakable schema marks specific content as appropriate for voice and audio responses, relevant specifically where those surfaces matter to a given domain’s audience. Each of these types exists to formalize a structure the visible content already has, which is the same relationship Chapter 6.6 established for entity markup, applied here to content-format rather than identity.

Correct JSON-LD Implementation Practices

Beyond the conceptual framing, correct implementation matters mechanically. JSON-LD should be valid, syntactically correct structured data that a parser can process without errors, since malformed markup is either ignored entirely or, worse, produces unpredictable interpretation.

Properties should be used as their schema type actually specifies rather than repurposed loosely for convenience; a property meant for one kind of data used to hold a different kind of data creates markup that is technically present but semantically incorrect, which defeats the purpose of using structured data in the first place. Placement matters as well: JSON-LD should be included in a location that is reliably present in the page’s initial response, connecting directly to the rendering discipline covered in Chapter 9.2, since schema that only loads after client-side script execution faces the exact same access problem as any other JavaScript-dependent content. Testing implementation against validation tools before publishing catches syntax errors, but validation tools check syntax, not whether the schema accurately reflects the page’s actual content, which is a separate and equally important check covered next.

Validating Schema Actually Matches Visible Content

Schema validation tools confirm that markup is syntactically correct. They do not confirm that the markup accurately describes what the page actually says, which is a distinct check a team has to perform deliberately.

This matters because mismatched schema, markup stating one version of a fact while the visible page content states something different, reintroduces exactly the conflict problem Chapter 6.6 identified for entity markup: a system encountering two different versions of the same fact on the same page has to resolve a contradiction rather than simply reading a clear signal. This can happen innocently, a page gets updated but its schema does not, or a template generates schema from a data source that has drifted out of sync with the visible content it’s meant to describe. A periodic check comparing schema output against the actual rendered page, not just running a syntax validator, catches this drift before it becomes the kind of contradiction that erodes confidence rather than building it.

Schema as Confirmation, Not a Substitute

The practical implication of everything above is a sequencing discipline: schema implementation should never be treated as a way to compensate for content that is itself unclear, inconsistent, or poorly structured. A page with a vague, buried answer gains nothing from FAQPage schema wrapped around that same vague answer, because the schema is only formalizing a structure that was never actually clear in the first place.

This is the same lesson Chapter 6.6 delivered for entity clarity, restated here for content structure broadly: schema is the machine-readable label on content that is already well-built. Teams that reverse this sequence, implementing comprehensive schema markup before addressing known content clarity issues, spend real engineering effort producing structured data that confirms very little, because there is no coherent underlying signal for the markup to make explicit.

A Practical Implementation Sequence

The correct sequence addresses content clarity first: ensure the visible page content already has the structure schema will formalize, a clear question-and-answer pattern for FAQPage, a clear step sequence for HowTo, clear authorship and date information for Article. Only after that clarity exists does schema implementation add real value.

From there, implementation should follow the mechanical discipline covered above: valid JSON-LD syntax, correct property usage, placement in the initial page response rather than dependent on script execution, and a validation pass that checks both syntax and accuracy against visible content. This sequence should be revisited periodically as content changes, not treated as a one-time implementation task, since the drift risk covered above accumulates the same way other forms of content drift do. Chapter 9.6 folds this schema check into the broader recurring technical audit alongside access, rendering, and canonical consistency.

Formalizing Clarity, Not Manufacturing It

Michael Rubinstein has pushed back consistently against schema being sold as a standalone visibility lever, because that framing sets teams up to skip the actual content work this framework spends most of its chapters covering, in favor of a markup implementation that feels more concrete and more finishable than the harder work of building genuinely clear content.

ScribePress implements FAQPage, Article, and HowTo schema as a final, formalizing step on content already built for clarity and structure, matching the same sequence Chapter 6.6 established for entity schema, rather than treating markup as a standalone deliverable disconnected from the content it exists to confirm.

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

Put the framework to work