SEO

FAQ schema generator (JSON-LD)

By Charles Summers · Updated · Free, no signup

Short answer

You can generate valid FAQPage markup here in a few seconds, but you should know before you do that in August 2023 Google narrowed FAQ rich results to well-known authoritative government and health websites. If you are not one of those, the collapsible questions will not appear, however perfect your markup is. Nothing is broken and nothing is penalised, the feature simply is not offered to you. The residual reasons to emit it anyway are real but small, and no honest page should sell you a project on them.

Use the schema markup generator

Why faq pages need a different approach

This is the one type on this tool where the most useful thing a page can do is talk you out of the work. On 8 August 2023 Google announced it was reducing FAQ rich results to a narrow set of well-known, authoritative government and health websites, and reducing How-To results to desktop only. How-To was withdrawn entirely not long after. For every ordinary commercial, publisher or B2B site, the accordion that made FAQ markup famous stopped appearing, and it has not come back.

That leaves a lot of people maintaining markup for a payoff that quietly ended. There is nothing dangerous about keeping it: valid FAQPage markup carries no penalty, causes no error, and is still parsed. But if your reason for adding it was the extra vertical space in the results, that reason no longer exists, and any tool or agency still pitching FAQ schema as a click-through-rate tactic is selling you a 2021 playbook. The rest of this page covers what remains true, and what it is honestly worth.

It runs entirely in your browser. Nothing you type is sent to a server, no account is required, and there is no usage limit, because there is no cost per run to control.

What the August 2023 change actually did

It is worth being precise, because the change is often described loosely and the loose version leads people to the wrong conclusion. Google did not deprecate FAQPage. The vocabulary still exists, the documentation still exists, the markup still validates, and Search Console still reports on it. What changed is who the rich result is served to. Eligibility narrowed to well-known, authoritative government and health sites, on the stated reasoning that the feature was cluttering results for queries where it was not adding much.

The practical consequence is that eligibility is now a property of your site rather than a property of your markup. This is unusual and it catches experienced people out, because every other structured data problem they have debugged has been fixable by improving the markup. Here there is nothing to fix. A perfectly formed FAQPage block on a well-run ecommerce site produces exactly what a malformed one does, which is nothing visible.

You can prove this to yourself in a minute rather than taking anybody's word for it. The Rich Results Test will confirm your item is valid and detected. Then look at your actual result in the SERP for a query the page ranks for. Valid and detected has never meant rendered, and this is the cleanest live example of that distinction anywhere in structured data. It is a useful thing to have seen once, because it inoculates you against the wider assumption that a green test result is a promise.

The How-To story is worth knowing alongside it as a lesson about durability. HowTo was a heavily promoted rich result with a large ecosystem of plugins and agencies built on it, and it was first restricted to desktop and then removed altogether. Structured data features are not permanent infrastructure. Building a content strategy on top of one specific SERP treatment is a bet on Google's product roadmap, and that bet has now been lost twice in the same year by the same people.

The small reasons to keep emitting it, stated without inflation

Having been blunt about the loss, it would be dishonest to swing to the opposite claim that the markup is worthless. There are residual reasons. They are just much smaller than the ones that were being marketed, and none of them justifies a dedicated project.

  • You might be in the eligible set, or become so. Government and health publishers should absolutely keep it. If that is you, this is not a marginal call and the rest of this list does not apply.
  • Question and answer pairs are cheap for a machine to consume. An explicit pairing costs a parser nothing where inferring the same structure from headings and paragraphs costs it something. The gain is real and modest, and nobody can quantify it for you.
  • It costs nothing once it is in the template. If your CMS already emits it from structured content fields, removing it is work with no upside. Leave it. The argument here is against new effort, not against existing plumbing.
  • It survives your redesigns. Markup generated from data outlives the accordion component that displays it, which is not nothing on a site that reskins every two years.
  • It is a forcing function for writing complete answers. The markup requires the full answer text rather than a teaser, which is a discipline that improves the visible page whether or not anything renders.

The distinctions people still get wrong, and where the effort should go instead

FAQPage and QAPage are different types for different situations, and the mix-up is common enough to be worth a paragraph. FAQPage is for a page where the site itself asks and answers questions, with one authoritative answer each. QAPage is for user-generated question and answer content, a forum thread or a community post, where one question attracts multiple competing answers from different people and votes may decide which is best. Marking up a forum thread as FAQPage misdescribes it, and marking up your own help page as QAPage does the same in reverse.

The other durable rule is that the answer in the markup must be the complete answer as it appears on the page, not a summary and not a teaser that requires a click. Only a limited set of HTML survives inside answer text, essentially basic block and inline formatting, and anything else is stripped. A question that is on the page but whose answer loads from an API after interaction is a genuine problem, because the markup asserts content the initial page does not contain.

If your motivation for looking at FAQ markup was capturing more surface area in the results, the honest redirect is that the surface you were aiming at is now allocated differently. People Also Ask is not driven by FAQ markup and never was, so no amount of it gets you in. What actually earns a place there is a page that answers a specific question clearly, in its own section, in language that matches how people ask it. That work is markup-independent, it survives feature deprecations, and it is what the FAQ markup was standing in for anyway.

One last practical note for anyone auditing an inherited site. Sites that adopted FAQ markup aggressively often carry FAQ sections that were added purely to justify the schema, which means blocks of thin, invented questions nobody asked sitting at the bottom of otherwise decent pages. Now that the payoff has gone, those sections are pure liability: they dilute the page, they read as filler to a human, and their only reason for existing has been withdrawn. Deleting them is usually the highest-value action available on this whole topic.

Numbers worth knowing

MetricTypicalWhat it means
FAQ rich result eligibility since Aug 2023authoritative gov and health sitesAnnounced 8 August 2023. Eligibility became a property of the site rather than of the markup, which is why there is nothing in your JSON-LD you can improve to earn it back.
How-To rich resultrestricted, then withdrawnReduced to desktop only in the same August 2023 announcement and removed entirely afterwards. Useful context for how permanent any single SERP feature should be assumed to be.
Penalty for keeping valid FAQ markupnoneIt is not deprecated, it does not error, and it is still parsed. The change removed a benefit rather than creating a risk, so there is no urgency to strip it out of working templates.
FAQ markup as a route into People Also Asknot a mechanismPAA has never been driven by FAQPage markup. If that was the goal, the work is writing a clearly answered question in a dedicated section, which no schema type can substitute for.

Mistakes that quietly cost you results

Adding FAQ sections to pages purely to justify the markup
The payoff that made this worth doing was withdrawn, so invented questions nobody asked are now just filler at the bottom of your page. On an inherited site, deleting those sections is usually a bigger improvement than anything you could do to the JSON-LD.
Marking up a user-generated forum thread as FAQPage
That is QAPage: one question, multiple competing answers from different people, possibly with votes. FAQPage is for your own authoritative answers on a page you control. The two describe genuinely different content and swapping them misdescribes what a reader will find.
Putting a teaser in acceptedAnswer and the real answer behind a click
The answer text has to be the complete answer as it appears on the page. Answers loaded by JavaScript after user interaction fail this in a way that is easy to miss, because the markup is asserting content the initial page does not contain.
Buying an FAQ schema plugin on the promise of more SERP real estate
For any site outside the government and health set, that promise expired in August 2023. Ask whoever is selling it what result they expect to appear and on which query, then check that query yourself before you pay for anything.

What does the output look like?

This is the exact output the tool produces from the example inputs. It is generated by the same code that runs when you click the button, so what you see here is what you get.

SCHEMA TYPE: FAQPage TARGET PAGE: https://northfell.com/help/returns JSON-LD (paste into the head, or anywhere in the body) <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "FAQPage", "name": "Returns and exchanges", "url": "https://northfell.com/help/returns", "mainEntity": [ { "@type": "Question", "name": "How long do I have to return something?", "acceptedAnswer": { "@type": "Answer", "text": "Sixty days from delivery for unworn items with tags attached. Warranty claims on manufacturing faults are separate and have no time limit." } }, { "@type": "Question", "name": "Who pays for return postage?", "acceptedAnswer": { "@type": "Answer", "text": "We do, on any order shipped within the UK. International returns are at your cost unless the item was faulty." } }, { "@type": "Question", "name": "Can I exchange for a different size?", "acceptedAnswer": { "@type": "Answer", "text": "Yes, and we hold the replacement for seven days once you start the return so the size does not sell out while it is in transit." } } ] } </script> REQUIRED BY GOOGLE FOR FAQPAGE [ok] mainEntity 3 Question item(s) built [ok] Question.name one per question [ok] Question.acceptedAnswer.text answer text must be the complete answer, not a teaser RECOMMENDED (eligible without these, thinner result with them missing) [ok] url supplied [TODO] answer HTML only h2, h3, br, ol, ul, li, a, p, div, b, strong, i and em survive inside answer text TODO MARKERS LEFT IN THE BLOCK: 0 Nothing left to fill in. Run it through the Rich Results Test anyway, because eligibility is decided per feature. NOTE ON THIS TYPE Since August 2023 FAQ rich results are restricted to well-known authoritative government and health sites. Keep this markup for parsing value if you like, but do not plan a project around the accordion appearing. BEFORE YOU SHIP 1. Every value above must also be visible to a user on the page. Invisible markup is what the spammy structured data manual action is for. 2. Test the rendered page, not the source, if anything on it is injected by JavaScript. 3. Check the enhancement report in Search Console a week later. Errors mean ineligible; warnings mean eligible but thinner.

Frequently asked questions

Should I remove the FAQPage markup I already have?

No. There is no penalty attached to it, it still validates, and if your templates already generate it from structured content there is no upside to spending engineering time stripping it out. The argument is against starting new work on it, not against leaving working plumbing alone. The one thing worth removing is not the markup itself but any thin FAQ content that was written purely so the markup would have something to describe.

Which sites still get the FAQ accordion in results?

Google described the surviving set as well-known, authoritative government and health websites, and did not publish a list, so there is no application process or threshold you can work towards. If you run a health service, a public body or a government information site, keeping thorough FAQ markup is straightforwardly worth it. If you sell software or shoes, treating this as achievable through better markup is a misunderstanding of what changed.

Do AI answer engines actually use FAQPage markup?

Honestly, nobody outside those companies can tell you with confidence, and anyone claiming a measured figure is guessing. The defensible statement is narrower: an explicit question and answer pairing is cheaper for any parser to consume than the same content inferred from headings, and cheaper parsing is generally better than expensive parsing. That is a reasonable argument for leaving existing markup in place, and a poor argument for a new project.

Is a long FAQ page better than answering questions inside the relevant pages?

Usually worse, and the markup change makes that clearer than it used to be. A question answered on the page where it arises, in the context that prompted it, serves both a reader and a search system better than the same answer exiled to a central help page nobody links to. Consolidated FAQ pages made sense partly as a vehicle for the markup, and the vehicle no longer goes anywhere.

Can one page carry both FAQPage markup and another type?

Yes, and it is common and fine. A product page can carry Product markup and an FAQPage block for the questions genuinely displayed on it, emitted as separate script blocks. The thing to avoid is duplicating the same questions across dozens of URLs because they sit in a shared template footer, which asserts that every one of those pages is an FAQ page when only one of them is.

Related free tools

Some links on this site are affiliate links, which means Hacking Demand may earn a commission if you buy through them at no extra cost to you. This does not influence which tools are listed. The tools on this page are free and have no affiliate relationship of any kind.