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.

O ficheiro da competência

---
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.

## O que precisa primeiro

- 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

## Método

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.

## O que isto produz

A keep, rewrite or remove decision per block, with surviving answers relocated into the body and the markup changes that go with each.

## Onde isto corre mal

- 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

---

Da biblioteca de competências da QuQi - https://www.quqi.io/pt/skills/faq-block-decision

O que precisa primeiro

• 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

Método

1. 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.
2. 02 Match each question against queries the page actually receives. Questions invented to fill the block are the first cut.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.

O que isto produz

A keep, rewrite or remove decision per block, with surviving answers relocated into the body and the markup changes that go with each.

Onde isto corre mal

• 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 esta skill na sua própria IA

O ficheiro é markdown simples, com o nome e o gatilho no frontmatter. Quando um assistente consegue carregar skills sozinho, é esse frontmatter que lê para decidir que esta se aplica.

Mais em SEO on-page