What makes a page an FAQ opportunity?

Two or more headings phrased as questions, each followed by an answer, and no FAQPage markup on the page. It is a detection of existing content rather than a suggestion to write new content, which is what separates it from advice to add an FAQ section to everything.

Should I add markup to every flagged page?

No. A page whose question headings are the structure of an article, rather than a set of independent questions and answers, is not an FAQ, and marking it up as one misdescribes it. Skip those deliberately rather than working through the list mechanically.

Does FAQ markup still do anything after the rich result was cut?

Not for the rich result on most sites, which is now limited to government and health domains. What it still does is pair each question with its answer explicitly, which is the form that survives being extracted by anything reading the page as data rather than as prose.

Pages that answer questions without saying so in markup

Somewhere on your site is a page that already did the hard part. Six subheadings, each one a question a customer actually asks, each followed by a real answer. What it does not have is anything in the markup saying so. This check is the list of those pages, and the harder half of the work is deciding which ones to leave alone.

The short answer

A page lands on this list when it already contains question-shaped headings with answers under them and carries no FAQPage markup. The content is there; only the declaration is missing. Most candidates are worth a few minutes, and a good number should be deliberately skipped, because not every question heading belongs in an FAQ.

ImportantAudit check · FAQ opportunities

The pattern that puts a page on this list

Two conditions have to hold at once. The page contains question-shaped content with answers sitting next to it, several of them, not one. And the page's structured data contains nothing describing that relationship. Either one alone is unremarkable. Together they are a page doing the work and declining to say it.

In practice the flagged pages are predictable. A pricing page with a questions block under the plan table. A support article whose H3s are all phrased as questions. A long guide that ends in "Common questions". An onboarding doc where somebody wrote out the six things every new customer asks in week one.

This is the only check in the pillar that asks you to write nothing.

Everything else in the answer-engine group is an editing job: rephrase the headings, restructure the order, tighten an answer to something liftable. This one hands you pages where the content decision was already made correctly, sometimes years ago, by someone who was not thinking about machines at all.

Where the detection is wrong, in both directions

Worth knowing before you work the list, because a triage pass over a list you trust too much is how markup ends up on pages that should not have it.

Flagged and it should not be.A rhetorical heading is not a question: "Why does any of this matter?" followed by three paragraphs of argument is prose with a hook on it. A glossary whose entries are phrased as questions is a definition list. And a page whose answers are all a variation on "contact our team" has questions and no answers, which is a content problem rather than a markup one.

Not flagged and it should be. These are the more interesting ones, because they are invisible in the report by definition.

The accordion that fetches on click. If the question text and answers arrive from an API when a user expands a row, no crawler sees questions on that page, so it never appears as an opportunity. It is usually the page on your site that most needs the work.
Markup injected after load. Schema added by a tag manager rather than rendered server-side does not exist as far as this check is concerned, so the page is reported as an opportunity you already took. The fix is the injection method, not the list entry.
The hub page that owns the questions. This is the one people get wrong. If the same six question-and-answer pairs appear on ten product pages while only /faq carries the markup, all ten product pages are flagged, correctly, one page at a time. Marking up all ten would put identical FAQ markup on eleven URLs, which is not ten wins.

Finding candidates from your browser console

You do not need a crawler to test the idea on a page you already suspect. This is roughly what the check does per page, minus the ranking:

devtools console

const QUESTION = /^(what|why|how|when|where|which|who|can|do|does|is|are|should)\b/i

const headings = [...document.querySelectorAll('h2, h3, h4')]
  .map((h) => h.textContent.trim())
  .filter((t) => t.endsWith('?') || QUESTION.test(t))

const ld = [...document.querySelectorAll('script[type="application/ld+json"]')]
  .map((s) => s.textContent)
  .join(' ')

console.log({
  questions: headings.length,
  hasFaqPage: ld.includes('"FAQPage"'),
  headings,
})

Two caveats that make this a probe rather than an audit. It reads the live DOM, so it will happily count headings a crawler never saw and find markup a crawler never received: run it with JavaScript disabled if you want the pessimistic answer. And it looks at one page, which means it cannot tell you the thing that decides your workload, which template these pages share.

Getting the list for your own site

The useful version of this check is the ranked list across every page, because the finding is almost never a single page. It is a pattern in a template.

This one needs the full crawl

Detecting an opportunity means reading a page for question-shaped content and then confirming that no matching markup exists, which is two passes over the same page rather than one field lookup.

The instant search on this site audits a single page, so rather than show you a verdict it cannot support, this guide sends you to the place the check actually runs.

Run the full audit, free

Triage: which candidates are actually worth it

Assume the list is longer than your appetite. Four tests, in this order, and a page that fails the first one is not an opportunity yet.

1. The answers stand alone.Read each answer with the page hidden. If it opens with "as mentioned above" or resolves a pronoun from the previous section, it is a paragraph in a flowing article, not an answer to a question. Marking it up promises something the text does not deliver, and the fix is in the prose first.
2. Somebody asks it in those words.A question written from inside the company ("What is our provisioning model?") matches nothing anyone types. That is a rewrite, and it is worth doing on its own merits.
3. The page is stable. Markup has to keep matching the visible text forever, so a page three teams edit weekly is a liability rather than a win. Pick the pages whose answers were true last year.
4. The page has something to gain. It gets impressions, or it is somewhere an assistant would plausibly be pointed. Structured data on a page nothing reaches is a tidy file with no reader.

Then reorder the work. Do not go down the list page by page: group it by template. If the questions block is a component, one change covers every page that renders it, and a two-hundred-page list collapses into three pull requests. That regrouping is usually the entire difference between this being a quarter's project and an afternoon.

Why a page that already works is still flagged

The flag does not mean the page is broken. It means the page is doing work it has not declared. Every reader gets the answer, every model that fetches it can read the answer, and nothing about the page is inaccessible, which is why this cannot sit in the Critical band alongside a page no crawler is allowed to request.

The argument for it outranking Refinement is a ratio rather than a severity. The scale weighs what a fix costs against what it returns, and here the content, the hardest and most expensive input, is already paid for. What remains is a template change measured in hours. Nothing else in the pillar has that shape.

There is a second reason, and it is the one that convinced us. The pages this check finds are selected for being answer-shaped, which means they are the pages most likely to be quoted whether you mark them up or not. A list of your own most extractable pages is worth something on its own, and a check that produced it and rated itself cosmetic would be underselling its own output.

Candidates you should deliberately skip

A shorter list you maintain beats a complete one that drifts. These are the ones to close as intentionally-not-doing rather than leave open forever.

Pages where the answer is a commitment. Pricing, refund terms, SLAs, anything legal. The markup becomes a second copy of a promise, and the two copies are edited by different people on different days. When the price changes and the JSON-LD does not, you are serving a machine-readable version of an obligation you no longer hold.
Question blocks that are navigation. "Where do I start?" followed by five links is a menu wearing a question mark. There is no answer on the page for the markup to describe.
The repeated block on many pages. Pick the one page that should own those questions and mark it up there. Leave the rest flagged, and note why, so the next person does not reopen it.
Anything you would not defend in writing. Marking an answer up says this is the accepted answer to that question. If the current text is a hedge somebody wrote to close a ticket, that is what you would be declaring.

Deleting the questions closes the finding and is almost never the fix.

Merging is, sometimes. Six thin pages each answering one question are better off as one page that answers all six, at which point you have a genuine candidate instead of six weak ones. That is a content decision the report cannot make for you, and it is the only legitimate way a page leaves this list without gaining markup.

Does this affect AI search?

Partly, and not in the direction the phrasing suggests. Detection changes nothing: a model fetching a page with clear question headings and clear answers reads them perfectly well today, with no markup involved. Adding a declaration to content a machine can already parse is not what turns an invisible page into a cited one.

The case for the markup itself, what an explicit question-to-answer pairing gives a retrieval pipeline, belongs to the schema guide and is argued there. What this check contributes is upstream of it: a map of the pages on your site that are already shaped the way answer engines lift content. Read as a content inventory rather than a markup backlog, that list is the more valuable half of the output.

One case is a genuine, direct AI-search change. The accordion that fetches its answers on click has no questions in the HTML at all, so no model can read them, marked up or otherwise. Fixing that is not a structured-data task, it is a rendering one, and it is the difference between content existing and not. The AI search checks cover that side.

Confirming a page has come off the list

Re-crawl, and the page should report FAQ markup present rather than an opportunity. That is the mechanical part, and it is the part least likely to be wrong.

Two things no tool will confirm. First, that the number of questions in the markup matches the number on the page: a template rendering its JSON-LD from CMS fields while the visible block is hand-written is exactly where those counts diverge, and the markup is then describing questions a reader cannot find. Second, that you added one block and not two, which happens the moment a plugin is also generating markup for the same page. The markup guide covers validating what you shipped.

And if you fixed this at the template level, do not verify on the page you edited. Open three other pages that use the same component, ideally the ones with the fewest questions and the longest answers, because those are where a shared template renders something you did not picture.

Questions this check raises

What makes a page an FAQ opportunity?: Two or more headings phrased as questions, each followed by an answer, and no FAQPage markup on the page. It is a detection of existing content rather than a suggestion to write new content, which is what separates it from advice to add an FAQ section to everything.
Should I add markup to every flagged page?: No. A page whose question headings are the structure of an article, rather than a set of independent questions and answers, is not an FAQ, and marking it up as one misdescribes it. Skip those deliberately rather than working through the list mechanically.
Does FAQ markup still do anything after the rich result was cut?: Not for the rich result on most sites, which is now limited to government and health domains. What it still does is pair each question with its answer explicitly, which is the form that survives being extracted by anything reading the page as data rather than as prose.