Deciding Whether An FAQ Block Earns Its Place
FAQ blocks spread when FAQ rich results were widely shown. Google now shows them for very few sites, so a large number of pages carry questions nobody reads that repeat content already above them. Removing every block is also wrong, and whether the blocks help in AI answer engines is argued both ways with little evidence either side. Judge each block on whether the questions are real and whether the answers belong in the body instead.
FORMAT
faq-block-decision.md
WHEN TO REACH FOR THIS
Use when a page carries an FAQ section added for rich results and you are deciding whether to keep, rewrite or remove it.
The skill file
---
name: faq-block-decision
description: Use when a page carries an FAQ section added for rich results and you are deciding whether to keep, rewrite or remove it.
---
# Deciding Whether An FAQ Block Earns Its Place
FAQ blocks spread when FAQ rich results were widely shown. Google now shows them for very few sites, so a large number of pages carry questions nobody reads that repeat content already above them. Removing every block is also wrong, and whether the blocks help in AI answer engines is argued both ways with little evidence either side. Judge each block on whether the questions are real and whether the answers belong in the body instead.
## What you need first
- The page, its FAQ block, and the FAQPage markup as rendered
- Search Console queries for the page, to see which questions people actually arrive with
- Scroll depth or engagement data for the block if you have it, otherwise a judgment on its placement
## Method
1. Check whether an FAQ rich result has shown for this site at all in recent months. If not, the markup is not a reason to keep the block and the decision is purely about the reader.
2. Match each question against queries the page actually receives. Questions invented to fill the block are the first cut.
3. For surviving questions, check whether the body already answers them. A duplicated answer lengthens the page and splits the passage that could otherwise be lifted into a snippet.
4. Move genuinely new answers into the body at the point the reader meets the topic, and drop the question form. A question answered at the foot of the page is answered after the reader has gone.
5. Keep a short block only where the questions are genuinely peripheral to the page: returns terms on a product page, cancellation terms on a pricing page. That is a real use and the foot of the page is the right place for it.
6. Remove the FAQPage markup along with any block you delete, in the same deploy, so the markup never describes content that is not on the page.
7. Never mark up questions that are not visible in the rendered page, including answers hidden behind an accordion that does not load. Markup that contradicts the page is a straightforward guideline breach.
## What this produces
A keep, rewrite or remove decision per block, with surviving answers relocated into the body and the markup changes that go with each.
## Where this goes wrong
- Keeping a block for the schema alone when no rich result has shown for this site in months
- Deleting a whole block and losing the two answers that were the only place a real question was addressed
- Answering the same question in the body and in the block, which pads the page and splits the passage a snippet could use
- Leaving FAQPage markup behind after the visible block is gone
---
From the QuQi skill library - https://www.quqi.io/skills/faq-block-decision
Free to download · no account, no email
What you need first
-
The page, its FAQ block, and the FAQPage markup as rendered
-
Search Console queries for the page, to see which questions people actually arrive with
-
Scroll depth or engagement data for the block if you have it, otherwise a judgment on its placement
Method
-
01
Check whether an FAQ rich result has shown for this site at all in recent months. If not, the markup is not a reason to keep the block and the decision is purely about the reader.
-
02
Match each question against queries the page actually receives. Questions invented to fill the block are the first cut.
-
03
For surviving questions, check whether the body already answers them. A duplicated answer lengthens the page and splits the passage that could otherwise be lifted into a snippet.
-
04
Move genuinely new answers into the body at the point the reader meets the topic, and drop the question form. A question answered at the foot of the page is answered after the reader has gone.
-
05
Keep a short block only where the questions are genuinely peripheral to the page: returns terms on a product page, cancellation terms on a pricing page. That is a real use and the foot of the page is the right place for it.
-
06
Remove the FAQPage markup along with any block you delete, in the same deploy, so the markup never describes content that is not on the page.
-
07
Never mark up questions that are not visible in the rendered page, including answers hidden behind an accordion that does not load. Markup that contradicts the page is a straightforward guideline breach.
What this produces
A keep, rewrite or remove decision per block, with surviving answers relocated into the body and the markup changes that go with each.
Where this goes wrong
-
Keeping a block for the schema alone when no rich result has shown for this site in months
-
Deleting a whole block and losing the two answers that were the only place a real question was addressed
-
Answering the same question in the body and in the block, which pads the page and splits the passage a snippet could use
-
Leaving FAQPage markup behind after the visible block is gone
Use this skill in your own AI
The download is a plain markdown file with the name and trigger in its frontmatter. Where an assistant supports skills it can load itself, that frontmatter is what it reads to decide this one applies.
Claude Code
Save it as ~/.claude/skills/faq-block-decision/SKILL.md and Claude loads it on its own when what you are doing matches the trigger line. Put it in .claude/skills inside a project instead if the whole team should have it.
Claude
Upload the file in the skills section of your settings. Once it is there it applies itself in any conversation where the trigger fits, so you do not have to remember it exists.
ChatGPT
There is no skills format to install into, so paste the file contents into a Project instruction or a Custom GPT instead. It then applies to every chat in that project rather than only the one you paste it into.
Anything else
Paste the markdown into the chat before your question. It works in any assistant, it just has to be pasted again each time.
Questions about this skill
When do I judge blocks one by one rather than keep them all or delete them all?
When a page carries an FAQ block added for rich results. The two obvious moves are both wrong: keeping every block for the schema, when FAQ rich results now show for very few sites, or deleting them all and losing the answers that were the only place a real question got addressed. Whether the blocks help AI answer engines is argued both ways.
What do I need in hand before starting?
The block, the FAQPage markup as rendered, and Search Console queries for the page so you can see which questions people actually arrive with. Without the query data you keep whichever questions sound plausible, which is how the block was written in the first place. Engagement or scroll data helps, but placement judgment substitutes adequately.
What do I end up with, and which part gets used?
A keep, rewrite or remove verdict per block, with surviving answers relocated into the body and the markup change for each. The relocation is the useful half. An answer at the foot of the page is delivered after the reader has gone, and moved into the body it also becomes a passage a snippet can lift.
What most often ruins this?
Deleting the visible block and leaving the FAQPage markup behind. Markup describing content that is not on the page is a straightforward guideline breach, and it will sit there for months because nothing visibly breaks. The same applies to questions inside an accordion that never loads. Ship the block change and the markup change in one deploy.
More in On-page SEO