Schema Markup for AI Search After FAQ Rich Results Die

A zero crossing is the moment a signal flips from positive to negative. Nothing dramatic happens at the crossing itself, but everything after it is a different sign than everything before. That’s about where search is right now, and FAQ rich results are the tell.

On May 7, 2026, Google stopped showing FAQ rich results in search. There was no blog post and no goodbye. The notice just showed up in the structured data docs one Thursday, and the little accordion snippets a lot of us spent years marking up quietly disappeared from the results page. By June the reporting drops out of Search Console. By August the API stops admitting they ever existed.

If you built FAQ schema to grab real estate in the blue links, yeah, this one stings. HowTo already went the same way, restricted to a handful of government and health sites back in 2023 and now basically dead for everyone else.

Here’s the part I keep having to talk people down from: the right move is not to rip out your FAQPage markup. Structured data just changed jobs, and almost nobody updated the job description.

The reward moved. The work didn’t.

For about fifteen years, the deal with schema was transactional. You added markup, Google handed you a rich result (stars, a recipe card, a price, an FAQ accordion), and that little bit of visual candy earned you clicks. Structured data was basically a bribe you paid the SERP in exchange for pixels.

That deal is falling apart, and not just for FAQs. The whole rich-result economy is getting eaten by a different consumer of your markup: the language model now sitting between the user and your page.

When somebody asks ChatGPT “what’s the best way to waterproof a basement,” or types a question into Google’s AI Mode, there’s no blue link to decorate. There’s an answer, stitched together from sources, with a few citations hanging off the side. Your goal stopped being be the result. It’s be the source the answer gets built from. And the machinery deciding which sources get pulled into that answer reads your page nothing like a human does, and honestly not much like classic Googlebot did either.

That’s the whole reframe. Rich results were structured data for humans looking at a search page. In 2026, structured data is ground truth for a model that’s trying very hard not to be wrong.

What Google actually says (and why it isn’t a contradiction)

Let’s kill the myth first, because it holds up everything else.

Structured data is not a ranking factor. John Mueller said it flat out again in 2025, “structured data won’t make your site rank better,” which lines up with a position Google has held since at least 2018: “there’s no generic ranking boost for SD usage.” Adding schema does not push you up the results. Full stop.

So why bother, if the rich results are dying and it won’t help you rank?

Because ranking was never the point of schema in the first place. What structured data does, in Google’s own words, is make your content eligible for features, make your entities easier to understand, and cut down the ambiguity a machine has to work through when it parses your page. Mueller’s line is that structured data is the directions to the party, not the invitation. It won’t get you through the door. But once you’re invited, it’s the difference between the model walking straight up to your front door and the model wandering the block guessing which house is yours.

That “understanding” job used to be a nice-to-have. In an answer-engine world it’s the entire game. Microsoft has been blunter about this than Google, actually. Bing’s product team has said outright that schema helps their LLMs understand content for Copilot. The mechanism is the same everywhere: models ground their answers in retrieved passages, and they’d rather use passages they can read without guessing.

So here’s the honest version, the one I’d put on a slide. Structured data does not cause AI citations. It removes the reasons a model has not to cite you. When an engine can verify, without squinting, who published a page, who wrote it, what entity it’s about, what the price is, and which other sources agree, you become the low-risk thing to quote. Models are like nervous interns. They quote the source they’re most sure won’t get them yelled at.

The schema types that still earn their keep

Not all markup is equal now. The types that mattered for rich results and the types that matter for AI grounding overlap, but the weight has shifted hard toward anything that nails down identity, authority, and verifiable facts. Here’s where I’d spend the time.

Organization is the foundation, and it’s the one most sites do worst. This is where you tell every engine, no ambiguity, who you are: legal name, logo, URL, and critically your sameAs links to the profiles that back up your existence (LinkedIn, Wikidata, Crunchbase, a Wikipedia entry if you’re lucky enough to have one). This is the entity-graph play, and it’s the most underused piece of markup on the web. More on it in a second.

Article and NewsArticle attach the metadata answer engines lean on to decide whether a page is trustworthy and current: a clear headline, a named author, a publish date, a modified date. Models favor recent, well-attributed content because recency and attribution are cheap proxies for reliability. If your best content has no author entity and no dates, you’re asking a model to trust an anonymous, undated page over a competitor’s bylined one. It won’t.

Product and Offer now get consumed directly by AI shopping agents and Google’s AI Mode. Price, currency, availability, SKU. When a model is assembling a “best X under $200” answer, structured product data is the difference between showing up with an accurate price and getting skipped because your price lived inside a JavaScript widget the crawler never rendered.

Review and AggregateRating hand engines quantified sentiment, a number they can compare across sources without parsing prose. Mark it up honestly (we’ll get to the honesty part) and it becomes comparison fuel.

LocalBusiness is table stakes for anything tied to a place, and it has to match your Google Business Profile exactly. Name, address, phone, hours. Mismatches between your schema and your other listings are precisely the kind of ambiguity that makes a model drop you.

BreadcrumbList quietly tells engines about your site structure and how your topics relate, which helps them understand where a page sits in the bigger picture.

Notice what isn’t at the top of that list: FAQPage and HowTo. Which brings us back to the question you’re probably still holding.

So should you keep the FAQ schema?

Yes. Keep it. Just stop expecting the SERP to pay you for it.

Google itself confirmed that leaving FAQ markup in place won’t cause search problems, because unused structured data doesn’t hurt you, and FAQPage is still a valid Schema.org type. The rich result is gone, but the markup still does the thing that matters more now: it hands a model a clean, pre-parsed set of question-and-answer pairs. A well-formed FAQPage block might be the most extraction-friendly structure you can put on a page, because it maps one-to-one onto the exact shape of a query and its answer. That’s not a rich-result feature anymore. It’s a gift to the retrieval layer.

The shift is all in your head, honestly. You’re not marking up FAQs to win an accordion. You’re marking them up because a question with a crisp, self-contained answer is exactly what an answer engine is shopping for.

The entity graph is where the leverage actually is

If you do one thing after reading this, make it sameAs.

Answer engines don’t think in pages. They think in entities (people, organizations, products, places) and the relationships between them. The reason a model will confidently cite one brand and ignore another one making the identical claim usually comes down to whether it can resolve the entity, meaning connect “the company on this page” to a stable, corroborated node in its picture of the world.

sameAs is how you draw those connections on purpose. Here’s a real Organization block that does it:

json

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Zero Crossing",
  "url": "https://writeandzeros.com",
  "logo": "https://writeandzeros.com/logo.png",
  "description": "Web development and search visibility for the AI era.",
  "sameAs": [
    "https://www.linkedin.com/company/writeandzeros",
    "https://twitter.com/writeandzeros",
    "https://www.crunchbase.com/organization/writeandzeros",
    "https://www.wikidata.org/wiki/Q000000"
  ]
}
</script>

Every URL in that array is a witness. You’re telling the engine that this entity is the same one LinkedIn, Crunchbase, and Wikidata already know about. Each corroborating link drops the model’s uncertainty a little, and lower uncertainty is what gets you quoted. A brand with a dense, verifiable entity graph is a safe citation. A brand that exists only on its own website is a coin flip.

Do the same thing for authors. An Article whose author is a real Person entity, with a sameAs pointing to their LinkedIn or their body of work, is far better grounded than a byline that’s just a string of text:

json

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Schema Markup for AI Search After FAQ Rich Results Die",
  "datePublished": "2026-07-23",
  "dateModified": "2026-07-23",
  "author": {
    "@type": "Person",
    "name": "Doug [Last Name]",
    "url": "https://writeandzeros.com/about",
    "sameAs": ["https://www.linkedin.com/in/yourprofile"]
  },
  "publisher": {
    "@type": "Organization",
    "name": "Zero Crossing",
    "logo": {
      "@type": "ImageObject",
      "url": "https://writeandzeros.com/logo.png"
    }
  },
  "mainEntityOfPage": "https://writeandzeros.com/schema-for-ai"
}
</script>

That’s the gap between “some page said this” and “a named expert, tied to a verifiable track record, published this on a dated, attributed page.” Only one of those is a citation a model feels safe making.

Schema and chunking are the same project

Here’s the piece most schema guides skip: your structured data and your content structure have to agree, because they’re describing the same thing to the same reader.

Answer engines rarely grab a whole page. They grab passages, often 100 to 300 words, and they want each one to be a complete, standalone thought. That has real consequences for how you write, and your schema should mirror your prose instead of fighting it.

Three rules pull most of the weight here.

Write answer-first. Lead each section with the direct answer, then support it. A model pulling a 200-word passage should get the payload in the first two sentences, not after four paragraphs of you clearing your throat. If your FAQPage acceptedAnswer text and your on-page answer say the same thing the same crisp way, you’ve reinforced the signal twice.

Kill the pronoun penalty. Retrieval rips a passage out of context, so a sentence like “The company’s revenue grew 3% last quarter” is useless on its own. Which company? Which quarter? Repeat the entity names instead of leaning on “it,” “they,” and “this.” Your schema already names the entity out loud, so your prose should too, and then the extracted chunk carries its own context wherever it lands.

Chunk by meaning, not by machine. Use H2s and H3s to break content into modules where each section is one complete idea that stands on its own. This isn’t readability theater. It maps your page to the exact unit an engine retrieves, and it lets your headings and your BreadcrumbList tell a consistent story about what lives where.

When your markup, your headings, and your sentences all describe the same entities and facts the same way, you’ve stripped out the ambiguity that makes a model hedge. That consistency is the real optimization, not any single tag.

The ways people get this wrong

A few failure modes worth calling out, because they’re common and they backfire.

Marking up things that aren’t on the page. Schema has to describe visible content. Invent an aggregate rating, stuff in FAQs no human ever sees, claim a price that contradicts your product page, and you’re not gaming anything. You’re feeding the engine a contradiction, and contradictions are exactly what make a source look untrustworthy. Fastest way to not get cited is to get caught being wrong.

Chasing dead rich results. If your schema strategy is still a checklist of “which SERP features can I unlock,” you’re optimizing for a surface that keeps shrinking. FAQ and HowTo are gone. Others will follow. Optimize for grounding instead, and rich results become a nice side effect rather than the whole point.

Fake or bought reviews in Review markup. Past the obvious policy risk, it poisons the exact signal (quantified, trustworthy sentiment) you wanted the markup to send in the first place.

Orphaned entities. An Organization block with no sameAs. An author who’s just a text string. A LocalBusiness whose name, address, and phone don’t match your Google Business Profile. Every one of those is an unresolved entity, and unresolved entities are uncited entities.

A 20-minute audit you can run today

Pull up your most important page and check, in this order.

Does it have an Organization block (or Person, if it’s a personal site) with a populated sameAs array pointing to at least three corroborating profiles? If not, that’s your highest-leverage fix, no contest.

Does your main content carry Article markup with a named author entity, a datePublished, and a dateModified that’s actually current? Undated, anonymous content is the easiest thing in the world for a model to skip.

For commercial pages, is your Product and Offer data present, with an accurate current price and availability, and does it match what a human sees on the page?

Are your headings breaking the page into standalone, answer-first sections, with entity names repeated instead of pronouns?

Run the whole thing through Schema.org’s validator and Google’s Rich Results Test. Fix every error and warning, not because you’re chasing a rich result, but because a validation error is literally the machine telling you it couldn’t read your claim.

And keep your FAQPage markup. Just move it, in your head, out of the “rich results” column and into the “extraction-friendly ground truth” column, where it lives now.

The bottom line

The death of FAQ rich results isn’t really a story about one deprecated feature. It’s the clearest sign yet that the audience for your structured data changed underneath you. For years you marked up pages to earn decorations on a search results screen. Now you’re marking them up to be the source a model trusts enough to quote when there’s no search results screen at all.

Structured data won’t rank you. Google’s been consistent, and correct, about that for years. What it does is quietly, unglamorously strip out every reason a machine has to be unsure about who you are, what you’re claiming, and whether it can afford to put your name next to an answer. On an internet more and more run by models that would rather stay quiet than be wrong, being the source there’s no doubt about is the entire ballgame.

The accordion’s gone. The markup underneath it just got a promotion.