Free Magento Schema.org JSON-LD validator

For a typical Magento store, six types drive most rich-result eligibility:

• Product — every PDP. Drives star ratings, price snippets, and Google Merchant Listings (free).
• BreadcrumbList — site-wide. Drives the breadcrumb trail in the SERP instead of the raw URL.
• Organization — once per site. Drives the knowledge panel + logo in branded SERPs.
• Article — blog and pillar pages. Drives Article rich result + Top Stories eligibility.
• FAQPage — FAQ-heavy CMS pages. The FAQ accordion in SERP is still supported for some queries (Google quietly demoted it for product/commercial intent in 2023).
• LocalBusiness — for stores with a physical address. Drives the local pack + Google Business Profile cross-checks.

The validator supports all six plus another nine (Person, Service, SoftwareApplication, Course, HowTo, Recipe, Event, Review, DefinedTerm) which Magento stores emit less often but still ship for certain use cases (Service-type pages on Magento + Hyvä service-business stores; Recipe-type for food brands; Course-type for academy/training sites; etc.).

JSON-LD. Google explicitly recommends it. Microdata still works but is deprecated for new implementations. RDFa is dead for ecommerce.

Why JSON-LD wins for Magento specifically:

• Decoupled from markup. Microdata interleaves itemprop attributes inside <div> trees — touch the layout, break the schema. JSON-LD lives in a single <script type="application/ld+json"> tag, isolated from the storefront DOM.
• Hyvä-safe. When you migrate Luma → Hyvä, your microdata-bound itemprop attributes are scattered across hundreds of phtml files. With JSON-LD you ship one block per page-type and the Hyvä migration leaves it alone.
• Faster for Google. JSON-LD parses faster than walking the DOM for microdata; Googlebot has an explicit fast-path for application/ld+json.
• Magento 2.4.7+ ships JSON-LD by default for Product. The core Magento_Catalog module emits it. Microdata is legacy.

This validator only validates JSON-LD. If you’re on microdata, your migration path is: extract microdata to a server-side template, emit it as JSON-LD via a Product block, then validate.

Three reasons, in descending frequency:

1. Sampled data drift. Search Console’s “Enhancement” reports are based on Googlebot’s last successful crawl — which can be 2–6 weeks behind your latest deploy. The Rich Results Test fetches your page live. So if you fixed schema two weeks ago, RRT is green but Search Console is still reporting the old errors.
2. Stricter Search Console policy. Search Console validates against rich-result eligibility rules (more strict than basic Schema.org). For example: Product is valid Schema.org if you have a name alone, but Google’s product rich-result rules require name + image + offers.price + offers.priceCurrency + offers.availability. RRT catches this; basic Schema.org validators don’t. This validator does — it scores both layers.
3. Page-state mismatch. Search Console sees pages with empty offers.price when stock = 0 or the product is configurable. Your test JSON-LD has a simple Product with a fixed price. Both can be “valid” for their respective inputs.

Fix path: re-validate the exact same JSON-LD Googlebot saw (use Search Console’s URL Inspection → View Tested Page → HTML to grab Googlebot’s render) against this validator. If we both flag it, fix it. If only Search Console flags it, you’re in case #1 — wait a crawl cycle.

Three trigger events — everything else is theatre:

• After every Magento upgrade. Core Magento_Catalog can change what it emits per minor version (2.4.8 changed offers.availability URL casing in core Product schema). Revalidate one PDP + one Article + one FAQPage after every setup:upgrade.
• After every theme migration. Luma → Hyvä; Hyvä major version bumps; replacing your custom theme. Each can swap or drop the structured-data block silently.
• After every schema-related extension install / update. Mageplaza Better Product Reviews, Amasty Advanced Reviews, Magefan Blog — each can inject its own aggregateRating or Article JSON-LD that conflicts with what core emits. Revalidate one page where the extension is active.

Outside those: schedule a quarterly spot-check against your top 10 organic landing pages. That’s enough — Schema.org vocabulary changes ~1–2 properties per quarter and Google updates rich-result eligibility maybe twice a year.

What you do not need to do: revalidate every PDP after every product edit. JSON-LD is template-driven — if one PDP validates clean, all PDPs of that product type are fine. Validate by template, not by product.

Not in a single click — the validator takes one JSON-LD snippet at a time. But you don’t need to validate every page; you need to validate every template.

For most Magento stores, that means 6–10 snippets:

1. One Product JSON-LD from a Simple PDP
2. One from a Configurable PDP
3. One from a Bundle PDP (if you use them)
4. One Category JSON-LD (often empty, which is its own problem — the validator catches that too)
5. One Article JSON-LD from your blog
6. One Article from a CMS service page
7. One FAQPage from a CMS / pillar page
8. One Organization (homepage)
9. One BreadcrumbList from any non-home page
10. One LocalBusiness (if applicable)

That covers ~95% of your URL surface. If any of those fail validation, every page of that template fails. Fix the template once; fix the whole site at once.

For a full automated crawl (which is what big agencies sell as a $5k schema audit), I do it manually as part of the full-site audit service — crawl up to 500 URLs, validate each JSON-LD, deduplicate by template, ship a per-template fix list. 48 hours, fixed price.

Schema.org marks each property as either required (must have for the type to be valid), recommended (improves rich-result eligibility), or optional (nice-to-have). The validator reports them in three buckets:

• Errors — missing required, wrong datatype, invalid enum value. These block rich-result eligibility. Fix immediately.
• Warnings — deprecated property, suspicious value, non-canonical @context URL. Worth fixing but won’t block rich results.
• Missing recommended — the property is allowed-but-absent. Google’s eligibility rules treat each missing recommended as a soft penalty against your rich-result score.

You don’t need to fix every “missing recommended” to be eligible — but the more you have, the better your chances. For Product specifically: sku, mpn, gtin13, brand, aggregateRating, and review are the high-value ones — adding them moves you from “eligible” to “competitively eligible” for Merchant Listings.

For Article: author, publisher, image at multiple aspect ratios (1:1, 4:3, 16:9), dateModified, and articleSection. Add these and your Top Stories eligibility climbs.

The validator’s 0–100 score weights required-property completeness 60%, recommended-property completeness 30%, and warning count 10%. Fix every error to get to ~60. Add the high-value recommended properties to climb past 85 (rich-result eligible).

Most do, some don’t. Google’s rich-result rules are pickier than the Schema.org vocabulary itself:

• Hard blockers (rich result will not appear): missing required property for the rich-result type, malformed JSON syntax, @type not matching a valid rich-result type, image not resolvable, price not a Number, priceCurrency not a valid ISO 4217 code.
• Soft blockers (rich result may appear but with degraded features): missing aggregateRating (no stars in SERP but other parts of the rich result still show), missing brand on Product (price snippet shows but Merchant Listing eligibility may drop), missing author on Article (Top Stories ineligible but standard Article result still works).
• Non-blockers (rich result appears anyway, but the validator flags for hygiene): deprecated properties (Schema.org marks them but Google still honours them for backwards compatibility), non-canonical @context URLs (http://schema.org still works), excessive nesting depth (warns at ≥6 levels but works at ≥10).

The validator’s “Valid / Invalid” pill reflects Schema.org validity. The 0–100 score reflects rich-result eligibility. They’re different signals — a snippet can be Valid (Schema.org passes) with a score of 55 (rich result unlikely to appear). Watch both.

Both are useful; they answer different questions.

Google’s Rich Results Test is the source of truth for “will this rich result appear in Google SERP?” It runs Google’s actual rich-result eligibility rules and returns: pass/fail per rich-result type, the rendered preview, and Googlebot-fetched HTML. Use it as the final eligibility check before pushing schema to production.

This validator is the per-property debugger. It tells you where your JSON-LD is broken, what datatype each property should be, and gives copy-pastable fix examples. Google’s tester gives a binary pass/fail with cryptic error messages (“Either ‘offers’, ‘review’, or ‘aggregateRating’ should be specified”); this validator gives offers.priceCurrency: expected ISO 4217 code, got "USD " (trailing whitespace).

My recommended flow:

1. Paste snippet into this validator — iterate until score ≥85, zero errors, zero warnings.
2. Deploy to staging.
3. Run Google’s Rich Results Test against the staging URL. If it passes, ship to production. If it fails, paste the staging-rendered JSON-LD back into this validator — one of the post-render values is probably empty (out-of-stock product, configurable with no default selection, etc.).
4. Re-test on production 24h after deploy. Search Console reflects the change in 2–6 weeks.

Yes — but you need to validate the rendered JSON-LD as Googlebot sees it, not your template source.

The challenge with Magento + dynamic pricing:

• Customer-group pricing → different prices per group → Googlebot sees the “not-logged-in” price (NOT_LOGGED_IN customer group).
• B2B segment pricing → segment-aware prices → Googlebot sees the default segment’s price (or no price if segmented away from default).
• Tier prices / minimum order quantity → Googlebot sees the unit price for qty=1.
• Configurable products → if you don’t pre-select a default child, Googlebot sees the parent’s placeholder price (often empty — this is the #1 source of “missing price” Search Console errors on Magento configurable PDPs).

How to test:

1. Open the PDP in an incognito browser (no auth, no segment cookies).
2. View source, find application/ld+json, copy the rendered JSON-LD (not your template source).
3. Paste into this validator. If offers.price is empty or "0.00" when stock exists, the price isn’t rendering for anonymous visitors — this is the bug.

Fix path: emit a price + priceSpecification structure that uses the default-segment price, or use priceRange on the parent Configurable with min/max from child SKUs. The validator’s fix-suggestions section gives you a copy-pastable Magento PHP block to do this.

Three weighted components:

• Required-property completeness (60% of score). Every required property present and correctly typed = full 60 points. Each missing required property subtracts ~15 points (depending on which property; image is heavier than alternateName). A datatype mismatch on a required property scores the same as missing.
• Recommended-property completeness (30% of score). Each recommended property present = +N points where N is proportional to its rich-result value. Adding aggregateRating on Product is worth ~6 points; adding color is worth ~1 point. The top 5 recommended properties together typically account for ~80% of the 30-point pool.
• Warning-count penalty (10% of score). Up to -10 points based on warning count (deprecated properties, non-canonical @context, suspicious values). Each warning subtracts ~1 point capped at -10.

Score bands:

• ≥85 — green ring. Rich-result eligible. Cross-check with Google’s tester before shipping.
• 60–84 — amber ring. Schema is valid but rich-result eligibility uncertain. Likely missing high-value recommended properties.
• <60 — red ring. Errors present; rich result will not appear until errors are fixed.

The score is type-specific — a Product score of 92 means “ready for Merchant Listings + star snippets”; an Article score of 92 means “ready for Article + Top Stories”.

Course, HowTo, Recipe, and Event are supported. VideoObject is on the roadmap.

Currently supported (15 types):

• Course — for Magento + Hyvä academy / training sites. Validates name, description, provider, and hasCourseInstance if present.
• HowTo — for tutorial CMS pages. Validates step array with HowToStep children. Note: Google demoted HowTo rich results for non-Google-Search-Console-verified sites in 2023; the schema still validates but the rich result rarely shows for ecommerce stores.
• Recipe — for food / DTC food brands selling cookware or ingredients. Full validation including recipeIngredient, recipeInstructions, nutrition.
• Event — for stores running launches, pop-ups, webinars. Validates startDate, endDate, location, organizer.

VideoObject is the most-requested addition. I’m holding back on it because Google’s VideoObject rules require live URL probes for contentUrl + thumbnailUrl + duration check, and that conflicts with the “zero data stored” promise of this tool. I’m exploring a HEAD-only validation pattern; expect it in Q3 2026.

If you need to validate something exotic (Dataset, MedicalEntity, Drug, etc.) — paste it anyway with Auto-detect, the validator will fall back to generic Schema.org type-checking and at least flag obvious errors (datatype mismatches, missing @type, non-canonical @context).

Hire a full-site auditor when:

• You have ≥10 page templates. Validating manually per template starts costing real time at 10+. A crawl-based audit hits every template in one pass.
• You’re seeing errors in Search Console that you can’t reproduce in this validator. That means the issue is page-state-dependent (stock = 0, customer-group price, segment-aware content) and needs Googlebot-fetched HTML inspection, not template inspection.
• You’re launching a new theme / Hyvä migration. Pre-launch audit prevents schema regression at cutover. Post-launch audit confirms parity.
• You’re going from “some pages have schema” to “every page-type has schema.” Roadmap-and-implementation work; this validator is for fixing existing schema, not designing new schema.
• Search Console is showing >100 affected URLs for a single issue. One template-level bug usually explains it — but isolating which template needs the audit.

How my full-site audit works:

1. Crawl up to 500 representative URLs (sampled by template).
2. Extract every JSON-LD block; deduplicate by template signature.
3. Validate each template’s schema against Schema.org + Google’s rich-result rules.
4. Cross-reference with Search Console “Enhancement” reports if you give me access (read-only).
5. Ship a per-template fix list: which Magento file to edit, what to change, copy-pastable code.
6. 48-hour turnaround. Fixed price. Optional implementation phase.

Use the form above to send your store URL + page list, or email kishansavaliyakb@gmail.com directly.