Google deleted the FAQ rich result documentation, and we still score FAQPage

What Google's changelog actually records about the FAQ rich result

Two entries carry the whole story and they say different things, so it is worth separating them. The first is dated 8 May 2026 and titled Deprecating the FAQ rich result feature. It records that a deprecation notice was added to the FAQ rich result documentation, and gives the reason in one sentence: this feature will no longer appear in Google Search starting May 7, 2026.

Read the two dates in that entry in order. The changelog entry is dated the day after the change it describes took effect, so the notice arrived on documentation for a result Search had already stopped drawing. It is a small thing to notice and a useful reminder that a vendor page is a record of a decision rather than a live view of a system.

The second entry is dated 15 June 2026 and titled Removing documentation for the FAQ rich result feature. It records that the documentation for the feature was removed, and gives as its reason that the FAQ rich result feature is no longer shown in Google Search results, as announced in the changelog entry in May 2026.

Removed turns out to be literal. Requested on 5 August 2026, the FAQ documentation URL under developers.google.com answers HTTP 301 with a location header pointing at /search/updates#removing-faq-rich-result, which is the June entry itself. The page did not become a stub explaining the retirement, and it does not redirect to a replacement page. It redirects to the sentence announcing its own deletion. Anyone holding a bookmark to the implementation reference now lands on a changelog and has to find the line.

The other place the feature used to be listed is Google's structured data feature gallery, which read on 5 August 2026 carries Last updated 2026-06-15 UTC, the same day as the removal entry. Its feature list runs from Article and Breadcrumb at the top through to Vacation rental and Video at the end, and there is no FAQ row anywhere in it. Discussion forum, Education Q&A and Q&A are all still present, which matters for the next section.

One string survived the edit. The word FAQs appears exactly once in that page's HTML, inside a summary sentence listing the features the gallery covers, and that sentence sits inside a template element rather than in the rendered document. It is a minor inconsistency and also a familiar shape, because text inside a template element reaches the browser and not the extractor. A machine reading that page to learn what Google supports gets one answer from the visible table and a different one from the template subtree, and which answer it gets depends entirely on how it parses.

A rich result is a rendering decision, a schema type is vocabulary

Nothing in either entry says the markup is invalid, and nothing in them says Google ignores it. They say the rich result is no longer shown. That is a statement about what Search draws on a results page, and it is the only statement being made. Reading it as a verdict on the vocabulary is an inference, and the vocabulary is somewhere else entirely.

schema.org still defines FAQPage. Read on 5 August 2026 the type page describes it as a WebPage presenting one or more frequently asked questions, places it in the hierarchy under Thing, CreativeWork and WebPage, and carries no deprecation notice. It also carries a usage figure from Google's own monthly web index aggregation, dated July 2026, putting FAQPage in the 1 million to 10 million domain band. That band was already the interesting part of the vocabulary the last time this site counted it, when reading the published dataset showed only sixteen schema.org types reaching the top band of more than ten million domains. FAQPage sits one bucket below that, which is a large installed base for a feature whose rendering has just been withdrawn.

The clearest evidence that Google has not turned against question and answer markup in general is in the same changelog, three months earlier. The entry dated 24 March 2026 records new supported properties added for Discussion Forum and QA Page markup, and gives its reason as providing more clarity on comment thread structure to Google ingestion systems, to prevent misinterpretations in the handling of forum and Q&A content. The Q&A page documentation is live, carrying Last updated 2026-06-15 UTC on the day this was read.

So one presentation of one type was retired while a neighbouring type was expanded in the same quarter. The two types describe different things, and the difference is in the schema.org definitions rather than in anything Google has said about motive. FAQPage is a page presenting questions the author both asked and answered. QAPage, which its definition points at directly, is a page carrying one question followed by its answers. Google has published no reason for retiring the one and expanding the other, so the honest reading stops at the observation: the change was to a rich result, and it was not applied to question and answer markup as a category.

The practical consequence is that the word ingestion in the March entry is doing more work than the words rich result in the May one. Structured data has always had two audiences: the layer that decides what to draw, and the layer that decides what a page is about. Only the first of those has published a decision here. That gap is exactly where answer engine optimisation advice tends to go wrong, and it is worth remembering that Google's own guidance for its generative surfaces is unusually blunt about this: its guide already names five tactics you can ignore, structured data among them. A site owner who adds FAQPage expecting an AI citation has been told by the vendor not to expect one, and a site owner who strips it out expecting a penalty to lift has been told nothing of the kind.

What Lantad's schema check does with FAQPage, and why it did not change

Lantad's composite score is weighted in core/src/config.ts, where SCORE_WEIGHTS gives parity 0.5, access 0.25, structure 0.15 and schema 0.1. Those four numbers sum to one and a test asserts that they do. Every one of them is a setting somebody chose, so schema being a tenth of the score is a position this product takes, not something measured about the web, and the same caution applies to everything else in this section.

The schema sub-score performs three checks and no others. Does the block parse as JSON. Does each entity in it declare an @type. Do the entities carrying a recognised business type also carry that type's required properties. The list of recognised types is data rather than logic, held in SCHEMA_REQUIREMENTS in core/src/schema.ts, and it is short: Organization requires name and url, Product requires name, Article requires headline, BreadcrumbList requires itemListElement, and FAQPage requires mainEntity. A handful of subtypes are checked against a parent, so NewsArticle, BlogPosting, TechArticle and ScholarlyArticle are all measured as Article, and LocalBusiness and Corporation as Organization.

FAQPage is therefore one of five types that can earn a page the recognised label at all, and its requirement is the single property that makes the block mean anything: mainEntity is where the questions live, so a FAQPage without it is an empty declaration. None of that changed in May or in June, and the reason it did not is worth stating rather than assuming. The check does not ask whether Google will draw a box. It asks whether the page makes a claim about itself that a machine can verify against the page. That question has the same answer today as it had in April.

What would change the check is evidence, and we do not have it. We can say what the scanner does and we publish the method rather than a black box. We cannot say that a page carrying FAQPage is more likely to be cited by ChatGPT, Claude or Perplexity, because we have not run that measurement, and a scoring weight is not a substitute for having run it. The discipline here is the same one behind measuring structured data twice, once in the served HTML and once after rendering: report the thing you actually observed, and name the thing you did not.

It would be straightforward, and wrong, to write this up as a finding that FAQPage is worth a tenth of your AI visibility. The weight is a decision. Presenting it as a measurement would be the same error as printing a confident grade for a page that was never fetched, which is the one thing this scanner refuses to do. A number that came out of a config file and a number that came out of a scan look identical on a slide, and only one of them survives being asked where it came from.

This blog emits FAQPage on every post and earns nothing visible for it

The inconvenient half of the subject is on this domain. Every post on this blog ends in a set of common questions, and that block is rendered by one shared component, site/src/components/Faq.astro, which builds a FAQPage object from the same array it renders: mainEntity is the list of questions, each a Question whose acceptedAnswer is an Answer carrying the plain text. Emitting the JSON-LD is the default and a page has to opt out of it deliberately, which exists so that the visible list and the structured data cannot drift apart.

Counted on 5 August 2026, the 46 posts published here before this one carry four questions each, 184 question and answer pairs in total, and every one of those posts emits a FAQPage block. Nineteen page files under site/src/pages import the same component directly, so the markup is not confined to the blog. All of it has been ineligible for the rich result it was originally associated with since 7 May 2026.

We are keeping it, and the honest version of why has three parts and no measured benefit in any of them. The first is that a question followed directly by its answer is the most extractable shape available to anything assembling a response, which is an argument about text rather than about markup, and it would hold if the JSON-LD were deleted tomorrow. The second is that the schema and the visible list come from one array, so the block costs nothing to maintain and cannot become a lie about the page. The third is that readers ask these questions.

What we cannot offer is a figure. There is no measurement on this site showing that the FAQPage block on a Lantad post has ever caused a citation, and if there were, one site's blog would be a sample of one. That is the same standard applied to every other structural signal we describe, including the ones we do score, and it is why the structural signals that tell an AI who you are are written up as mechanisms rather than as guarantees.

There is one thing a page can do that removes the ambiguity, and this site does it: publish the same content in a form that needs no extraction at all. Every public page here has a markdown twin, which is the answer text as text. A consumer that wants the questions can have them without parsing JSON-LD, without rendering, and without depending on anybody's rich result policy. That is a hedge against exactly this kind of change, and it is a cheaper hedge than most generative engine optimisation advice on offer.

What to check on your own site now the rich result is gone

The first decision most people reach for is whether to strip the markup out, and it is the wrong first decision. Removal is work with no documented benefit. Both changelog entries say the feature is no longer shown; neither says the markup is penalised or discouraged, and the vocabulary that defines it has not changed. If you already ship it, shipping it costs nothing further. What is worth removing is the expectation, and any reporting line that still counts FAQ rich result eligibility as a result.

The check that replaces it is about the text rather than the schema. Fetch one page as a plain client and look for the answer text in the bytes that come back. If the questions are injected by script after load, a JS-blind crawler has no questions, and the JSON-LD block describing them is a description of content that client never received. That is the ordinary two-layer problem, because what the server returns and what a browser assembles are two different documents, and on an accordion-based FAQ the gap between them is common enough to be worth checking rather than assuming. The direct way to answer it for a named crawler is to fetch the page as that crawler and read what came back.

Then check that the block and the page agree. The questions in the JSON-LD should be the questions on the page, in the same words, and the answers should be the answers. Google's general structured data guidelines, carrying Last updated 2026-07-10 UTC, are explicit that using structured data enables a feature to be present and does not guarantee it will be present, and they list content referred to by the structured data being hidden from the user among the reasons a page may show nothing. Those guidelines still govern every feature that does have a rich result, so a habit of keeping markup and page in sync remains worth having for reasons that have nothing to do with FAQ.

The wider check is the one this site scores. If your answers exist only inside the JSON-LD and not in the readable body, you have written for a parser rather than for a reader, and that is a prose parity problem before it is a schema problem. Markup that describes content is worth exactly as much as the content it describes; markup that substitutes for content describes nothing.

Finally, calibrate what any of this is for. A retired rich result is a reminder that presentation is the vendor's to withdraw and that a page's substance is not. If the goal is being cited by Google's generative surfaces, the platform guidance for how to get cited in AI Overviews is a better starting point than any single markup type, and if the goal is knowing what a crawler can read at all, that is a question about access and text rather than about vocabulary. FAQPage was never the thing doing the work. It was a label on the thing doing the work, and the label losing its box does not change the work.