Should you still add FAQ schema?

Add it when you have a clear reason to maintain a machine-readable description of your FAQ content. Structured data means information labelled with predictable names. Schema.org defines FAQPage as a page presenting frequently asked questions. The FAQPage definition remains available.

Google stopped showing FAQ rich results on May 7, 2026. The previous documentation address now redirects to its documentation updates. Check the current notice before following an older tutorial promising extra space in search results. Google documents that retirement.

Ask whoever proposed the work to name the intended use. An answer such as “our content system needs consistent question-and-answer records” gives you something to assess. A promise of automatic search visibility does not provide a useful acceptance criterion.

If you are reviewing a wider backlog, use a practical SEO audit to decide where this task belongs. Give each proposed change a purpose, an owner and a way to check completion.

Which questions belong in your FAQ?

Choose questions that help someone complete the next step. Review enquiries, order notes and messages to your team. Keep the wording close to the customer’s language, then answer with your actual operating policy.

Hypothetical example: a repair business

Imagine a small appliance repair company preparing a booking page. “What should I send when requesting a repair?” is a useful starting point. A hypothetical answer could be: “Send the appliance model and a short description of the fault.”

Ask the person handling bookings to approve that answer. If photographs are needed, decide which ones and explain how to submit them. Do not let a copywriter invent a diagnostic process just to complete an FAQ block.

• Keep one main issue in each question.
• Put the direct answer before background detail.
• State relevant exceptions next to the rule.
• Remove unsupported promises about timing or availability.
• Choose someone to approve future changes.

Read every answer as though you were contacting the business for the first time. Could you act without sending another message for clarification? Use that question as an editing test, rather than aiming for an arbitrary number of FAQs.

For a shop, separate product questions from general delivery policy. Consider the product schema implementation guide when planning product information. Keep this FAQ task focused on the questions you have actually chosen to publish.

What does a simple FAQPage example look like?

Start with one approved question. JSON-LD is a format for expressing labelled information in a code block. In this example, the visible question and answer should use the same wording as the two editable text values.

Hypothetical visible content: What should I send when requesting a repair? Send the appliance model and a short description of the fault.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What should I send when requesting a repair?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Send the appliance model and a short description of the fault."
      }
    }
  ]
}
</script>

Read the example before changing it

Replace the question in name and the answer in text. Keep the surrounding field names intact. To include another question, add another complete Question object inside the mainEntity list.

Schema.org describes mainEntity as the primary entity described by a page and text as textual content. Consult the FAQPage property reference for those definitions. Avoid filling every available property simply because a generator offers it.

For the first attempt, keep the answer as plain text. If you introduce quotation marks or more complex formatting, have the generated JSON checked. Do not judge correctness by whether the code looks tidy in a document.

How should you install the markup?

Check the existing page before adding a new block. Ask your developer to search its HTML output for FAQPage and identify where any existing markup comes from. Make one deliberate choice about which component will manage the questions.

When you use WordPress

Review the SEO plugin and FAQ block already installed. If your site uses Yoast SEO or Rank Math, inspect the options available in your installed version. Ask for a preview of the resulting page before buying another plugin or adding a separate generator.

A useful handover should show where to edit an answer and how to check the output. Request instructions for your actual setup. Avoid relying on a screenshot from a tutorial whose version or configuration differs from yours.

When a developer adds the code

Give the developer the approved visible text and the example block. Request insertion into the selected page’s HTML as JSON-LD, followed by a check of the live output. Keep a copy of the previous implementation so you can undo an incorrect change.

Do not paste this page-specific example into a shared site field without reviewing its scope. Ask which other pages would receive it. For a multilingual site, prepare and check each language separately; the hreflang planning guide covers the wider language-page setup.

How do you check the finished implementation?

Run a technical check and a content check. Use Schema Markup Validator to inspect the structured data, then compare the output with the visible page yourself. Treat successful parsing as one checkpoint in your review.

1. Open the page as a visitor and find the FAQ content.
2. Compare each question with its corresponding code entry.
3. Ask the business owner to approve each answer.
4. Review any reported syntax errors, meaning mistakes in the code’s written structure.
5. Look for old or conflicting FAQ blocks in the page output.
6. Repeat the check after the correction is published.

In a hypothetical repair company, the page might ask customers to wait for a booking confirmation while old markup says the booking is immediate. Resolve the policy first, then update both versions. The acceptance test should catch that disagreement.

Keep a short record containing the page address, reviewer, result and unresolved issue. Ask for evidence from the published page, not only a saved generator preview. Use the mobile SEO checklist when checking how comfortably customers can read the answers on a phone.

Should you keep or remove existing FAQ markup?

There is no need for an urgent removal project solely because the search feature ended. Existing FAQ structured data can remain, although it no longer earns the former Google display. Search Engine Journal explains the distinction.

My recommendation is to compare its actual use with the work needed to maintain it. Keep accurate markup if a documented process uses it and updates are manageable. Consider removing it if nobody owns it and keeping it aligned requires avoidable manual work.

A manageable plan for this week

• Select one important customer-facing page.
• Approve its questions and answers with the responsible colleague.
• Identify the existing source of FAQ markup.
• Choose to retain, revise or remove the coded version.
• Record who will review future policy changes.

Keep useful visible answers even if you remove their coded representation. If you also change the navigation around them, follow a deliberate internal linking plan. Give visitors a clear route to the full policy or booking instructions.

For measurement, I suggest tracking whether customers still ask the same unresolved questions. Record changes to the wording alongside those observations. Do not present a reduction in enquiries as proof that schema improved rankings.