Is Google's support for rich snippets really limited to JSON-LD?

What does this announced limitation really mean?

Mueller clarifies that JSON-LD would only be supported for a small number of schema.org tags. The two cited examples – events and site link search boxes – represent a tiny fraction of the hundreds of types available in the schema.org vocabulary.

This statement raises an apparent contradiction. Field observations show active rich snippets for reviews, recipes, products, FAQs, and articles in JSON-LD. If Google really only supported events and internal search, these rich displays simply wouldn't exist.

Why does Google communicate such a restrictive position?

Two hypotheses emerge. The first: this statement dates from an earlier period when JSON-LD support was indeed limited, prior to its gradual expansion. Google's caution in its official communications explains this potential gap between discourse and technical reality.

The second: Mueller may be making a distinction between documented official support and actual technical support. Google could technically read other types in JSON-LD without guaranteeing them in its official documentation, reserving the right to modify this behavior without notice.

How does this differ from other structured data formats?

Microdata and RDFa historically benefited from broader support at the time of this statement. JSON-LD, a newer but technically superior format, followed a gradual adoption curve at Google. The engine preferred to validate each type individually before guaranteeing its display.

Google's official documentation now recommends JSON-LD as the preferred format for most structured data types. This shift in position suggests a major evolution since Mueller's initial statement, moving from limited support to widespread adoption.

• JSON-LD was initially supported only for events and internal search, according to this statement
• Field observations contradict this limitation with functional rich snippets on many types
• Google likely distinguishes between technical support and official guarantee in its communication
• The current official position favors JSON-LD for nearly all types of schema.org
• The time gap partially explains this apparent contradiction

Does this statement still reflect the engine's technical reality?

No, and that's precisely what makes this statement historically interesting. Field tests show extensive JSON-LD support well beyond events and internal search. Product, Recipe, FAQPage, Article, Review – all these types generate rich snippets in JSON-LD.

Google's Search Central documentation explicitly recommends JSON-LD for dozens of different types. This contradiction between Mueller's statement and the current official position is striking. Either support has considerably broadened since then, or the initial communication was intentionally restrictive.

Should you still use Microdata or RDFa today?

The question deserves a nuanced answer. JSON-LD offers undeniable technical advantages: separation of markup and HTML content, easier maintenance, the ability to dynamically inject structured data via JavaScript without affecting the visible DOM.

However, Microdata remains fully functional and can even be simpler in certain contexts. For an existing site already marked up in Microdata with active rich snippets, migrating to JSON-LD brings no measurable SEO gain. The energy would be better spent elsewhere. [To be verified]: no public data demonstrates a ranking or display advantage for JSON-LD versus Microdata at equal markup quality.

What risks are there in implementing unofficially mentioned types?

The main risk is not technical but strategic. If Google indeed reads a type of structured data without officially guaranteeing it, they can change this behavior without warning. Your rich snippet displayed today could disappear tomorrow without Google considering it a bug.

What does this mean in practice? Stick to the official Search Central documentation. Avoid exotic types or undocumented properties, even if tests show they work sporadically. Long-term stability matters more than a temporary rich display on a marginal type.

What types of structured data should be prioritized in JSON-LD?

Start with types that match your actual content and generate measurable user impact. For an e-commerce site: Product with price, availability, aggregateRating. For a blog: Article with headline, datePublished, author. For a local site: LocalBusiness with address, hours, reviews.

FAQs and HowTos deserve special attention. These types generate rich displays that take up significant SERP space, pushing competing results down. Their implementation remains simple, and their visual impact is immediate. However, be cautious: Google can remove these rich snippets if the content does not meet its quality guidelines.

How can you verify that your JSON-LD is working correctly?

Google's Rich Results Test tool is the first step in validation. It detects syntax errors, missing required properties, and previews the potential rendering. However, it does not guarantee actual display in the SERPs – Google reserves the right not to display a rich snippet even if it's technically valid.

The Search Console provides a dedicated report on enhancements listing errors and warnings on your indexed structured data. Check this report weekly for regressions. A JSON-LD error introduced during an update could break rich display on thousands of pages without any visible alert signal.

Should you duplicate structured data in multiple formats?

No. Google explicitly recommends using only one format per page. Mixing JSON-LD and Microdata for the same type of content creates confusion and can generate parsing errors. If you migrate from Microdata to JSON-LD, remove the old markup once the new one is in place and validated.

Some CMS or plugins automatically generate structured data. Ensure they do not conflict with your custom markup. I've seen sites with three different Product implementations on the same page – one from the theme, one from a plugin, one added manually – generating blatant inconsistencies in the Search Console.

• Audit the types of structured data already present on your site and their current format
• Prioritize types with visible SERP impact: Product, Recipe, FAQ, Article, Review based on your content
• Validate each implementation with Google’s testing tool before deployment
• Monitor the Improvement report in Search Console after each modification
• Document your implementation choices to facilitate future maintenance
• Test actual SERP display after indexing, not just in the validation tool