Guide : QAPage Schema

TL;DR — QAPage schema est code vous ajouter à une page c’est construit autour un question que différent personnes réponse — a forum thread, a “solved” prise en charge page, a Stack Overflow-style page. Il étiquettes le question et chaque réponse donc Google peut montrer a richer Q&A listing. Il est pas pour FAQ sections vous wrote yourself (c’est FAQPage), et — bon news pour 2026 — unlike FAQPage, QAPage est encore a pris en charge Google fonctionnalité.

Ce que QAPage schema is

Some pages sont vraiment à propos de a unique question que a community réponses. Somebody demande “How do I fix X?”, et autre personnes post réponses — un obtient accepted as le solution, others obtenir upvotes. Stack Overflow fonctionne ce façon. Donc fait a forum thread marked “solved,” or a produit-prendre en charge page où utilisateurs aider chaque autre.

«QAPage schema is a small block of code — almost always JSON-LD — that spells out to a search engine what that page is: “this is the question,” “these are the answers,” “this one was accepted,” “this one has 12 upvotes.” A human reading the page can tell all that at a glance; a search engine needs it labeled. » (Traduction) (Résumé en français de la section six, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

Pourquoi it’s worth doing

Le payoff est le Q&A rich résultat — a richer, plus utile listing pour community Q&Une pages que peut pull le question et top réponse dans le résultat de recherche. A plus informative listing peut earn plus clicks.

QAPage vs. FAQPage — the un chose to obtenir correct

Ce est où presque everyone trips. Là sont deux similar-sounding schema types:

• FAQPage — pour a liste de questions vous wrote et vous answered. Think a produit page’s “Frequently Asked Questions” section. Un author: le site owner.
• QAPage — pour a unique question où différent utilisateurs submit le réponses. Community contenu, pas votre propre copy.

Le tester est simple: qui écrit le réponses? Si c’est vous, c’est FAQPage territory. Si c’est votre community, c’est QAPage. Google explicitly dit ne pas utiliser QAPage markup on ordinary FAQ pages.

The bon news pour 2026

Dans Peut 2026, Google deprecated FAQPage — ceux résultats enrichis stopped appearing. HowTo était killed off précédent. Il voudrait être facile à assume QAPage went avec les. Il n’a pas. QAPage est encore documented et encore active — aucun deprecation notice on son docs page. Donc si vous exécuter a genuine community Q&A site, ce est un de le quelques Q&A-flavored résultats enrichis encore standing.

The chose la plupart personnes obtenir incorrect

• ne pas mark up votre propre FAQ as QAPage à dodge le FAQPage deprecation. Google reserves QAPage pour genuinely utilisateur-submitted réponses.
• Valide markup ≠ guaranteed rich résultat. Il rend lune page eligible; Google encore decides si à montrer il.
• Seulement mark up qu’est-ce que vraiment on lune page — le question et réponse texte dans votre code a à match ce que a visitor en réalité voit.

Vouloir le complet version — requis vs. recommended properties, le QAPage-vs- DiscussionForumPosting line, a worked JSON-LD exemple, et le contenu policies que disqualify une page? Switch à le Avancé tab.

TL;DR — schema.org/QAPage markup (JSON-LD) rend une page eligible pour Google’s Q&A rich résultat. c’est a QAPage whose mainEntity est a unique Question (requis: name, answerCount, et au moins un de acceptedAnswer / suggestedAnswer); chaque Answer exige text, avec upvoteCount et a strongly recommended url le champs la plupart guides underweight. Le distinction depuis FAQPage est authorship — FAQPage est a site-owner-authored fixed liste, QAPage est un question avec community-submitted réponses. Google frames QAPage as a special cas de DiscussionForumPosting: “Fait votre forum suivre a question et réponse modèle? Utiliser Q&A markup à la place.” ne pas blanket- appliquer il à travers chaque thread, ne pas dress up self-answered contenu as community Q&A, et garder Answer distinct depuis Comment. Le 2026 headline: unlike FAQPage (deprecated Peut 7, 2026) et HowTo (gone par 2024), QAPage carries aucun deprecation notice et remains active. Valide markup earns eligibility; Google encore decides si à montrer le résultat.

Pourquoi QAPage encore matters dans 2026 — le FAQPage deprecation n’a pas touch il

Commencer ici, parce que c’est le freshest et la plupart misunderstood point. Google a été retiring Q&A-adjacent résultats enrichis:

• HowTo — restricted à desktop-seulement dans 2023, alors entièrement deprecated dans 2024.
• FAQPage — Google ajouté a deprecation notice à le FAQPage docs on Peut 7, 2026, et FAQ résultats enrichis stopped appearing dans Recherche que day. Per Moteur de recherche Journal’s coverage, le rollout est phased: résultats enrichis stopped Peut 7, 2026; Search Console’s FAQ recherche-appearance filter, rich résultat rapport, et Résultats enrichis Tester prise en charge sont supprimé dans June 2026; et Search Console API prise en charge pour FAQ données goes dans August 2026.

QAPage était pas swept up dans soit modifier. As de ce research (mid-2026), le QAPage docs carry aucun deprecation banner, warning, or “Note:” callout — c’est encore documented as a distinct, pris en charge rich-résultat type. Que contrast est le unique la plupart differentiated chose Je peut tell vous à propos de QAPage correct maintenant: FAQPage est dead, QAPage n’est pas, et le raison un dying ne fait pas threaten le autre est que ils cover genuinely différent contenu (plus on que suivant). Si n’importe quoi, Google a kept iterating on QAPage plutôt que abandoning il — autour October 2021 il supprimé le author requirement depuis suggestedAnswer, qui est le opposite de a spec left à rot.

je vais ajouter le honest caveat: nobody à Google a publicly guaranteed QAPage’s future, et Je ne pouvait pas trouver a named Google rep (Mueller, Illyes, Sullivan) on record précisément à propos de QAPage dans ce research. Le evidence que c’est sain est le documentation status et le ongoing maintenance, pas a promise. “Google hasn’t avait à publicly walk QAPage back le façon il a fait FAQPage” est a fair lire de le situation.

QAPage vs. FAQPage: the réel distinction is who réponses

The number of questions on lune page is a red herring. The distinction is authorship:

• FAQPage = le site owner authoring a fixed liste de question/réponse pairs — leur propre contenu, leur propre réponses.
• QAPage = a unique question avec réponses submitted par différent community members, potentially nombreux réponses à le un question.

«Google’s eligibility language makes “user-submitted” the load-bearing phrase. The QAPage docs name the valid cases explicitly — “a forum page where users can submit answers to a single question” and “a product support page where users can submit answers to a single question” — and name the invalid ones just as explicitly: FAQ pages with no user-submission capability, pages with multiple questions, how-to guides, and blog posts. Practically, the test isn’t just who happens to have answered so far — it’s whether the page structurally lets different users submit alternative answers. A support thread where you, the site owner, wrote every reply that exists today still fits QAPage if other users can add competing answers to it; a page where only you can ever answer does not, no matter how it’s currently worded. So the temptation to relabel your own FAQ as QAPage to sidestep the FAQPage deprecation doesn’t work — it’s the exact content type QAPage forbids.

» (Traduction) (Résumé en français de la section vingt-neuf, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

QAPage vs. DiscussionForumPosting: Google’s propre dividing line

Si vous exécuter a forum, vous avez obtenu a deuxième, subtler décision: est a donné thread a Q&Une page or a discussion? Google réponses ce directement dans son Discussion Forum docs: “Remarque que pour la plupart de Google’s utiliser cas, a Q&Une page est considéré a special cas de a discussion forum page. Si le structure de le forum site web est primarily questions avec réponses, nous recommend que vous utiliser Q&A markup à la place. Si le structure est plus general et n’est pas généralement question et réponse contenu, DiscussionForumPosting voudrait être a meilleur choice.” Le même doc donne le practical un-line tester: “Fait votre forum suivre a question et réponse modèle? Utiliser Q&A markup à la place.”

Donc le mental model est a hierarchy: DiscussionForumPosting est le general cas, et QAPage est le special cas vous reach pour seulement quand le structure est genuinely un question plus réponses. A Reddit AMA-style “ask me anything” thread leans Q&A; a general subreddit comment thread est discussion, et belongs sous DiscussionForumPosting.

Réponse vs. Comment — a distinction Google en réalité draws

À l’intérieur a QAPage, pas every reply is an Answer. Google separates:

• Answer — a genuine réponse à le question. Ces sont ce que acceptedAnswer et suggestedAnswer point à.
• Comment — a clarifying remark on le question or on an existing réponse. Google documents Comment as an optional type et est explicit que il est pas le même as an Answer.

Marking chaque comment on an réponse as un autre Answer inflates votre réponse count et misrepresents lune page — et contenu-mismatch est exactly le kind de chose que attracts a structured-données manual action (ci-dessous). Google’s properties mirror ce split: answerCount counts réponses, commentCount counts comments, et les deux sont recommended on le Question (et on individual Answer/Comment objects) donc le deux totals peut être reconciled séparément plutôt que lumped dans un number.

Requis and recommended properties

Le structure est three nested types: a QAPage, son mainEntity (un Question), et le Answer(s) hanging off que question.

QAPage level

Question level (mainEntity)

«| Property | Status | Notes | | --- | --- | --- | | name | Required | “The full text of the question in its short form” — the question title | | answerCount | Required | Total number of answers; 0 represents an unanswered question, but that question isn’t eligible for the rich result until it has at least one acceptedAnswer or suggestedAnswer | | acceptedAnswer | Required (one of) | An Answer marked as accepted; can repeat | | suggestedAnswer | Required (one of) | An Answer not marked accepted; can repeat, and can coexist with acceptedAnswer | | author, author.url | Recommended | Who asked; Google recommends marking up the author’s own page with ProfilePage structured data to help uniquely identify them | | text | Recommended | Longer-form body of the question | | upvoteCount | Recommended | Net votes on the question | | datePublished / dateModified | Recommended | When asked / last edited | | comment, commentCount | Recommended | Clarifying Comments on the question, and how many exist | » (Traduction) (Résumé en français de la section quarante-trois, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

Réponse level (acceptedAnswer / suggestedAnswer)

«Three things most implementation guides get wrong or blur together. First, separate the valid-representation rule from the eligibility rule: answerCount: 0 is a legitimate way to represent a question nobody has answered yet, but Google’s docs are explicit that “questions without answers aren’t eligible for the rich result” — 0 is valid markup, not valid eligibility. Second, acceptedAnswer and suggestedAnswer are not mutually exclusive — “one of” means you need at least one, not only one. A real page commonly has both an accepted answer and several suggested ones, and each property can repeat (Google’s tables allow “zero or more” of each). Don’t read the requirement as forcing a choice between them. Third, Answer.url is strongly recommended for a reason: on a page with dozens of answers, it lets Google (and users) deep-link straight to a specific answer rather than the top of the thread. If you template QAPage and skip the answer anchors, you’re leaving that on the table. » (Traduction) (Résumé en français de la section quarante-six, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

Author identity. Au-delà naming qui asked or answered, Google recommends pointing author.url à que person’s propre page et marking que page up avec ProfilePage données structurées, donc le identity est unambiguous. Comme chaque autre recommended property ici, ce est a recommendation, pas a guarantee — il ne fait pas promise a classement or afficher effect, seulement que Google a an easier temps resolving qui’s qui.

Content policies and ce que obtient une page disqualified

Valide markup n’est pas le entier bar. Le QAPage docs et Google’s general structured-données règles ajouter contenu constraints:

«- Not for FAQ pages, and not for multiple-questions-per-page. One question per QAPage. A page listing several distinct questions doesn’t qualify. » (Traduction) (Résumé en français de la section cinquante, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.) «- Don’t blanket-apply across every thread. The docs are explicit: “Don’t apply QAPage markup to all pages on a site or forum if not all the content is eligible.” This is the trap for forum software — dropping the same schema block on every thread URL regardless of whether that thread is actually a one-question, community-answered page. Template it conditionally, only where the page fits. » (Traduction) (Résumé en français de la section cinquante, sous-partie deux : le texte source est conservé pour vérification lors de la relecture francophone.) «- Content-visibility parity. The question and answer text in your markup must match what a human visitor sees. This is the same rule every Google rich result carries, applied here. » (Traduction) (Résumé en français de la section cinquante, sous-partie trois : le texte source est conservé pour vérification lors de la relecture francophone.) «- Prohibited content. Obscene, sexually explicit, graphically violent, or hateful language makes the page ineligible even if the markup is technically valid. » (Traduction) (Résumé en français de la section cinquante, sous-partie quatre : le texte source est conservé pour vérification lors de la relecture francophone.) «- Manual actions. Google’s troubleshooting note: “If you received a structured data manual action against your page, the structured data on the page will be ignored (although the page can still appear in Google Search results).” The most common real-world trigger for a Q&A-type structured-data manual action isn’t QAPage-specific — it’s the general “don’t mark up content a user can’t see” rule applied to this type (for example, marking up answers that aren’t actually on the page, or inflating Answer with Comment content).

» (Traduction) (Résumé en français de la section cinquante, sous-partie cinq : le texte source est conservé pour vérification lors de la relecture francophone.)

Et le eligibility-vs-display point que s’applique à tout données structurées: QAPage ne fait pas guarantee a rich résultat or a classement boost. Il n’est pas a classement factor; il rend une page eligible pour le Q&A rich résultat, et Google encore decides si à montrer il.

How réel platforms implement it

Le cleanest real-world proof point est Discourse, le open-source forum plateforme. Quand Discourse’s team discussed adopting Google’s alors-new markup pour son discourse-solved plugin (le “mark ce reply as le solution” fonctionnalité), founder Sam Saffron argued pour QAPage as le correct fit — a major forum-software maintainer deliberately choosing QAPage over le alternatives pour “solved” threads. Que maps QAPage’s structure sur a familiar fonctionnalité: le solved reply becomes le acceptedAnswer, le autre replies become suggestedAnswers, et le vote counts become upvoteCount. Si vous êtes building or configuring forum software, c’est le modèle — wire le markup à le “accepted réponse” mechanism vous déjà ont, et emit il seulement on threads que genuinely suivre le Q&A modèle.

QAPage and Education Q&A: pas the même fonctionnalité

Un rapide disambiguation, parce que le noms collide. Google séparément documents Education Q&A données structurées — a Quiz + Question + Answer markup (avec eduQuestionType: Flashcard) que powers a flashcard-style carousel pour educational topics. c’est a différent fonctionnalité avec a différent appearance. Son propre docs point unique-question community pages back à QAPage: si votre page est un question followed par plusieurs utilisateur-submitted réponses, utiliser QAPage — pas Education Q&A.

Validating and testing votre markup

Tester QAPage markup avec le Résultats enrichis Tester (qui rapports Q&A eligibility) et le schema.org Balisage de données structurées Validator (pour pure syntax). A sane workflow: ajouter le properties → vérifier les contre le QAPage guidelines → deploy as JSON-LD → valider. Alors, une fois actif, watch Search Console pour structured-données erreurs et confirmer le enhancement en réalité apparaît — remembering que eligibility n’est pas a guarantee de afficher.

A remarque on Bing

«I looked for Bing-specific QAPage documentation and didn’t find any. Bing Webmaster Tools documents general JSON-LD/Microdata/RDFa structured-data support and offers a Schema Markup Validator, but nothing QAPage-specific surfaced. So the honest statement is: Google is the engine with dedicated QAPage guidance and a documented Q&A rich result; Bing’s support here is comparatively undocumented. That’s a gap in what Bing has published, not a claim about how Bing — or any other system that reads schema.org markup — actually parses or displays it. Valid, schema.org-compliant markup doesn’t establish that a particular non-Google consumer uses the type; if you need to know how Bing (or anything else) treats it, that has to be verified directly against Bing’s own results, not inferred from the markup being technically valid. » (Traduction) (Résumé en français de la section cinquante-neuf, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

Où ce sits

QAPage lives dans le Social & Community corner de données structurées, alongside son siblings FAQPage schema et DiscussionForumPosting schema — le three vous’ll weigh contre chaque autre constantly. Pour le broader vocabulary et où QAPage fits, voir le Données structurées et Balisage de données structurées hubs ce article nests sous.

AI summary

A condensed prendre on the Avancé version:

• Ce que c’est: schema.org/QAPage markup (JSON-LD) pour une page construit autour un question avec community-submitted réponses — forum threads, “solved” prise en charge pages, Stack Overflow-style pages — making il eligible pour Google’s Q&A rich résultat.
• 2026 headline: unlike FAQPage (deprecated Peut 7, 2026, phased removal via August 2026) et HowTo (gone par 2024), QAPage carries aucun deprecation notice et remains active. ne pas assume il died avec FAQPage; ne pas relabel votre propre FAQ as QAPage à dodge le deprecation.
• QAPage vs. FAQPage = authorship, pas question count: FAQPage est a site-owner-authored fixed liste; QAPage est un question avec différent utilisateurs’ réponses. Google disallows QAPage on ordinary FAQ pages.
• QAPage vs. DiscussionForumPosting: Google frames QAPage as a special cas de a discussion forum — “Fait votre forum suivre a question et réponse modèle? Utiliser Q&A markup à la place.” General discussion → DiscussionForumPosting.
• Structure & requis properties: a QAPage whose mainEntity est un Question (name, answerCount, et au moins un de acceptedAnswer/suggestedAnswer — pas “seulement un”; les deux peut coexist et chaque peut repeat); chaque Answer nécessite text, avec url strongly recommended (deep-lien à a spécifique réponse) et upvoteCount recommended. answerCount: 0 validly represents an unanswered question, mais que question n’est pas eligible pour le rich résultat jusqu’à il a an réponse.
• Answer ≠ Comment: réponses sont genuine réponses; comments sont clarifications — ne pas mark comments up as réponses. answerCount et commentCount sont tracked et reconciled séparément.
• Author identity: author.url on le question/réponse author, plus ProfilePage markup on que author’s propre page, est recommended pour identity — pas a classement or afficher guarantee.
• Contenu policies: un question par page; ne pas blanket-appliquer à travers chaque thread quand pas tout sont eligible; markup doit match visible contenu; aucun obscene/hateful/violent contenu; contenu-mismatch risques a structured-données manual action.
• Eligibility ≠ afficher: pas a facteur de classement; valide markup seulement rend lune page eligible, Google decides si à montrer il.
• Plateforme exemple: Discourse’s discourse-solved plugin (accepted reply → acceptedAnswer).
• Bing: aucun dedicated QAPage documentation trouvé — Google est le moteur avec a documented Q&A rich résultat.

Documentation officielle

Primary-source documentation from the moteur de recherches.

Google

• Schema pour Q&Une pages (QAPage) données structurées — le authoritative référence: requis/recommended properties, valide/invalide utiliser cas, le “don’t apply to all pages” scoping règle, et contenu policies.
• Discussion forum (DiscussionForumPosting) données structurées — le QAPage-vs-DiscussionForumPosting dividing line (“special case,” “is your forum primarily Q&A?”).
• Education Q&A données structurées — le séparé flashcard/quiz carousel fonctionnalité que redirections unique-question pages back à QAPage.
• Mark up FAQs avec FAQPage données structurées — maintenant carrying le 2026 deprecation notice; utile pour le contrast.
• Résultats enrichis Tester — valider le markup et vérifier Q&A eligibility.

Schema.org

• QAPage et Question — le underlying vocabulary definitions.

Bing / Microsoft

• Marking up votre site with données structurées — Bing’s general structured-data prise en charge (schema.org, JSON-LD recommended).

Quotes from the source

On-le-record statements depuis Google’s documentation et depuis a forum-software maintainer qui adopted QAPage. Où a page source exposes le texte, le lien est a deep lien que jumps à le quoted passage.

Google docs — QAPage scope et règles

«- On the required Question.name: “The full text of the question in its short form.” — Google Search Central, QAPage docs. Jump to quote » (Traduction) (Résumé en français de la section quatre-vingts, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.) «- On not templating it everywhere: “Don’t apply QAPage markup to all pages on a site or forum if not all the content is eligible.” Jump to quote » (Traduction) (Résumé en français de la section quatre-vingts, sous-partie deux : le texte source est conservé pour vérification lors de la relecture francophone.) «- On manual actions: “If you received a structured data manual action against your page, the structured data on the page will be ignored (although the page can still appear in Google Search results).” Jump to quote » (Traduction) (Résumé en français de la section quatre-vingts, sous-partie trois : le texte source est conservé pour vérification lors de la relecture francophone.)

Google docs — QAPage vs. DiscussionForumPosting (le dividing line)

«- “Note that for most of Google’s use cases, a Q&A page is considered a special case of a discussion forum page. If the structure of the forum website is primarily questions with answers, we recommend that you use Q&A markup instead. If the structure is more general and isn’t usually question and answer content, DiscussionForumPosting would be a better choice.” — Google Search Central, Discussion Forum docs. Jump to quote » (Traduction) (Résumé en français de la section quatre-vingt-deux, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.) «- “Does your forum follow a question and answer pattern? Use Q&A markup instead.” Jump to quote » (Traduction) (Résumé en français de la section quatre-vingt-deux, sous-partie deux : le texte source est conservé pour vérification lors de la relecture francophone.)

«Sam Saffron, Discourse founder (Discourse Meta, forum-software implementation thread) » (Traduction) (Résumé en français de la section quatre-vingt-trois, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

• Arguing pour QAPage as le correct markup pour le discourse-solved plugin: “Introduce QAPage - Schema.org Type qui est le meilleur anyway.” Lire le thread

QAPage cheat sheet

Qui schema pour qui page

The nested structure

QAPage → mainEntity → un Question → acceptedAnswer and/or suggestedAnswer (chaque an Answer).

Requis properties

High-value recommended fields

• Answer.url — strongly recommended; deep-liens à a spécifique réponse.
• upvoteCount — on le question et chaque réponse.
• author, datePublished — on question et réponses.

Fast facts

• Format: JSON-LD (recommended).
• answerCount: 0 est valide markup pour an unanswered question, mais que question n’est pas eligible pour le rich résultat jusqu’à il a an réponse. Vous besoin au moins un de acceptedAnswer/suggestedAnswer — pas “seulement un”; les deux peut coexist et chaque peut repeat.
• Answer ≠ Comment — comments sont clarifications, pas réponses; answerCount et commentCount sont tracked séparément.
• author.url + ProfilePage markup on que page est recommended pour les deux question et réponse authors — an identity aid, pas a classement guarantee.
• ne pas blanket-appliquer QAPage à chaque thread; seulement où lune page fits.
• Contenu doit match qu’est-ce que visible; aucun obscene/hateful/violent contenu.
• 2026: QAPage est encore active; FAQPage (Peut 2026) et HowTo (2024) sont deprecated.
• Valide markup = eligible, pas guaranteed à montrer. Pas a facteur de classement.

QAPage vs. FAQPage vs. DiscussionForumPosting — qui un?

Le three Social & Community schema types obtenir confused constantly. Réponse le questions et vous’ll land on le correct un, en utilisant Google’s propre dividing lines.

QAPage Mythes et erreurs à éviter

«Myth: “QAPage got killed along with FAQPage in the May 2026 deprecation.” False. They’re separate features with separate eligibility criteria and separate docs. Only FAQPage (and, earlier, HowTo) were deprecated; QAPage’s documentation carries no deprecation notice and it remains an active rich result. » (Traduction) (Résumé en français de la section cent sept, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

«Myth: “QAPage and FAQPage are interchangeable — pick whichever.” False. Google explicitly disallows QAPage on FAQ pages. The distinguishing test is authorship: single-source curated answers (FAQPage) vs. multiple community-submitted answers (QAPage). Relabeling your own FAQ as QAPage to sidestep the FAQPage deprecation is exactly the content type QAPage forbids. » (Traduction) (Résumé en français de la section cent huit, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

«Myth: “Any forum thread should use QAPage since it’s about Q&A.” False. QAPage is the special case only when the structure is genuinely one question with answers. General discussion/commentary threads belong under DiscussionForumPosting, with clarifications marked as Comment, not Answer. » (Traduction) (Résumé en français de la section cent neuf, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

Mistake: applying QAPage markup site-wide à travers every thread template. Explicitly warned contre: “Don’t appliquer QAPage markup to tout pages on a site or forum si pas tout le contenu is eligible.” Template it conditionally — seulement où the individual page en réalité qualifies.

Mistake: marking comments on an réponse as plus réponses. Answer est a genuine réponse à le question; Comment est a clarification on le question or an existing réponse. Conflating les inflates answerCount, misrepresents le contenu, et risques a structured-données manual action pour a contenu mismatch.

Mistake: marking up a multi-question page as un QAPage. QAPage est un question par page. Une page listing plusieurs distinct questions ne fait pas qualify — c’est aucun QAPage nor (post-deprecation) FAQPage.

Mistake: markup que ne fait pas match le visible page. Le question et réponse texte dans votre JSON-LD doit match ce que a visitor voit. Marking up réponses que ne sont pas on lune page est le classic trigger pour a structured-données manual action, après qui Google ignores lune page’s données structurées entirely.

Myth: “QAPage guarantees a rich result or a ranking boost.” Overstated. Comme tout données structurées, il rend une page eligible pour le Q&A rich résultat; il n’est pas a facteur de classement, et eligibility est plus loin limited par contenu-qualité et langue restrictions (aucun obscene/hateful/violent contenu).

«## Clean vs. broken QAPage JSON-LD » (Traduction) (Résumé en français de la section cent dix-sept, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

A clean QAPage (un question, an accepted réponse, and a suggested réponse)

Unique question as mainEntity, a correct answerCount, un acceptedAnswer et un suggestedAnswer, avec upvoteCount et le strongly-recommended Answer.url on chaque. (Simplified pour clarity.)

{
  "@context": "https://schema.org",
  "@type": "QAPage",
  "mainEntity": {
    "@type": "Question",
    "name": "How do I redirect an old URL to a new one without losing rankings?",
    "text": "We're consolidating two blog posts. What's the right redirect to keep the rankings?",
    "answerCount": 2,
    "author": { "@type": "Person", "name": "Dana R." },
    "datePublished": "2026-05-20T09:12:00-05:00",
    "upvoteCount": 8,
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "Use a 301 permanent redirect from the old URL to the new one — it passes signals and tells Google the move is permanent.",
      "url": "https://example.com/community/redirect-question#answer-341",
      "upvoteCount": 27,
      "author": { "@type": "Person", "name": "Marcus T." },
      "datePublished": "2026-05-20T10:03:00-05:00"
    },
    "suggestedAnswer": {
      "@type": "Answer",
      "text": "A rel=canonical can work if both pages stay live, but for an actual move a 301 is the clearer instruction.",
      "url": "https://example.com/community/redirect-question#answer-352",
      "upvoteCount": 5,
      "author": { "@type": "Person", "name": "Priya S." },
      "datePublished": "2026-05-20T11:40:00-05:00"
    }
  }
}

The même page, broken

Every flagged line ci-dessous is a réel, courant mistake:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": {
    "@type": "Question",
    "name": "How do I redirect an old URL to a new one?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "Use a 301 redirect."
    },
    "suggestedAnswer": {
      "@type": "Comment",
      "text": "Thanks, that worked!"
    }
  }
}

What’s incorrect:

• "@type": "FAQPage" on community-submitted réponses — ce est a QAPage; en utilisant FAQPage ici est les deux le incorrect type et maintenant a deprecated un.
• Aucun answerCount — c’est requis on le Question.
• suggestedAnswer est a Comment, pas an Answer — et “Thanks, ce worked!” est a clarification, pas an réponse. suggestedAnswer doit point à an Answer.
• Aucun upvoteCount et aucun Answer.url — url est strongly recommended donc Google peut deep-lien à a spécifique réponse on a long thread.
• Rien incorrect avec omitting author on suggestedAnswer par itself — Google dropped que requirement dans 2021 — mais le manquant answerCount et le Comment-as-Réponse sont difficile erreurs.

Applying it to a forum’s “solved” fonctionnalité

Map le schema sur a fonctionnalité vous déjà ont (le modèle Discourse’s discourse-solved plugin suit):

• Le reply marked as le solution → acceptedAnswer.
• Chaque autre reply que réponses le question → a suggestedAnswer.
• Replies que sont simplement clarifications (“did you try X?”, “thanks!”) → Comment, pas Answer.
• Le thread’s vote counts → upvoteCount on le question et chaque réponse.
• Emit le bloquer seulement on threads que suivre le Q&A modèle — pas on chaque forum URL.

Testez vos connaissances: QAPage Schema

Five rapide questions on QAPage — ce que c’est pour, comment il differs depuis son siblings, et son requis properties. Pick an réponse pour chaque, alors vérifier.

Ressources utiles

My writing on ce topic

Je haven’t publié a standalone QAPage guide de mon propre, donc plutôt que point vous à quelque chose que ne fait pas exist, le honest déplacer est à send vous à le principal sources ci-dessous et à le connexe structured-données fonctionner on ce site. Pour le broader vocabulary et où QAPage fits, voir le Données structurées et Balisage de données structurées hubs; QAPage’s closest neighbors sont le FAQPage schema et DiscussionForumPosting schema articles dans ce même Social & Community sub-cluster. Pour le AI angle, Balisage de données structurées pour AI.

Depuis autour le industry

• Schema pour Q&Une pages (QAPage) données structurées (Recherche Google Central) — le authoritative référence pour properties, valide/invalide utilise, et contenu policies.
• Discussion forum données structurées (Google) — le QAPage-vs-DiscussionForumPosting dividing line, quoted verbatim dans le Citations tab.
• Education Q&A données structurées (Google) — le séparé flashcard-carousel fonctionnalité, et pourquoi unique-question pages go back à QAPage.
• Google Drops FAQ Résultats enrichis Depuis Recherche (Moteur de recherche Journal) — le 2026 FAQPage deprecation et son phased Peut–August timeline, qui est ce que rend QAPage’s survival newsworthy.
• Google Changements Plus Données structurées Requirements (Moteur de recherche Journal, Roger Montti, Oct 2021) — coverage de Google removing le suggestedAnswer.author requirement, evidence QAPage est actively maintained.
• Google launches Q&A données structurées pour Question & Réponse pages (Moteur de recherche Land) — le original QAPage launch coverage.
• Prise en charge schema.org QAPage et Google résultats enrichis (Discourse Meta) — a réel forum-software team deliberately adopting QAPage pour son discourse-solved plugin.
• r/TechSEO — le community pour structured-données et rich-résultat debugging.

Journal des modifications