If a tutorial tells you to paste your code into Google’s Structured Data Testing Tool, that tutorial is stale. Google retired it, and the replacement is not one tool but three, each answering a different question. Picking the wrong schema markup tester is how people end up convinced their markup is broken when it is fine, or convinced it is fine when Google is ignoring it.
Here is what each tool actually checks, in the order you should use them.
What happened to the Structured Data Testing Tool
The old tool validated markup against the full schema.org vocabulary and reported everything it found, whether or not Google used it. That was genuinely useful for general validation and genuinely misleading for SEO, because a green checkmark implied eligibility for a search feature that may not exist.
Google deprecated it and split the job. Rich Results Test answers “will Google show a rich result for this page?” The schema.org validator, which the community took over, answers “is this markup syntactically valid?” Those are different questions and you will need both.
Google’s Rich Results Test: the eligibility check
This is the tool that matters for search. Give it a live URL or paste raw code, and it reports which Google rich result types the page qualifies for, plus errors and warnings per feature.
Three things make it the primary tester:
- It renders the page first. JavaScript-injected markup — from a tag manager, a React component, or a Shopify app — is executed before extraction, so what you see is close to what Googlebot sees.
- It shows the rendered HTML and any page-loading issues. Blocked resources and script errors show up here, which is often the real reason markup is missing.
- It tests mobile and desktop separately. Sites serving different markup by device get caught.
Read the output carefully. Errors mean a required property is missing and the feature is not eligible — fix these. Warnings mean a recommended property is absent; the feature still works, but filling them in usually improves display. And “no eligible rich results detected” does not mean your markup is broken. It often means the type you used is not a Google search feature at all, which is exactly when you move to the second tool.
The schema.org validator: the syntax check
validator.schema.org checks your markup against the complete schema.org vocabulary with no Google filter. It catches misspelled property names, values of the wrong type, malformed nesting, and types that do not exist.
Use it in three situations. First, when Rich Results Test reports nothing eligible and you need to know whether the problem is your syntax or Google’s feature list. Second, when you are marking up entities for general machine readability — Organization, Person, Dataset — where no SERP feature is expected. Third, when debugging markup a plugin generated, because it reports the full parsed object tree and you can see exactly what got emitted.
It will not tell you whether Google cares. That is the trade. Perfect validation here plus nothing in Rich Results Test means valid markup for an unsupported feature.
Search Console: the only view of what Google actually did
The first two tools test a page in isolation, on demand. Search Console’s Enhancements reports show how Google is treating your real pages at scale, over time, after crawling them itself.
Each structured data feature Google detects on your site gets its own report with valid item counts, warnings, and errors, plus example URLs for each problem. After deploying a fix, use the Validate Fix button to queue a recrawl of the affected URLs and watch the state progress.
Two habits make this reliable. Expect lag — new markup takes days to weeks to appear depending on crawl frequency, and it populates gradually rather than all at once. And pair it with the Performance report filtered by search appearance, which is the only place you can see whether an enhanced listing changed impressions and click-through rate. That comparison is the actual measure of success, not a validator’s green tick.
A testing workflow that catches real problems
Run this sequence whenever you ship or change structured data:
- Validate the code before deploy by pasting the raw JSON-LD into the schema.org validator. Catches typos in seconds.
- Test one live URL per template in Rich Results Test after deploy. If the product template is correct, all 4,000 product pages are correct — testing every URL is wasted effort.
- Compare markup against the rendered page. Open the URL, read what a visitor sees, and confirm every marked-up value appears on screen. This is the check nobody runs and the one that prevents a violation.
- Check for duplicates. View source and search for
application/ld+json. Two Organization blocks from a theme and a plugin, or two Article blocks with different authors, will confuse Google more than missing markup would. - Watch Search Console for two to four weeks before declaring the project done.
The check no validator performs
Every tool above verifies syntax and eligibility. None of them verifies honesty, and that is where the real risk lives.
Structured data must describe content that is visible on the page. Markup claiming a 4.9-star rating that appears nowhere in the HTML, a price you do not charge, or FAQ answers no visitor can read is a structured data spam violation. It will validate cleanly in every tool listed here and can still trigger a manual action, and the consequence is loss of rich result eligibility across the whole site rather than just the offending page.
Review markup carries an extra rule worth stating plainly: reviews about your own business or your own products, published on your own site, are not permitted. Plenty of plugins generate them anyway. A tester will pass it; Google will not.
Testing markup you did not write
Most sites accumulate schema from several sources — the theme, an SEO plugin, an ecommerce app, a tag manager container someone configured in 2022. The result is often contradictory rather than merely redundant.
Audit it directly. View the rendered source, extract every JSON-LD block, and list what each declares. Then decide which single source of truth you want and turn the others off. Deduplication almost always improves results more than adding another type, and it removes the maintenance surface that causes the next contradiction.
Where testing fits in technical SEO
Schema validation is a narrow check on a narrow layer. It tells you nothing about whether the page is crawlable, canonicalized correctly, fast, or duplicated across four URL variants — and those problems will cost you far more than a missing recommended property.
Run structured data testing as part of a broader technical pass rather than in isolation. SEO Rocket’s technical audits cover the surrounding layer: an instant quick scan of around 25 pages, or a deep full-site crawl verified past 900 pages, with the actual titles, URLs, and H1 text attached to each finding, plus PageSpeed and Core Web Vitals backed by real-user field data. It does not generate or validate your schema — use the three tools above for that — but it tells you whether the pages carrying that markup are healthy enough for it to matter.
