FAQPage still exists in Schema.org. Google’s FAQ rich result does not. That leaves many websites publishing valid machine-readable FAQ objects whose only recorded business case was a Search feature that has retired. The markup still parses. The visible questions may still help customers. Neither fact proves the structured data still has a job.
My rule is: name the consumer before you fund the code. “Search engines”, “AI”, “machines” and “SEO” are not consumers. A consumer is a named system, feature, partner product or controlled internal process with a documented behaviour somebody can verify. If no one can say who reads the object, what happens when it is read and who notices when that behaviour changes, do not add new FAQ markup. For existing output, do not panic-delete it either. Put it through a bounded dependency check and send any removal through the actual generating-system owner.
TL;DR
- Vocabulary fit and consumption are different claims; a valid object can be unemployed.
- Visible FAQ answers face a reader-value decision; the markup faces a consumer decision. Keep them separate.
- "Helps AI understand the page" is an outcome hope, not a named consumer.
- Check dependencies before removal, and give every retained object an exit condition.
Vocabulary and consumption are different claims
Schema.org defines FAQPage as a page presenting one or more frequently asked questions. That definition gives software a shared vocabulary. It does not promise that a particular search engine, AI assistant, partner or internal application will consume the object or produce an observable result. Google makes the separation clear in its structured-data introduction: Schema.org supplies much of the vocabulary, while Google documents the structured data that has special meaning for its own Search features.
An FAQ implementation therefore contains at least four separate propositions:
Proposition 1
The visible page contains useful questions and answers
Determines whether the public answers deserve to exist at all. A reader-value and accuracy decision.
Proposition 2
FAQPage accurately describes that visible resource
A vocabulary-fit question. The type must match the delivered page, not the page the team wishes it had.
Proposition 3
A named system consumes that exact machine-readable object
The first half of a job for the markup. "Search engines" and "AI" are not names.
Proposition 4
The consumption produces a documented behaviour worth maintaining
The second half of the job. Something observable that somebody notices when it changes.
Old SEO checklists collapse all four into “add FAQ schema”. That was weak governance even when a rich result existed. After the feature disappears, the missing distinctions become impossible to ignore.
The Google rationale has expired
Google’s Search documentation updates record the end of the FAQ rich-result display and the later withdrawal of its dedicated feature documentation (Google Search documentation updates). The exact dated entry should be checked against the live changelog during implementation review because product documentation can change.
That evidence resolves one dependency: a register row naming Google’s FAQ rich result as the active consumer and expanded result as the expected behaviour is obsolete. It does not resolve the visible content. A useful answer about price, eligibility, preparation or service scope does not become worthless because an enhanced search presentation ended. It also does not prove no other system consumes the object. An internal support product, partner feed or maintained integration may still depend on it. The absence of a Google feature is evidence about that Google feature, not universal evidence about every consumer.
This is the post-rich-result split: visible FAQ content faces a reader-value and accuracy decision; FAQ markup faces a consumer, behaviour and maintenance decision. Do not staple them together under a migration ticket saying “delete FAQ SEO”.
“AI visibility” does not fill the empty consumer cell
The easiest way to preserve an obsolete schema service is to rename its hoped-for benefit. Google’s guidance for AI features does not establish FAQPage as a special route into AI Overviews or AI Mode. A different AI product may document a use, but the business must still identify that product, the specific object consumed and the behaviour produced.
“Helps AI understand the page” is too broad to govern an implementation. Does the system import the answers? Use them to populate a controlled interface? Make the page eligible for a documented presentation? Exchange data with another application? Produce a receipt that the team can inspect? If none of those mechanisms can be named, the claim is an outcome hope.
This matters commercially. A web-design or SEO agency can keep billing for hidden output by replacing “rich results” with “AI readiness” while leaving the evidence field empty. The terminology becomes more current; the business case does not. I would rather close an honest schema ticket than sell an invisible dependency nobody can test.
Give the object a job test
Use a Schema Job Test for one versioned object on one defined page or template family.
| Gate | Required question | Suitable evidence |
|---|---|---|
| Consumer | Which named system reads this exact object? | Current documentation, integration specification, contract or observed receipt |
| Behaviour | What documented action or eligibility follows? | Consumer-controlled documentation or reproducible observation |
| Vocabulary | Does FAQPage accurately describe the visible resource? | Delivered page, Schema.org definition and consumer rules |
| Truth source | Do visible and machine-readable answers come from the same controlled facts? | Versioned source and live comparison |
| Ownership | Who owns answer accuracy, output generation and disablement? | Named roles and accepted responsibility |
| Verification | How will meaning, parsing, delivery and consumption be tested separately? | Representative scope and dated checks |
| Exit | Which event ends or reopens the job? | Feature withdrawal, integration change, page retirement or source change |
This is not a score. The first decisive failure controls the result. A truthful object with no consumer does not average into usefulness because its JSON-LD is tidy. A documented consumer does not rescue stale hidden answers. A perfect vocabulary choice does not replace an owner. Use bounded dispositions:
Permission is not implementation. The test decides whether the code deserves work; it does not choose a plugin or approve a deployment.
Valid markup can be unemployed
Consider four evidence sets:
| Situation | Decision |
|---|---|
| Publisher-written FAQs with Google’s retired display as the only named consumer | No current job: omit new markup |
| A plugin emits accurate FAQ markup whose only recorded consumer has retired | Run bounded dependency check, then controlled removal if no other job is found |
| A documented internal support tool imports the object and has a tested freshness process | Keep and continue observation |
| A page contains one community question with user-submitted answers | FAQPage may be the wrong vocabulary; review the actual resource and consumer rules |
The first two examples show why page content and markup must remain separate. Removing a jobless object does not require deleting useful answers. Keeping useful answers does not create a reason to retain jobless markup.
“Schema remains valid” answers a syntax or vocabulary question. It does not answer whether the object is employed.
Hidden answers cannot outlive visible truth
Any retained object must remain within the claim ceiling of the public page. Google’s structured-data policies require markup to represent relevant visible content and separate valid implementation from guaranteed search presentation.
The machine-readable version must not gain a stronger promise, extra location, missing qualification or old price. If the visible answer says availability requires confirmation, the object cannot turn it into unconditional availability. If the visible FAQ is removed, a forgotten plugin field must not continue publishing its answers invisibly. Where possible, generate visible and structured representations from one maintained fact source. If the stack keeps separate copies, the register needs an explicit comparison, named owners and change triggers.
A validator can show that output parses and uses recognised vocabulary. It cannot prove the answer is true, the consumer uses it or the maintenance cost is justified. This is where schema work meets branding. Hidden code is still public representation. If it makes the business appear more available, qualified or comprehensive than the visible page can support, it is not harmless technical decoration.
Not sure which of your plugins is still emitting FAQ markup, or who reads it? We run the dependency check and hand the removal package to the right owner.
Check dependencies before removal
Accurate existing markup is not automatically an emergency. Before removing it, define the search boundary for dependencies. Inspect:
Record the systems checked and observation date. “No exact dependency located in the checked systems” is a defensible bounded finding. “Nothing uses this anywhere” usually is not. If credible dependency evidence remains incomplete, retain a hold with an owner and deadline. If no current job is found, send a removal package to the component owner containing the generating source, affected templates, representative URLs, present output, dependency-check boundary, rollback requirement and live verification request.
I do not panic-delete accurate markup. I also do not renew a dead business case because removal feels like admitting the earlier work has expired.
Do not turn QAPage into a consolation prize
Type substitution must follow the resource and consumer rules, not the desire to keep “question schema” on the invoice. Schema.org defines QAPage broadly around a page focused on a question and answers. Google’s Q&A structured-data guidance has historically applied a narrower Search use case around one question with user-submitted answers. Check current documentation before implementation.
A business-written FAQ containing several questions does not become a community Q&A page because its former rich result retired. A blog article with rhetorical headings does not become an FAQ. A product page containing several customer questions is not automatically one QAPage. Vocabulary describes the resource. It is not a loophole around a feature decision.
Separate four kinds of validation
If the object retains a job, validate each layer independently:
- Meaning: the type and properties accurately describe the visible page.
- Syntax: the delivered code parses under the relevant vocabulary.
- Feature or integration: the named consumer’s current requirements are satisfied.
- Consumption: the expected system behaviour is observed where the system exposes evidence.
A green parser result proves only the second layer. An eligible implementation does not guarantee a display. A visible display does not prove a commercial outcome. An internal import receipt does not prove the public content remains accurate. After release, sample complete, sparse and unusual records. Test empty answers, withdrawn questions, changed prices, unpublished components, translations and pages where the FAQ module is absent. Hidden output often survives in edge cases because the demonstration page contained every field.
Give every schema job an exit
Every retained object should have a named consumer and behaviour, an authoritative fact source, content and technical owners, a representative page-family scope, a validation method, a last observation date, a change trigger, a failure behaviour and a removal or review condition. The exit condition is part of the original implementation, not an admission of failure. Search features retire. Integrations change. Pages disappear. Products move. Plugins are replaced. A useful data object can become unemployed without ever becoming syntactically invalid.
For FAQ schema, the decision is now straightforward. Keep the visible answers if they still resolve a real customer decision. Keep or add the machine-readable object only when a named system performs a documented, maintained job with it. Schema.org supplies the vocabulary. It does not supply the reader.
Good to know
FAQs
Not by reflex. Run a bounded dependency check across documentation, integrations, configuration, logs, owners and release tests. If no named consumer is found, send a removal package to the system owner. If evidence is incomplete, hold with an owner and deadline.
Google’s AI-features guidance does not establish FAQPage as a special route into those products. “Helps AI understand the page” names no system, object or behaviour, so it cannot govern an implementation. It is an outcome hope, not a consumer.
Yes, if they still resolve a real customer decision about price, eligibility, preparation or scope. The visible content and the markup are separate decisions; removing jobless markup never requires deleting useful answers.
Only if the resource genuinely matches. Google has historically applied QAPage to one question with user-submitted answers. A business-written FAQ with several questions does not become a community Q&A page because a rich result retired.
Next step
Is your structured data still employed?
We audit every emitted object against the Schema Job Test, name the consumer or the exit, and route removals through the owner of the generating system.