Most sites that believe they've handled structured data have only confirmed a script tag exists somewhere. Here's why valid JSON, a declared @type, and coverage across every page template are three separate — and separately common — failure points.
Structured data gets treated, in most teams' workflow, as a one-time checkbox: add a JSON-LD block somewhere, confirm it doesn't throw a visible error, move on. That treatment misunderstands what the markup is actually for. Schema.org JSON-LD isn't decoration for your existing content — it's a separate, machine-readable declaration of what your content is, addressed to systems that otherwise have to infer that from unstructured text. "Present" and "correctly describing your entities" are different bars, and most sites that believe they've handled structured data have only cleared the first one.
Why "It's There" Isn't the Same As "It Works"
A JSON-LD block is a script tag containing a JSON string, and JSON is unforgiving syntax — a trailing comma, an unescaped quote inside a title pulled from a CMS field, a missing closing brace, and the entire block fails to parse. When that happens, you don't get a partial result or a warning banner. You get nothing: the block is invisible to anything trying to read it, exactly as if you'd never added it, while it continues to look present in your page source to a human skimming for the script tag. This is the single most common gap between "we have structured data" and "we have structured data that does anything" — it's not that teams forget to add markup, it's that a dynamically generated block breaks silently for a specific content edge case and nobody notices because nothing visibly changed on the page.
A Valid Block With the Wrong (or No) @type Is Still Incomplete
Syntactically valid JSON-LD that declares no @type, or the wrong one, solves the parsing problem without solving the actual problem. The @type is the part that tells a consuming system what kind of entity it's looking at — Product, Article, Organization, FAQPage, and the rest of the Schema.org vocabulary exist specifically so a page doesn't have to be inferred from prose. A block that parses correctly but omits @type, or nests it incorrectly inside a structure a parser won't traverse, is markup that exists without actually classifying anything. This is a subtler failure than broken JSON because it produces no error at all — the page just quietly fails to declare what it is, the same outcome as having no structured data, arrived at through a more convincing-looking route.
The Coverage Gap: One Good Page, Every Other Template Bare
The most consistent pattern in practice isn't broken markup — it's uneven coverage. A homepage gets real attention (often because a developer implemented Organization schema once, deliberately, during a site launch) while the templates that actually drive most of a site's indexed pages — product pages, articles, category listings — carry nothing at all. A single well-marked-up homepage creates a false impression of completeness precisely because it's the page most likely to get manually checked. Auditing structured data seriously means sampling across page types, not confirming the homepage looks right and extrapolating from there.
Where Microdata and RDFa Still Fit
JSON-LD has been Google's recommended format for years because it lives in a separate script block, independent of the surrounding HTML — it can be added, updated, or corrected without touching the content markup itself. Microdata and RDFa embed the same kind of declarations directly as HTML attributes (itemscope/itemtype, or typeof/vocab), which still works and is still recognized, but couples the structured layer to the template markup in a way that makes it more fragile to change and harder to audit at a glance. Sites migrating off an older template sometimes carry Microdata forward without realizing JSON-LD has since become the more maintainable choice — not wrong, just worth being deliberate about rather than inherited by accident.
The Newer Reason This Matters: Machine-Readable Facts for AI Retrieval
Structured data's original audience was search engines building rich results — star ratings, FAQ accordions, breadcrumb trails in the SERP. That audience has grown. AI systems synthesizing an answer benefit from the same explicit, unambiguous declarations for the same reason search engines always did: a clearly typed Organization or Product entity with declared properties is easier to extract a correct fact from than the equivalent information stated in prose, where it has to be parsed out of sentence structure. This doesn't replace the content-and-crawler-access side of GEO work covered in our GEO & AI Visibility guide or in tracking AI citations — it's an adjacent lever, worth pulling for the same underlying reason: making facts about your entities unambiguous to a machine reader, whichever kind of machine is reading.
What an Actual Audit Needs to Confirm
Three checks, in order, on every page template that matters: does JSON-LD parse as valid JSON at all (not just "is a script tag present"); does it declare an appropriate @type for what the page actually is; and does that coverage hold across a representative sample of your templates, not just the homepage. SearchVitals' structured data check runs exactly this sequence — JSON-LD, Microdata, and RDFa presence, JSON validity, and declared types — across the homepage and a sampled set of other pages per site, specifically so a clean homepage doesn't mask bare templates everywhere else. Run that exact sequence against a single page right now with our free Structured Data & GEO Readiness Checker. For the rest of the on-page factors this sits alongside, see our On-Page SEO guide.