Should you switch to the new structured data testing tool after the old Google tool's retirement?

Why is Google getting rid of this historic tool?

Google is streamlining its tools and prefers to focus its resources on what directly impacts display in search results. The old structured data testing tool validated any schema.org markup, including types that Google does not use to generate rich results.

The issue? Many SEOs thought that a markup validated by this tool would necessarily be considered by Google. False. A perfectly valid Article markup according to schema.org does not guarantee a display in rich results — you must also meet Google's specific eligibility criteria.

What is schema.org's exact role in this transition?

Schema.org takes over the source code of the old tool and maintains it as a generic validator. This makes sense: schema.org is the consortium that defines the vocabulary for structured data, independent of Google.

This separation clarifies responsibilities. Schema.org validates syntax and compliance with the standard, while Google focuses on what actually generates features in its SERPs through rich results testing in Search Console.

How does Search Console concretely replace the old tool?

Search Console now offers the rich results test, which simulates the potential display of your markup in Google's results. It covers the types of markup that Google effectively uses: recipes, products, FAQs, events, articles, etc.

The fundamental difference? This tool does not validate all types of schema.org — only those that trigger rich results with Google. If you mark up CreativeWork or MedicalEntity, Search Console will not give you feedback: these types do not generate any special display in the SERPs.

• The old testing tool validated JSON-LD/Microdata syntax for all schema.org types
• The rich results test only checks the types used by Google and simulates the display
• The tool transferred to schema.org remains accessible to validate generic markup outside Google’s scope
• None of these tools guarantee actual display in production — Google retains control over its eligibility criteria
• You now need to cross-check multiple sources to fully validate your markup

Does this strategy from Google indicate a desire for greater control?

Absolutely. By pushing SEOs towards rich results testing in Search Console, Google directs the markup effort towards what directly serves its own features. We lose sight of the purpose of structured data beyond Google: Bing, Yandex, voice assistants, content aggregators.

The risk? Practitioners may stop marking up what isn't immediately rewarded by a rich display on Google. However, Organization, SameAs, or ContactPoint markup remains relevant for the global knowledge graph, even without a visible rich result. [To be verified]: Google claims that markup not used for rich results can still help better understand entities — but no public data quantifies this impact.

Does the transfer to schema.org truly ensure the tool's longevity?

Not necessarily. Schema.org is a consortium where Google has significant weight, but it also relies on external contributions and funding. Nothing guarantees that the tool will stay updated with changes in schema.org or that it will receive regular patches.

In practice, we already see that some third-party tools (like Yandex's validator or Chrome extensions) do not always follow the latest specifications. If schema.org does not mobilize dedicated resources, the tool risks stagnating. For now, it’s impossible to say if the community will take over — it’s a wait-and-see situation.

Should we still care about validating markup outside Google’s scope?

Yes, if your SEO ecosystem extends beyond Google. A site targeting multiple engines (Bing for certain markets, Yandex in Russia, Baidu in China) must continue to validate its generic markup. Similarly, if you're using structured data for third-party integrations (CRM, semantic analytics tools, voice assistants), schema.org validation remains relevant.

But let’s be honest: for 90% of sites, the focus should stay on achieving visibility in Google's SERPs. The rest is a bonus. If you have to choose, prioritize the rich results test and ensure that your markups trigger the expected features. Schema.org validation becomes a second-tier complement.

Which tool should you use based on your specific use case?

If you want to check that your markup triggers a Google rich result, go directly to the rich results test in Search Console. It has become the go-to tool for simulating SERP display and detecting blocking errors for eligibility.

If you are marking up schema.org types that Google does not use (Person, Organization, SameAs, ContactPoint, etc.) or targeting other engines, use the validator hosted by schema.org. It remains relevant for validating JSON-LD or Microdata syntax but won’t provide insights on Google’s display.

How to adjust your validation workflows after this transition?

Incorporate a double-check system into your deployment processes. First, validate the syntax with the schema.org validator to ensure your JSON-LD is clean. Then, test the URL in Search Console to confirm that Google detects and can display the rich result.

Never rely solely on one or the other. A syntactically correct markup can fail Google’s eligibility criteria (too small an image, missing date, invalid author). Conversely, Search Console may sometimes show a preview when the markup contains schema.org errors that other parsers reject.

What errors should be avoided during this migration phase?

The first error: assuming that the old tool has disappeared and panicking. It is still accessible via schema.org — bookmark the new URL. The second error: believing that Search Console validates all your markups. It ignores types not used by Google, which may give you a false impression of complete validation.

The third error: abandoning markup that does not immediately generate rich results. Structured data feeds the global knowledge graph, even without visible display. An Organization or SameAs markup remains relevant for long-term semantic understanding, even if the impact is not measurable in the short term.

• Bookmark the schema.org validator to replace the old Google tool
• Use the rich results test in Search Console for all types exploited by Google
• Update internal documentation and validation workflows
• Train teams on the difference between syntax validation and eligibility for rich results
• Continue marking up types outside Google’s scope if your ecosystem justifies it
• Monitor Search Console reports to detect markup errors in production