Core Structured Data Foundation
O-5 — Core Structured Data Foundation
What this action is
O-5 is the comprehensive implementation of Schema.org structured data across the brand’s pages. It comprises three components: entity-level schemas (Organization, LocalBusiness, Person, Brand) declaring the brand as a coherent entity; content-type schemas (Article, FAQPage, HowTo, Product, BreadcrumbList) declaring what each page contains; and supporting schemas as appropriate to the brand’s content (Recipe, Event, Course, Review, Speakable, etc.).
The work is engineering with substantial editorial input. Engineering implements the schema templates; editorial supplies the content (entity descriptions, author identification, FAQ content, etc.). The work cannot be done by either function alone.
Why this action matters in AVO
Structured data is the most direct mechanism by which AI systems ground entity claims about a brand. A brand without Schema.org markup is a brand AI must interpret entirely from raw text, which is interpretable but not grounded. A brand with comprehensive structured data is a brand AI can cite with structural confidence.
The methodology paper notes that structured data is more important in AI-mediated discovery than it ever was in traditional SEO. The reason is mechanical: AI systems use Schema.org and similar structured signals to ground their understanding of what a brand is and what category it belongs to, while traditional search systems used structured data primarily for snippet enhancement.
O-5 is high-leverage because it affects multiple V1.1 datapoints simultaneously and creates the entity scaffolding that subsequent G-pillar work (G-1, G-11) extends.
What it requires before you can attempt it
Hard prerequisites:
| Prerequisite | Why required |
|---|---|
| O-4 substantially complete | Structured data is implemented in templates; templates depend on the broader infrastructure O-4 establishes |
| Engineering capacity for template implementation | O-5 is template engineering work; engineering capacity must be available |
| Editorial capacity for schema content | Schema properties (descriptions, author bios, FAQ content) are editorial; without editorial input, schemas are sparse |
Soft prerequisites:
| Prerequisite | Why it helps |
|---|---|
| Existing Schema.org work from prior consultants | If schema is partially implemented, audit and extension is faster than greenfield implementation |
| Documented brand identity (founding date, address, leadership, business activity) | Schema requires this information; assembling it is part of O-5 if not already documented |
| CMS that supports template-level schema generation | Plugin-based or manual schema implementation works but is more fragile than CMS-native support |
Stage assessment: O-5 is a foundations-stage action that follows O-4. It can be conducted in phases (entity schemas first, then content schemas, then specialized schemas) over multiple cycles or as a unified push.
What gets done in this action
O-5 work proceeds through five phases.
Phase 1 — Schema audit and gap analysis. Existing Schema.org markup across the brand’s pages is inventoried. Existing schemas may be partial, malformed, or appropriate. Gaps are identified: which page types lack schema, which schemas are partial, which are deprecated.
Phase 2 — Entity schema implementation. The entity-level schema (Organization, LocalBusiness, Person, or Brand as appropriate) is implemented on the homepage and key entity pages. Properties are completed substantively: name, url, logo, sameAs, description, foundingDate, founder, address, contactPoint, areaServed, knowsAbout (where applicable). The entity schema is consistent across pages.
Phase 3 — Content-type schema implementation. Article schema is implemented on editorial templates. FAQPage schema is implemented on FAQ templates. Product schema on product templates. BreadcrumbList on every page that has breadcrumbs. The implementation is template-level so new content automatically receives the appropriate schema.
Phase 4 — Specialized schema as appropriate. Brands with specific content types implement appropriate schemas: Recipe for recipe brands, Event for event-related content, Course for educational content, Review where reviews are produced, Speakable for content optimized for voice, ImageObject and VideoObject for multimedia.
Phase 5 — Validation and ongoing monitoring. All schema is validated against Google’s Rich Results Test, Schema.org’s official validators, and Bing’s structured data testing tool. Errors are remediated. Monitoring is established to detect schema breakage as the site evolves (CMS upgrades, plugin updates, template changes can all break schema).
What success looks like
A successful O-5 produces:
- Entity-level schema present on the homepage and key pages with substantive properties
- Content-type schemas on the templates appropriate to the content
- Schema validation clean against major validators
- Datapoint movement: schema-presence, entity-schema, structured-content-signals all lift toward high
- Subsequent V3.1 work has scaffolding (entity schemas provide the sameAs targets that G-1 work expands)
Beyond datapoint movement, success is engineering culture that maintains schema discipline. Schema is fragile to template changes; without ongoing maintenance, errors accumulate.
What failure looks like
| Failure pattern | What it signals |
|---|---|
| Schema validates correctly but properties are minimal | Type declared, properties empty; AI grounding is partial |
| Schema declarations conflict with visible page content | The declared aggregateRating doesn’t match the visible reviews; the declared name differs from the page text. AI systems detect inconsistency and discount. |
| Schema implementation breaks during a CMS update | The plugin or implementation pattern was fragile; ongoing maintenance is needed |
| Schema is implemented on flagship pages but not on template pages | Most of the site is bare; the schema work hasn’t scaled |
| Schema includes deprecated types or properties | The implementation was based on outdated guidance; modern Schema.org has evolved |
Common mistakes
| Mistake | Better approach |
|---|---|
| Implementing schema as one-time work without maintenance | Schema requires ongoing validation; new content, template changes, CMS upgrades all create breakage opportunities |
| Filling property values with generic content | Schema properties carry weight when substantive; generic placeholders dilute the signal |
| Using deprecated types or properties | Reference the current Schema.org specification; some older guidance is now deprecated |
| Implementing only Organization schema and stopping | Content-type schemas are equally important; AI grounding benefits from both |
| Skipping validation | Errors are silent until they’re not; routine validation prevents accumulated breakage |
| Treating schema as marketing content | Schema is structural; the property values should be factual descriptions, not marketing copy |
Datapoints affected
| Datapoint | Influence |
|---|---|
| schema-presence (V1.1) | Direct, primary |
| entity-schema (V1.1) | Direct, primary |
| structured-content-signals (V1.1) | Direct, primary |
| meta-completeness (V1.1) | Indirect — schema work often surfaces metadata gaps |
| entity-recognition (V2.1) | Indirect — entity schemas establish canonical entity references |
| knowledge-graph-depth (V3.1) | Indirect — entity schemas provide sameAs targets that G-1 work extends |
Multilingual considerations
Schema.org is fundamentally language-neutral in its markup, but implementation has language-specific considerations:
inLanguageshould be declared accurately on every page- Property values that are human-readable should be in the page’s content language
- Per-language Organization schema may have localized property values
- sameAs links to per-language Wikipedia or knowledge-graph entries where they exist
- Per-language editorial content needs per-language Article schema with proper language declaration
A common multilingual failure mode is implementing Organization schema in English on all language variants, failing to localize the description and contact properties. This produces measurable degradation on non-English pages.
What comes after
O-5 typically leads to:
| Next action | Why it follows |
|---|---|
| G-1 (External Entity Verification, Knowledge Graph & Local Authority) | G-1 extends entity schemas with external verification and broader knowledge-graph presence |
| M-3 (Dedicated FAQ & Knowledge Hubs) | FAQ work uses FAQPage schema implemented in O-5 |
| M-7 (Multimedia Content Optimization) | ImageObject and VideoObject schemas implemented in O-5 are extended in M-7 |
| G-11 (Wikipedia & Wikidata Optimization) | Wikidata work depends on the entity foundations that O-5 establishes |
In maturity-stage terms, O-5 is foundations work that continues at maintenance level throughout. Schema additions for new content types occur as the brand’s content matures; ongoing validation continues throughout.