Start here
Before You Fix It: What This Check Means
Structured data provides machine-readable context that search engines use for richer interpretation. In plain terms, this checks whether search engines can read useful Schema.org markup on the page. Scavo inspects the page for Schema.org markup using two formats.
Why this matters in practice: incorrect signals here can dilute indexing clarity and search traffic quality.
How to use this result: treat this as directional evidence, not final truth. Search indexing outcomes depend on crawler recrawl cadence and ranking systems outside your direct control. First, confirm the issue in live output: verify raw HTML output and crawler-facing validators Then ship one controlled change: Generate JSON-LD from typed/shared helpers, not ad-hoc string concatenation. Finally, re-scan the same URL to confirm the result improves.
TL;DR: Your pages lack Schema.org markup, so you're missing out on rich results like star ratings, FAQ dropdowns, and product prices in search.
Rich results account for 58% of clicks in search results, with FAQ schema achieving an average 87% CTR and product schema boosting clicks by 25% (Lantern Digital/Schema Markup Statistics, 2026). One case study showed a 20% CTR increase within 30 days of adding structured data, with overall traffic improving by 25% (SearchPilot). Without markup, you're invisible to rich result formats.
What Scavo checks (plain English)
Scavo inspects the page for Schema.org markup using two formats:
- JSON-LD blocks (
<script type="application/ld+json">) - Microdata (
itemscopemarkup)
For JSON-LD, Scavo validates parseability and type clarity:
- Counts total JSON-LD blocks found
- Counts valid vs invalid JSON-LD blocks
- Extracts discovered
@typevalues
How Scavo scores this check
Result behavior:
- Pass: valid JSON-LD exists (or microdata exists) with no critical parse issues
- Warning: structured data exists but some JSON-LD blocks are invalid
- Warning: JSON-LD exists but no
@typevalues detected - Fail: JSON-LD scripts exist but none can be parsed
- Info: Scavo could not gather enough reliable evidence on this run to score pass/fail confidently.
- Warning: no structured data detected at all
In your scan report, this appears under What failed / What needs attention / What is working for structured_data, followed by Recommended next steps and Technical evidence (for developers) when needed.
- Scan key:
structured_data - Category:
SEO
Why fixing this matters
Search engines can still read plain HTML, but structured data improves disambiguation and eligibility for enhanced search features. Invalid blocks are typically ignored, which means teams think schema is live when it is not actually usable.
It also helps internal consistency. If your templates output page meaning via shared schema objects, new pages inherit cleaner machine-readable context by default.
Common reasons this check flags
- JSON-LD is hand-built in templates and breaks due to escaping/commas.
- CMS fields inject invalid JSON characters.
@typeis omitted or misnamed after refactoring.- Old schema fragments coexist with new ones and create parse failures.
If you are not technical
- Ask for validator evidence, not just "we added schema".
- Confirm each key page type has an intended schema type map (home, pricing, article, product, help).
- Require content and dev teams to agree on source-of-truth fields (name, URL, author, offers).
- Re-scan and verify invalid block count drops to zero.
Technical handoff message
Copy and share this with your developer.
Scavo flagged Structured Data (structured_data). Please validate every JSON-LD block for parseability, ensure explicit @type values are present, align schema with visible page content, and provide Rich Results/Schema validator evidence.If you are technical
- Generate JSON-LD from typed/shared helpers, not ad-hoc string concatenation.
- Guarantee valid JSON serialization (encoding + escaping).
- Ensure each object has
@contextand explicit@type. - Match schema fields to visible content (title, author, dates, offers).
- Remove stale/duplicate blocks that no longer represent the page.
- Validate in CI for critical templates before deploy.
How to verify
- View page source and locate all
application/ld+jsonscripts. - Run each URL through Google Rich Results Test and Schema.org Validator.
- Confirm no JSON parse errors and expected
@typevalues appear. - Re-run Scavo and confirm
json_ld_invalidis zero or reduced.
What this scan cannot confirm
- It does not guarantee a rich result will be shown in SERP.
- It does not validate every schema-property best practice for every vertical.
- It does not replace template-by-template semantic QA.
Owner checklist
- [ ] Define schema ownership by page type.
- [ ] Keep schema builders centralized in shared code.
- [ ] Add validation checks to release workflow.
- [ ] Review schema after CMS field/model changes.
FAQ
If schema is optional, why fix it?
Because valid schema improves machine interpretation quality and helps prevent ambiguity in search and AI retrieval contexts.
Is Microdata enough, or should we move to JSON-LD?
JSON-LD is usually easier to maintain and validate at scale. Microdata can work, but is often harder to keep clean in complex templates.
Why does Scavo warn when @type is missing?
Without explicit types, parsers cannot reliably classify the entity, so the markup gives limited value.
Should we include many schema types on one page?
Only when they accurately represent real entities on the page. Overloading unrelated types creates noise and maintenance risk.
Sources
- Google: Intro to structured data
- Google: Structured data policies for Search
- Schema.org
- Google Rich Results Test
- Schema Markup Validator
Need a schema map for each template in your app? Send support your page inventory and current JSON-LD snippets.
