What a FAQ checker should test#
A FAQPage checker has three layers. First, parse the JSON-LD and report malformed JSON, duplicate script blocks, and unsupported nesting. Second, verify the semantic shape: an FAQPage with mainEntity Question items and each Question’s acceptedAnswer as an Answer. Third, compare the questions and answers with the visible HTML on the same canonical page. A structurally valid block that describes text users cannot see is not a quality implementation.
Schema.org defines FAQPage for a page containing a list of questions with answers. Schema vocabulary tells consumers what terms mean; it does not establish Google feature eligibility. Google explicitly says its Search documentation, not Schema.org alone, is definitive for Google behavior.
Use visible content as the source of truth#
A reliable checker extracts page headings, question controls, answer text, and hidden-but-user-accessible disclosure content, then matches normalized whitespace and punctuation against the JSON-LD values. Flag a mismatch for human review rather than rewriting markup automatically. Marketing teams often update a visible answer without updating a template’s JSON-LD, leaving contradictory facts on the same URL.
| Check | Pass condition | Evidence to retain |
|---|---|---|
| JSON syntax | script parses | parser result and script location |
| Page type | FAQPage has question entities | extracted JSON-LD node |
| Answer mapping | every Question has acceptedAnswer | property path and value |
| Visibility | same Q&A appears for users | HTML or rendered text excerpt |
| Canonical consistency | markup describes this URL’s content | canonical URL and capture time |
Google’s structured-data introduction says markup must describe the page where it appears and warns against adding structured data for information that is not visible to users.
Validate in two tools, then monitor the deployed page#
Run the Schema Markup Validator to check Schema.org vocabulary and a Google Rich Results Test to check Google-supported rich-result interpretation. The two results answer different questions. A clean Schema.org result does not mean Google supports that type for a feature, and a Google warning does not necessarily make the vocabulary invalid for other consumers.
After deployment, inspect the live canonical URL rather than a staging fragment. Confirm the production response contains the script, the client has not overwritten it, and its values still match visible content. Google recommends validating during development and monitoring after deployment because templates and serving changes can break markup. Store the test URL, date, tool output, and a capture of the page artifact.
Know the FAQ rich-result limit#
Google’s FAQPage guidance says FAQ rich results are available only to well-known, authoritative government-focused or health-focused sites. For most commercial, publisher, and software sites, FAQPage can still be accurate metadata, but a checker must not label it “eligible” for a Google FAQ rich result. It should report validity, visible-content alignment, and the documented scope separately.
Use FAQ content to answer real support questions clearly for readers, not to manufacture near-duplicate landing pages. Consolidate overlapping questions, state scope and exceptions, date answers that change, and remove stale responses. CrawlReady’s schema checker can help review markup, while structured data for AI crawlers explains where structured data helps and where it does not.
Scope and limits. This procedure creates an audit trail, not a promise of crawler access, inclusion, indexing, citations, referral traffic, rankings, or conversions. User-agent text is easy to spoof. Treat the records as observed request artifacts unless the requester is verified by the relevant operator method. Keep the raw event, the verification result, and the interpretation separate so a later reviewer can reproduce the conclusion.
Review checklist for editors and engineers#
- List the questions users actually ask, and remove promotional pseudo-questions.
- Assign a content owner and review date to each answer that contains policy, price, medical, legal, or availability information.
- Confirm the visible page shows the same answer a script emits, including qualifiers and links where they change meaning.
- Test the canonical production URL after cache invalidation; a local component preview is not deployment evidence.
- Treat warnings as review tasks, not an invitation to add empty recommended properties.
When a question has multiple valid answers by region, plan, or date, say so in visible text and model the scope accurately. A checker should surface ambiguity for editorial review rather than flatten it into an absolute answer.
Common checker findings#
The most useful findings are concrete: a trailing comma breaks JSON; a Question lacks acceptedAnswer; the script is present on a category page whose visible content is not a FAQ; an answer was changed in the CMS but the schema cache was not regenerated; or two templates emit conflicting answers. Report the property path, canonical URL, and visible-text comparison so an engineer can fix the source rather than guessing.
Do not treat every optional Schema.org property as a checklist item. Add a property when it is accurate, maintained, and meaningful for the page. Incomplete automation is worse than a smaller truthful model because reviewers and downstream consumers cannot tell which facts to trust.
FAQ#
Does valid FAQPage markup guarantee a Google FAQ rich result?#
No. Google limits FAQ rich results to well-known authoritative government and health sites. Valid markup is not a guarantee of any search feature.
Must FAQ schema match visible questions and answers?#
Yes. The markup should describe the content on the page. A checker should flag questions or answers that do not match visible user-facing content.
Which validator should I use?#
Use Schema Markup Validator for Schema.org vocabulary and Google’s Rich Results Test for Google feature interpretation. They test different things.