FAQ, process and changing features
FAQ and HowTo Markup: Keep Useful Answers, Retire Old Search Promises
Preserve questions and instructions that help readers while checking their markup and current consumers separately. A retired Google feature does not erase useful content or the Schema.org vocabulary.
Free learning from Semantec SEO.
Start with a real answer or an achievable process.
A useful FAQ presents questions the page can answer accurately. A useful process explains a bounded task, prerequisites, ordered actions and a completion check. Neither format needs a search enhancement to justify its place on the page.
Keep the answer available to the reader, with the conditions that affect its meaning. Do not create invisible questions or hidden steps solely for markup. An accordion may be a reasonable reading format when people can open it; unavailable content is different from content deliberately organized for access.
For instructions, identify necessary tools or supplies, access requirements, risks and what to do when a step cannot be completed. Do not invent a duration, cost or successful result to fill a property. An explanation of a concept is not automatically a sequence of instructions.
Choose vocabulary for the visible content model.
FAQPage remains a Schema.org page type for frequently asked questions. A publisher-controlled FAQ with its accepted answers differs from a discussion in which users submit answers to one question; examine QAPage when that second model genuinely applies.
HowTo describes instructions for achieving a result through steps. Its vocabulary can express tools, supplies and time where those facts exist. Do not infer that every available property is required, appropriate or supported by Google.
Vocabulary meaning, encoded syntax and platform feature support are separate checks. Retaining accurate FAQPage or HowTo for another documented consumer can be reasonable. Keeping a false promise of a Google enhancement is not justified by generic vocabulary validation.
Use the current platform record, not an old eligibility rule.
Current status checked on 23 October 2026: Google’s supported structured data gallery does not list FAQ or HowTo rich-result features. Do not present either as an available Google rich-result target.
The official Google documentation update log records that FAQ rich results stopped appearing from 7 May 2026, with the announcement entered on 8 May and the documentation removed on 15 June. The older government-and-health eligibility restriction is historical, not a current exception that restores the retired feature.
Google’s HowTo and FAQ change announcement, updated in September 2023, records the end of HowTo rich results on desktop from 13 September 2023 after the earlier mobile change. Do not repeat its original desktop-only wording as the current state.
A historical source can explain when a feature changed, but its old requirements must not be copied into a present-day sales claim. Record the date checked and recheck official guidance when maintaining a changing feature.
Worked reassessment: a legacy FAQ and process page.
Consider a fictional support resource titled “Prepare a source record”. Its old proposal says that adding FAQPage and HowTo will guarantee expanded Google results. The visible page contains two useful questions and a three-step procedure. This is a teaching scenario, not a test of a real live page.
The questions are “What should a source record identify?” and “What if the publication date is missing?” The first answer asks for source identity, address and the passage supporting the claim. The second says to record the missing date and check applicability rather than invent one. Those answers remain useful after feature retirement.
The procedure requires access to the source and a place to save the record: first identify the source and relevant passage; next record available publication/version information and access date; then compare the exact claim with its conditions and mark unresolved evidence for review. Completion means a traceable record with unknowns visible, not an automatic approval.
Now compare the old promise with the gallery and change records. Neither FAQ nor HowTo supplies a current Google rich-result opportunity. Delete the guarantee, keep the useful visible answers and ordered procedure, and inspect any existing markup for correspondence with that content.
If an identified non-Google consumer or internal data use still needs accurate vocabulary, retain a documented semantic description with an owner. If no purpose remains, removal can reduce unnecessary maintenance. Do not relabel the FAQ as QAPage or the procedure as Recipe to pursue another unsupported appearance.
| Legacy element | Evidence check | Decision |
|---|---|---|
| Two visible FAQ answers | Relevant, bounded answers available to readers | Keep useful copy; correct any unsupported statements |
| Three ordered process steps | Prerequisite and completion condition supplied | Keep procedure independently of search features |
| Guaranteed expanded Google result | Conflicts with current gallery and retirement records | Remove claim from page, reports and sales templates |
| FAQPage/HowTo vocabulary | Still defined in Schema.org | Assess a real semantic consumer; no feature promise |
| Old government/health exception | Historical FAQ rule superseded by retirement | Do not apply as current eligibility |
| Markup retained or removed | Requires complete visible-content and purpose review | Record owner, reason and later validation |
Check the places where old claims survive.
Inspect visible copy, JSON-LD, plugins, templates, reusable blocks, reports and sales descriptions. Removing one promotional sentence may leave a generated FAQ claim elsewhere. Preserve a before-and-after record and identify which component owns each assertion.
Do not delete the whole support answer because its markup no longer targets a feature. Equally, do not retain unseen or incorrect graph content merely because removal takes work. Separate the content decision, markup decision and unsupported commercial claim.
A change record should name the old claim, current source, affected URLs or templates, chosen action, responsible owner and verification method. Recheck visible content and emitted markup together after a real deployment. Historical test screenshots are not proof of current feature availability.
Use validation without overstating its result.
Test syntax and vocabulary where a description is retained. A generic validator can inspect FAQPage or HowTo even when Google’s rich-result tooling no longer supports the retired feature. Lack of a feature result in that tool is not evidence that useful instructions must be removed.
Check the observed live output, access and reader experience after an authorized change, and preserve the observed result. This lesson has not run a platform test or measured a search outcome. No validation result guarantees indexing, rankings, traffic or display.
Keep an owner and a trigger for revisiting the decision: changed answers, revised process, a different consumer, or a new official platform announcement. A known retirement date should not be hidden behind a rolling automatic “reviewed today” label.
Route the decision by its remaining purpose.
Return to the structured data overview or learning overview. Use vocabulary validity and feature eligibility when a successful syntax test has been mistaken for a search promise.
The controlling outcome is a useful visible answer with accurate description and honest expectations. Record what was kept, corrected, removed or held and why, so the next contributor can maintain the decision.