Free AI SEO Audit
Free AI SEO Audit

FAQ Page Schema Example Guide for Rich Results

Sep 2026

The most popular advice about an FAQ page schema example is already outdated. Adding FAQPage markup to a page no longer guarantees the expandable Google FAQ display many guides still promise. Google stopped showing FAQ rich results globally on May 7, 2026, while the FAQPage type remains valid in Schema.org. Google's update timeline also records the later removal of FAQ Search appearance and Rich Results Test support in June 2026, followed by Search Console API support changes in August 2026. See the Google Search updates timeline for the current transition details.

That doesn't make FAQ schema useless. It changes the job. You're no longer adding structured data mainly to decorate a search result. You're describing a page's question-and-answer content in a machine-readable way, while keeping the same information clear for people, crawlers, and answer systems.

This distinction matters for service businesses. A dental practice might need to explain insurance, appointment preparation, and emergency care. A law firm may need to clarify jurisdiction, consultation logistics, and case intake. A home service company may need to answer service-area, scheduling, and pricing questions. Useful answers can reduce friction even when no Google dropdown appears.

The examples below cover the FAQPage hierarchy, JSON-LD, Microdata, visible-content rules, validation, and service-business question design. You can also review what schema means in SEO if structured data is new to you. The practical standard is simple: use FAQPage when the page presents answered questions, make every marked-up answer visible, and treat the markup as an accurate description rather than a shortcut to a display feature.

Table of Contents

Introduction Why FAQ Schema Still Matters After Rich Results Changed

FAQPage schema remains a valid Schema.org type in 2026, although Google stopped showing FAQ rich results globally on May 7, 2026. These are separate facts: FAQ rich-result visibility has ended on Google, while FAQPage remains a vocabulary for structured understanding. The official FAQPage documentation describes its type and implementation model.

Schema.org defines what information means. Google decides whether to use that information for a search appearance. Other answer systems may interpret the same markup differently, and visitors still benefit when answers are organized clearly on the page.

Practical rule: Keep FAQ content because it helps visitors. Keep FAQPage markup only when it accurately describes the page.

Service businesses should begin with questions people ask before contacting them. A dental practice can answer, “Do you accept my insurance?” A law firm can clarify whether it handles cases in a particular jurisdiction. A home service company can state its service area, scheduling process, or pricing approach. These questions give prospective customers usable facts, unlike broad prompts such as “Why choose our practice?” The answer should identify the business or service clearly and avoid unsupported promises.

The markup is only one layer of the implementation. The page also needs visible HTML, correct nesting, one accepted answer for each Question, and a validation process that catches syntax or content mismatches. A technically valid graph can still describe the wrong page if FAQPage is applied to a service page whose small FAQ section is unrelated to its main purpose.

Use this guide as a working reference. The structural explanation clarifies the vocabulary, while the JSON-LD and Microdata examples show how to choose an implementation format. The content guidance supports better service-business questions, and the workflow covers validation before deployment. For a broader introduction, see this guide to what schema means in SEO.

What FAQPage Schema Is and How It Fits Structured Data

FAQPage identifies a page where the publisher supplies questions and their answers. Its structure starts with a top-level FAQPage object and a mainEntity array. Each array item is a Question, and each Question contains one acceptedAnswer, represented by an Answer object. This relationship follows Google's FAQPage structured data guidance.

A diagram explaining FAQPage Schema structure including mainEntity, Question, Answer, and acceptedAnswer components in a flowchart.

The hierarchy in plain language

The markup works like nested labels:

  • FAQPage identifies the page as a collection of answered FAQs.
  • mainEntity contains the page's primary question entities.
  • Question stores the complete question.
  • acceptedAnswer connects that Question to its answer.
  • Answer stores the response in its text property.

The nesting is the part to verify first. An answer should not appear beside a Question as unrelated data. It belongs inside that Question, and the Question belongs inside mainEntity. For a service business, this structure gives answer engines a clearer map of which response addresses which customer concern.

FAQPage is not QAPage or HowTo

Use FAQPage when the site owner provides the questions and answers. Use QAPage for a page centered on one question where users can submit alternative answers. A community forum with several user responses describes a different interaction from a clinic's page answering common patient questions.

HowTo describes ordered instructions for completing a task. “How do I prepare for a consultation?” may work as an FAQ when the answer is brief and direct. A detailed, step-by-step procedure may fit HowTo more accurately. Select the type that matches the page's purpose and visible content.

FAQPage is one layer in technical SEO. Search engines still need to crawl and render the URL, index its content, and connect the site's entities and relationships. Markup can clarify those relationships, but it cannot fix blocked crawling, absent visible answers, or conflicting business details. Validation should therefore check both the data structure and its agreement with the published page.

Choosing Your Implementation Format JSON-LD Versus Microdata

JSON-LD and Microdata can describe the same FAQPage structure, but they place that structure in different parts of the implementation. JSON-LD uses a separate script block, while Microdata adds attributes directly to the visible HTML. Google's general structured data guidance commonly supports JSON-LD, and practical implementation guides place the script in the HTML head or near the end of the body. The Schema App implementation guide also directs implementers toward validation before deployment.

A comparison chart explaining the implementation formats of JSON-LD and Microdata for structured data markup.

JSON-LD keeps data separate

JSON-LD is usually easier to maintain when a CMS, SEO plugin, or headless frontend controls the page template. The FAQ text remains in the page content, and the structured data is generated separately. That separation keeps the HTML readable, but it creates a risk: the JSON-LD can drift away from the visible questions if editors update one and forget the other.

Use JSON-LD when:

  • Your CMS supports scripts: WordPress, a custom CMS, or a templating system can insert the graph consistently.
  • Your team wants centralized editing: Developers can manage the data layer without adding attributes throughout the markup.
  • Your page template changes often: A separate block is less invasive than editing every visible element.

Microdata binds markup to content

Microdata places itemscope, itemtype, and itemprop attributes on the elements visitors see. That creates a close relationship between displayed text and structured data. The tradeoff is maintenance complexity. Editors and developers can accidentally break the hierarchy by moving an element, omitting an attribute, or placing a property outside its intended scope.

Scenario Practical choice Main reason
WordPress with a reliable schema plugin JSON-LD The plugin can generate consistent output
Headless CMS with structured components JSON-LD or controlled Microdata Choose the format your rendering system can keep synchronized
Static HTML with tightly controlled templates Microdata or JSON-LD Both can work if visible content and markup stay aligned
Frequently edited FAQ content JSON-LD generated from the same content source Reduces manual duplication
Developer-managed, small FAQ block Microdata Inline properties can be easy to audit in the template

Don't implement both formats just to increase the amount of markup. Duplicating the same FAQ in JSON-LD and Microdata can create conflicting versions, and it adds another maintenance path. Pick one format, connect it to the content workflow, and validate the rendered result.

JSON-LD FAQ Page Schema Examples You Can Copy and Adapt

A JSON-LD implementation starts with @context and @type. The top-level type is FAQPage, and mainEntity contains one or more Question objects. Each Question includes a complete name and one acceptedAnswer with an Answer text value.

Practical guides place the JSON-LD block inside a <script> tag in the HTML head or near the end of the body, then recommend testing the result with Google's Rich Results Test. The structured data examples from AISEOGrow provide additional implementation context.

Minimal single-question example

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Do you accept dental insurance?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Our dental office accepts several insurance plans. Contact the office with your plan details so our team can confirm benefits before your appointment."
      }
    }
  ]
}
</script>

name is the full question shown to users. acceptedAnswer.text should match the visible answer closely. Don't add an answer in the JSON-LD that visitors can't find on the page.

Multi-question pattern

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "How do I schedule an appointment?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "You can request an appointment through our online form or call the office during business hours. Our team will confirm the available appointment time."
      }
    },
    {
      "@type": "Question",
      "name": "Do you provide emergency dental visits?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "We assess urgent dental concerns and explain the next available care option. Call the office as soon as possible for guidance about your situation."
      }
    }
  ]
}
</script>

The array lets you add multiple Questions without changing the overall hierarchy. Every entry still gets exactly one answer. A law firm, for example, could replace these questions with jurisdiction, consultation, and document-preparation answers. A home service company could use service-area, appointment-window, and emergency-response questions.

Pattern Structure When to use
Single FAQ One Question in mainEntity A focused page with one genuine question
Multiple FAQs Several Question objects in the array A dedicated FAQ page or clearly defined FAQ collection
Service FAQ Questions about logistics and eligibility Dentists, lawyers, medical practices, and home services
Reusable template CMS-generated Question objects Sites where staff regularly update answers

The code is reusable, but the facts aren't interchangeable. Replace each question and answer with information the business can support, then compare the rendered page with the graph before publishing.

Microdata FAQ Page Schema Examples for Inline HTML

Microdata marks the same relationships directly in the HTML that visitors read. The outer element receives itemscope and itemtype, the question receives the Question scope, and the answer receives itemprop="acceptedAnswer" with an Answer type.

A laptop on a wooden desk displaying structured FAQ page schema code on its screen with a notebook.

A complete inline example

<section itemscope itemtype="https://schema.org/FAQPage">
  <h2>Frequently asked questions</h2>

  <div itemprop="mainEntity" itemscope itemtype="https://schema.org/Question">
    <h3 itemprop="name">Do you offer same-day plumbing appointments?</h3>

    <div itemprop="acceptedAnswer" itemscope itemtype="https://schema.org/Answer">
      <p itemprop="text">
        Same-day appointments may be available in our service area. Call the office with your address and plumbing issue so the scheduling team can confirm availability.
      </p>
    </div>
  </div>
</section>

The <section> establishes the FAQPage scope. The Question <div> is a member of mainEntity, and the nested Answer <div> tells parsers which response belongs to that question. The visible heading and paragraph carry the actual values through itemprop.

Implementation check: If you remove the visible question or answer from the HTML, you've removed the content your Microdata is meant to describe.

Adding another Question

<div itemprop="mainEntity" itemscope itemtype="https://schema.org/Question">
  <h3 itemprop="name">Which areas do you serve?</h3>

  <div itemprop="acceptedAnswer" itemscope itemtype="https://schema.org/Answer">
    <p itemprop="text">
      We serve homeowners in the listed local communities and nearby areas. Contact us with your address before booking so we can confirm coverage.
    </p>
  </div>
</div>

A common error is putting itemprop="acceptedAnswer" on the paragraph without creating the nested Answer scope. Another is adding itemprop="text" to a container that doesn't contain the complete answer. Keep each property attached to the element that visibly contains its value.

Microdata can work well in a tightly controlled static template where the developer owns both the content and markup. It becomes harder to manage when a staff member edits FAQ text through a page builder that moves or strips HTML attributes. In that situation, JSON-LD generated from the same content source may reduce accidental breakage.

The following video can help teams visualize how structured FAQ markup fits into a page implementation:

Whichever format you choose, don't hide the answer in data alone. The HTML should render a useful question-and-answer experience before any crawler interprets the structured properties.

Best Practices for Visible Content Placement and Eligibility

FAQ markup succeeds or fails on content fidelity, not on the number of properties in the code. Google's FAQ guidance emphasized that the full text of every question and answer must appear on the page, that users must be able to see the FAQ content, and that each Question should have one answer. Those rules also make sense for answer engines, because a parser needs a stable relationship between the question, the answer, and the page context.

An infographic showing five best practices for implementing FAQ page schema for improved website search visibility.

Make the visible page the source of truth

Write the FAQ in the page's rendered content first. Then generate JSON-LD or add Microdata around that content. Don't create a set of answers in a plugin and assume the page builder has displayed the same text.

Use one clear answer for each Question. If a service business has several possible answers depending on insurance, location, or appointment type, explain the condition in one complete response or direct the visitor to contact the appropriate team. Don't place multiple competing answers under one Question.

Choose questions with decision value

Generic promotional copy doesn't belong in FAQ markup. Questions should address a real uncertainty that could delay a call, booking, consultation, or purchase.

A useful service-business set might include:

  • Eligibility: Who can use the service, and what conditions apply?
  • Logistics: How does someone book, prepare, or submit information?
  • Coverage: Which insurance plans, jurisdictions, or service areas apply?
  • Cost context: What determines the fee or estimate, without inventing a price?
  • Urgent handling: What should someone do when the issue can't wait?
  • Process expectations: What happens after the first contact?

Answers should be concise, factual, and entity-rich. Name the service, location, department, or policy when that context helps a machine connect the answer to the business. Avoid vague lines such as “We're here to help,” which provide little extractable information.

The FAQ creation guide from AISEOGrow is useful for turning customer objections into visible, answer-focused questions. Treat accordions carefully. If a user must click to reveal an answer, confirm that the full content is still rendered and accessible in the page HTML. Don't use markup to label hidden promotional text as an FAQ.

Content standard: Every marked-up answer should be useful even if a search engine never displays it.

Finally, use FAQPage only when the page presents an FAQ collection. A service page with a short question section may need different page-level structured data, while the FAQ content can remain visible as semantic HTML. Accurate description matters more than forcing every question into a FAQPage graph.

Validation Testing and Deployment Workflow

Validation has two layers. First, confirm that the markup is syntactically valid and semantically recognizable. Then review the rendered page as a visitor would, checking whether the structured graph accurately describes the content people can read. FAQ schema now works less as a rich-result tactic and more as a structured understanding layer for search systems and answer engines.

A repeatable QA sequence

  1. Confirm the page purpose. Decide whether the URL presents an FAQ collection. If the main content is a product, article, or service with only a short question area, do not label the entire page FAQPage automatically.

  2. Compare visible copy with markup. Copy every marked-up question and answer from the rendered page and compare spelling, qualifiers, locations, service names, and policy conditions. A shortened JSON-LD answer can become inaccurate when it removes a limitation that changes the meaning.

  3. Inspect the hierarchy. Check that mainEntity contains Question objects, each Question has name, and each includes one acceptedAnswer containing an Answer and text. The JSON-LD examples above show the required nesting.

  4. Test the published URL. Run it through Google's Rich Results Test to identify parsing errors, missing properties, or malformed JSON. A successful test confirms that the markup can be read. It does not promise an FAQ display in Google Search, because that search appearance has been retired.

  5. Check rendered HTML. Use browser inspection or the rendered-page view in your testing workflow. Confirm that the complete question and answer exist in the page HTML, rather than appearing only after interaction or remaining inaccessible to crawlers.

  6. Deploy and monitor. Record the URL, implementation format, page changes, and validation result. Recheck after template updates, plugin changes, or edits to the FAQ content.

Troubleshooting common failures

A missing acceptedAnswer usually indicates an incomplete Question object or an answer placed at the wrong nesting level. In Microdata, check for the nested Answer itemscope, since omitting it can break the equivalent relationship.

Invalid JSON often comes from trailing commas, unescaped quotation marks, or HTML pasted inside a JSON string. Keep answer text plain unless the implementation and parser support the required format. If the script sits in the wrong template location, move it to the head or near the end of the body, then test the rendered URL again.

Search Console reports and API availability can change independently of Schema.org validity. Google's Search updates documentation records those product changes. A missing FAQ report therefore does not prove that every FAQPage graph is invalid. Judge the implementation by whether it accurately and usefully describes the visible page, including the service terms a customer and an answer engine need to understand.

Quick Reference Glossary Cross References and Next Steps

Use this glossary when reviewing an implementation or explaining it to a client:

  • FAQPage: The top-level type for a page presenting one or more answered frequently asked questions.
  • mainEntity: The property that contains the primary Question entities on the FAQ page.
  • Question: The type representing each individual question.
  • acceptedAnswer: The property connecting a Question to its single Answer.
  • Answer: The type containing the response, usually through text.
  • JSON-LD: A separate structured-data script that describes the page without placing schema attributes throughout visible HTML.
  • Microdata: Inline HTML attributes that connect visible elements to Schema.org types and properties.

For a quick service-business lookup, match the question type to the information a visitor needs:

Business need Useful FAQ question
Dentist or orthodontist Do you accept my insurance, and how can I prepare for an appointment?
Law firm Do you handle cases in my jurisdiction, and what information should I bring?
Medical clinic Which patients or conditions does this service address, and how do I request an appointment?
Home service business Do you serve my location, how is an estimate arranged, and what should I do during an urgent issue?
Professional service firm What does the initial consultation include, and which information helps your team assess the request?

The strongest FAQ content usually begins with customer-service records, intake forms, sales calls, and on-site search behavior. Turn repeated uncertainty into a direct question, answer it with verifiable information, and make the same answer visible in the page content and structured data.

The FAQPage vocabulary can still support machine-readable understanding, but it shouldn't replace semantic HTML, clear headings, internal links, or accurate business entities. The Stackmatix discussion of FAQ schema and AI Overviews highlights an underserved practical point: many examples stop at code and don't explain how concise, factual, entity-rich questions can serve answer engines. That writing discipline matters more than decorative markup.

Run the implementation through three final questions:

  1. Does this URL function as an FAQ page?
  2. Can a visitor see every marked-up question and its complete answer?
  3. Does the structured data describe the page accurately without promotional filler or unsupported claims?

If the answer to all three is yes, publish the markup, validate the rendered URL, and keep a record for future edits. If not, improve the page or leave the FAQ as visible semantic HTML rather than forcing an inaccurate type.

AISEOGrow helps service businesses audit structured data, technical SEO, content depth, and visibility across Google and answer engines. Visit AISEOGrow to request an AI SEO audit or strategy call, and get practical guidance on FAQ design, schema implementation, and machine-readable content.

Scroll to Top