The short version
- For Google, structured data has a documented, observable payoff: eligibility for rich results. That is published and verifiable.
- For AI assistants, the payoff is plausible but unconfirmed. Valid markup makes facts unambiguous, which should help any system parsing your page.
- Implement it for the documented reason. Treat any AI benefit as an unpriced bonus rather than the justification.
- Errors in required fields can block a supported rich result. Warnings and errors differ; validation is necessary but does not establish display or ranking.
Structured data is having a second moment. Having been a moderately dull technical task for years, it is now widely presented as a key lever for AI visibility. The underlying idea is sound (machine-readable facts are easier for machines to use) but the evidence base for the two audiences is very different, and it is worth being precise about which claim rests on what.
What is documented versus inferred
The framing: implement structured data because the Google benefit is documented and testable. If it also helps assistants, which is likely, you get that for free. Reversing the justification (implementing it primarily for AI and citing unpublished mechanisms) is how teams end up with elaborate markup that serves no measurable purpose.
Which types are actually worth implementing
The first row is the most underrated. Organization markup on your homepage is where you state, in machine-readable form, what your company is called, what it does and where to find it. For anything trying to understand your entity (search engine or assistant) that is the canonical statement, and a surprising number of sites either omit it or fill it with marketing language.
The step everyone skips
An error in a required field can prevent that item from qualifying for a supported rich result. A warning about an optional field is different, and other valid items may still be usable. Plugins and templates can introduce errors after an update, so inspect the reported issue rather than assuming all markup is ignored.
- Test key page types in the Rich Results Test: one per template, not every page.
- Cross-check in the Schema Markup Validator, which checks the vocabulary rather than Google’s specific requirements.
- Watch the enhancement reports in Search Console for errors appearing at scale.
- Re-test after any template or plugin change. That is when markup breaks.
- Make sure the markup matches the visible page. Describing content that is not there is a policy violation, not a clever trick.
Rich result eligibility also changes over time. Google has added and withdrawn support for particular result types more than once, which means markup implemented for a specific visual outcome may stop producing it without anything on your side changing. That is another argument for implementing the well-established types properly rather than chasing whichever enhancement is currently being demonstrated: the fundamentals have been stable for years.
FAQ markup on pages with no FAQ
A recurring pattern: bolting FAQ markup onto pages to try to occupy more space in results, with questions nobody asked and answers that add nothing. This misrepresents the page, which is a policy problem, and it produces the kind of thin question-shaped content that performs badly with both audiences. Use it where you have genuine questions and answers, which is a real and common case: just not a universal one.