Schema on Every Page. None of It Connected.

By Scott Finney • May 12, 2026

A regional consulting firm had a 30-page static website with structured data on most pages. The homepage had Organization and FAQPage schema. Event pages had Event markup. Blog posts had Article schema. On paper, structured data was handled.

It wasn't.

A closer look revealed inconsistencies that undermined the entire entity graph. Seven pages — services, workshops, a recruitment page, the contact page — had nothing beyond a BreadcrumbList. Six location pages serving metro areas lacked WebPage and SpeakableSpecification markup, making them invisible to voice search and AI citation. The @id references that should have connected entities across the site were fragmented: the founder was defined with one identifier on one page and referenced with a different identifier on another. One archived event page used a bare domain while the rest used www — technically two different entities in JSON-LD.

The result: a site that looked schema-aware but wasn't actually maximizing its visibility in rich results, AI answer engines, or voice search.

Phase 1: Skills Audit and Tool Mapping

The first step wasn't touching the site. It was reading ten existing internal reference documents to understand what the team already knew about schema and where the gaps were. The SEO reference had a schema section with four basic JSON-LD templates — useful but shallow. The geo-optimization reference mentioned schema for entity clarity but deferred to the SEO doc for details. None of the other eight documents addressed structured data at all.

Simultaneously, third-party tools were mapped. ClassySchema.org was evaluated for its full capabilities: a HowTo generator, FAQPage generator, Video generator, SpecialAnnouncement generator, and a Structured Data Visualiser that accepts raw HTML or fetches a live URL. These were cataloged alongside Google's Rich Results Test and the Schema.org validator to create a generate-validate-deploy workflow.

The output: a comprehensive reference document covering 20+ page-type-to-schema-type mappings, copy-paste JSON-LD templates for every relevant type, a completeness audit checklist, and the full tool integration workflow. This became the playbook for everything that followed.

Phase 2: First Implementation Pass

With the reference framework in place, the first round of changes targeted the most visible gaps. Seven pages received new or upgraded schema:

• About page — WebPage upgraded to AboutPage with mainEntity linking to the Organization
• Contact page — new ContactPage schema with SpeakableSpecification
• Workshops page — new WebPage with Speakable
• Recruitment page — new WebPage plus JobPosting schema with proper employment type, location, and hiring organization references
• Updates index — new ItemList with all articles, Speakable added to existing CollectionPage
• Locations index — new ItemList with all location pages

Phase 3: Entity Graph Audit

Rather than assuming the first pass was clean, a full @id connectivity audit was run across all 32 HTML files. Every entity definition and every entity reference was cataloged and cross-checked.

Five issues surfaced:

• Founder defined with wrong ID — The Organization block defined the founder as one identifier, but event pages referenced a different one. Two different @id values for the same person.
• Cross-domain orphan — An external organization ID was referenced in eight files but never formally defined on the site's domain.
• Domain variance — One event page used the bare domain across eight URLs while every other file used www. In JSON-LD, those are two different entities.
• LocalBusiness disconnected — The homepage LocalBusiness block had no @id, making it invisible to the entity graph.
• Founder definition in wrong location — The #founder Person was only defined in the contact page, not on the homepage where the Organization lived.

Each issue was fixed: a canonical #founder Person was defined on the homepage with sameAs linking to external profiles, the LocalBusiness got an @id and connected its founder property via reference, and all domain inconsistencies were standardized.

Phase 4: Full Re-Audit and Final Pass

A second complete audit checked every HTML file for three things: does it have a page type (WebPage, AboutPage, etc.), does it have SpeakableSpecification, and does it have BreadcrumbList. This surfaced a final layer of gaps:

• Six location pages — had LocalBusiness and BreadcrumbList but no WebPage or Speakable
• Seven article pages — had Article but no Speakable
• FAQ page — had FAQPage but no WebPage or Speakable
• Newsletter page — had only BreadcrumbList (added WebPage with SubscribeAction)
• Privacy and Terms pages — had only BreadcrumbList
• One event archive page — missing WebPage and Speakable

All 22 files were updated in this final pass.

By the Numbers

What Changed for the Business

Every page on the site now tells search engines and AI models exactly what it contains, who published it, and how it connects to the rest of the site. Before, a voice assistant or AI answer engine reading the FAQ page would see questions and answers but wouldn't know who published them or what organization they belonged to. Now that metadata is explicit on every page.

The location pages — critical for local search visibility — went from bare LocalBusiness entries to fully connected entities with WebPage, Speakable content markers, and an ItemList on the index page that tells search engines "these six pages are a set." The same pattern was applied to the blog index and its articles.

The reusable reference document means the next time a page is added to the site — a new case study, a new event, a new location — the schema decision is already made. The template exists, the validation workflow is documented, and the entity graph conventions are established. Schema went from something that had to be figured out each time to something that follows a pattern.

How It Was Built

I decided what mattered: that schema coverage should be maximized, that ClassySchema.org should be evaluated as a tool ecosystem, and that the output should include a reusable reference for future projects. I also directed the re-audit after the first implementation pass — recognizing that one round of changes wasn't enough to claim completeness.

The AI handled execution at a pace that made multiple audit-implement-reaudit cycles practical within a single session:

• Research — Read all ten reference documents, fetched and analyzed five ClassySchema.org pages, and ran web searches to map the full tool inventory — all in parallel.
• First audit — Grepped every HTML file for existing @type declarations and built the gap table.
• Implementation — Wrote 35+ JSON-LD blocks across 22 files, each tailored to the page's actual content.
• Entity graph analysis — Cataloged every @id definition and reference across 32 files, identified five connectivity issues, and fixed each one.
• Re-audit — Ran a second full-site scan, identified 15+ remaining gaps across location pages, articles, and utility pages, and closed all of them.
• Reference creation — Synthesized everything learned into a comprehensive document with templates, checklists, and tool workflows.

When implementation takes minutes instead of hours, you can afford to audit, implement, re-audit, and implement again in the same sitting. The planning conversation — deciding what to build and why — took longer than any single round of implementation. That's the ratio you want: human judgment as the bottleneck, not human typing.

Is Your Structured Data Actually Working?

Having schema on your pages isn't the same as having schema that works. If your entity graph is fragmented — different IDs for the same person, domain mismatches between pages, key pages missing page types — search engines see disconnected fragments instead of a coherent site.

The gap between "we have structured data" and "our structured data is connected and complete" is where visibility gets left on the table.