Every few months someone declares schema markup dead, and every few months answer engines get better at using it. Both things are true at once, because schema was never a ranking factor and was never meant to be one. It is a machine-readable description of what a page contains and which real-world things that page is about, and that job matters more now than it did when the only consumer was a rich snippet.
The confusion is worth clearing up before you spend a sprint on it. Schema will not make a thin page rank. It will not persuade ChatGPT to cite you over a stronger source. What it does is remove ambiguity - about what the page is, when it was updated, who wrote it, and which of the six companies sharing your brand name you happen to be. In a retrieval pipeline, ambiguity is expensive, and reducing it is cheap.
What schema actually does for LLMs
Answer engines do not read your JSON-LD and treat it as ground truth. Assume every claim in your markup is cross-checked against the visible page, and assume conflicts are resolved against you. What schema provides is structure: a parseable statement of type, relationships, and identifiers that survives the messy process of converting a rendered web page into something a model can index and chunk.
Three concrete benefits hold up in practice.
First, type resolution. A page marked as Product with an offers block and an aggregateRating is unambiguously a product page. Without markup, a retrieval system has to infer that from layout heuristics that break on unusual templates.
Second, entity disambiguation. This is the one most teams undervalue. Your Organization node with a stable @id, a sameAs array pointing at your Wikidata entry, LinkedIn company page, Crunchbase profile, and GitHub org, tells a model that these scattered references are one entity. That is how you stop being conflated with a similarly named company in another industry.
Third, metadata that is otherwise guessed. datePublished and dateModified in markup are far more reliable than a model parsing "Updated last Tuesday" out of a byline. Freshness matters to answer engines, and giving them an explicit machine-readable date is one of the cheapest signals you can send.
What schema does not do: it does not create authority, does not substitute for being cited elsewhere, and does not compensate for a page that answers the question worse than the alternatives. If you are choosing between fixing your content and fixing your markup, fix the content. Then fix the markup, because it takes an afternoon.
The types that matter, and why
You do not need thirty schema types. Most sites need six or seven, implemented properly and kept consistent.
Article and BlogPosting
The workhorse for any content site. Mark up headline, datePublished, dateModified, author (as a Person node, not a bare string), and publisher. The author node is doing real work here - an author with a sameAs pointing to their LinkedIn and a personal site is a resolvable entity, and expertise signals attach to entities, not to text strings.
Use BlogPosting for posts and Article for everything else editorial. The distinction rarely changes outcomes, so pick one convention and apply it consistently rather than debating it.
FAQPage
The most misunderstood type on this list. Google pulled most FAQ rich results from search, and a lot of teams concluded FAQPage was worthless. It is not, because rich results are no longer the only consumer.
FAQPage gives an answer engine an explicit question-answer pair with clean boundaries - which is precisely the unit a retrieval system wants to chunk and quote. If you write genuine questions your audience asks and answer each one in two to four sentences, you have produced content in the exact shape that gets extracted. The markup makes that shape legible.
The rule is simple: only mark up FAQs that appear visibly on the page and that a real user would actually ask. FAQPage stuffed with keyword-shaped fake questions is worse than no markup, because it teaches every consumer of your data that your markup is unreliable.
HowTo
Use it when the page genuinely describes a sequence of steps producing an outcome. Each HowToStep with a name and text gives a model a pre-segmented procedure. Do not use it for listicles that happen to be numbered.
Product
Non-negotiable for anything with a price. offers with price, priceCurrency, and availability, plus aggregateRating and review where you have real reviews. Comparison and recommendation queries are a large share of high-intent AI search, and a model assembling a shortlist benefits enormously from structured price and availability data it does not have to scrape out of a rendered widget.
Organization and WebSite
These two are your identity layer and belong on every page, usually in a single sitewide block. Organization carries name, url, logo, description, foundingDate, founder, and - most importantly - sameAs. WebSite carries name, url, and a publisher reference back to the Organization node.
Give both a stable @id (a canonical URL with a fragment, such as the homepage plus #organization) and reference that same @id from every Article publisher field on the site. That is what turns a pile of independent page-level blocks into a connected graph rather than hundreds of disconnected assertions.
BreadcrumbList
Cheap, boring, and useful. It tells a consumer where a page sits in your site's hierarchy, which helps a model understand topical scope - that this page is a subtopic of a category, not a standalone document.
The sameAs and entity graph
If you do one thing from this article, do this. sameAs is a list of URLs that refer to the same entity. For an organization: Wikidata, Wikipedia if you have an entry, LinkedIn, Crunchbase, X, GitHub, YouTube. For a person: LinkedIn, personal site, published author pages, speaker profiles.
Answer engines are constantly resolving "which thing is this" against knowledge bases. sameAs is you answering that question directly instead of hoping the resolution goes your way. It costs nothing and it is the single highest-leverage line in most schema implementations.
The mistakes that break it
Invalid JSON-LD. A trailing comma or an unescaped quote makes the entire block unparseable. It fails silently - no error in your CMS, nothing in the rendered page. Whole blocks get dropped this way and nobody notices for a year.
Marked-up content that is not on the page. FAQs in the JSON-LD that do not appear in the HTML, ratings for reviews that do not exist, prices that differ from the visible price. This is the fastest way to have your markup discounted entirely, and increasingly it gets the whole domain treated as low-trust structured data.
Duplicate and conflicting blocks. A plugin emits one Organization block, your theme emits another with a different logo, and a tag manager script adds a third. Now three contradictory statements about your identity ship on every page. Audit what your stack actually renders, not what you think it renders.
Orphan Organization data. An Organization block with a name and a logo and nothing else - no sameAs, no @id, no reference from anywhere. It technically validates and it disambiguates nothing.
Markup that drifts from reality. Prices change, authors leave, products get discontinued. Schema generated once at launch and never revisited becomes actively misleading. Treat it as data with an owner, not as a one-time task.
Rendering schema only in client-side JavaScript. Some crawlers execute JS and some do not. Server-render your JSON-LD if you have any choice about it.
How to validate
Three passes, in order.
- Syntax. Run every template through Schema.org's own validator. It is stricter than Google's tool and will catch type errors and misused properties that the rich-results tester ignores because they do not affect a Google feature.
- Eligibility. Google's Rich Results Test tells you what Google can actually use. Useful, but do not treat it as the definition of correct - plenty of valid, useful markup produces no rich result.
- Reality. Fetch the live page as a bot would, with JavaScript disabled, and confirm the block is present, singular, and matches the visible content. This is the pass most teams skip and where most real bugs live.
Do this at the template level, not page by page. Validate one product page, one blog post, one category page, and one homepage - if the templates are right, the site is right. Our free SEO audit runs the syntax and consistency checks across a crawl and returns a Fix Pack, and the Schema Generator takes a sitemap or a URL list and produces validated JSON-LD for up to ten pages per run, which is usually enough to cover every distinct template on a site.
For spot checks during development, our free Chrome extensions surface the structured data on whatever page you are looking at without a round trip to a validator.
A rollout order that works
Do these in sequence. Each step is small and the order is deliberate - identity first, because everything else references it.
- Sitewide Organization and WebSite with a stable
@idand a completesameAsarray. One block, server-rendered, on every page. Half a day. - Author Person nodes for everyone who publishes, each with
sameAs. Reference them from Article markup rather than repeating strings. - Article or BlogPosting on every editorial template, with accurate
dateModifiedwired to your CMS rather than hardcoded. - Product on every commercial template, with
offersfed from live inventory data. - BreadcrumbList sitewide, usually a single template change.
- FAQPage on pages that already have real FAQs. If a page has no FAQ section, that is a content decision, not a markup one - decide whether the questions belong there before adding markup.
- HowTo on genuine procedural content only.
- Audit for duplicates and conflicts once everything is live, then set a quarterly recheck.
Then measure. Schema improvements show up as better entity resolution and steadier citation behavior, not as a traffic spike the following Tuesday. The AI Visibility Grader is a reasonable way to establish a before-and-after baseline across engines rather than guessing from anecdotes.
The honest position
Schema is hygiene. It is the plumbing that makes your content legible to machines, and like plumbing, doing it well earns you nothing visible while doing it badly causes problems that are hard to trace. It belongs in the same category as canonical tags, clean sitemaps, and fast server responses: necessary, unglamorous, and no substitute for having something worth citing.
Ship it because ambiguity is expensive and removing it takes an afternoon. Do not ship it expecting it to rescue a page that does not deserve to be cited.
Frequently asked questions
Does schema markup help AI search?
Yes, but indirectly. It does not act as a ranking signal for answer engines. It makes your page's type, dates, authorship, and entity identity machine-readable, which reduces the guesswork in retrieval and lowers the chance you are confused with another entity. The benefit shows up as more reliable and correctly attributed citations, not as a ranking boost.
Is FAQPage schema still worth adding now that Google removed the rich result?
Yes, for a different reason than before. Rich results are no longer the only consumer of structured data - answer engines use explicit question-answer pairs as clean extraction units. Only mark up questions that appear visibly on the page and that real users actually ask, and keep the answers short enough to quote.
What is the single most important schema property for AI visibility?
sameAs on your Organization and author Person nodes. It links your entity to external identifiers such as Wikidata, LinkedIn, and Crunchbase, which is how retrieval systems confirm which real-world thing your site refers to. It takes minutes to add and resolves the ambiguity that causes misattribution.
Can bad schema hurt my site?
It can. Markup describing content that is not on the page - invented FAQs, ratings without reviews, prices that do not match - gets your structured data discounted, and repeated offenses can devalue markup across the whole domain. Conflicting duplicate blocks from plugins and themes cause similar damage more quietly, so audit what your stack actually renders.