What Is Discussion Forum Schema?

The primary type is DiscussionForumPosting, a subtype of SocialMediaPosting. It fits forum-style pages where users collectively share first-hand perspectives. The original post is the main entity, and replies can be nested as Comment nodes that preserve the visible conversation structure.

This markup is not for publisher-authored articles, product reviews or pages that merely allow comments. It describes genuine user-generated discussion. It cannot verify that a post is true, make a community trustworthy or guarantee placement in a discussion feature.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Use it only for user-generated posts.
• Represent the complete visible conversation.
• Source identities and counts from platform records.

Primary specification: Google Search discussion-forum structured data documentation.

DiscussionForumPosting schema models a real user-created conversation, not publisher content with a comment section.

A parser reads the canonical post, author, timestamp, text or media and interaction data. Direct replies can sit beneath the post; replies to comments can be nested below the relevant Comment. Stable URLs or fragments allow individual contributions to resolve to their visible location.

JSON-LD is supported, while Microdata or RDFa can reduce duplication when long user text already exists in the HTML. Regardless of format, the delivered markup must contain the same complete content. Syntax validation cannot detect moderation state, deleted content or fabricated counts.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Confirm the page is a user-created discussion.
2. Map the original post and author.
3. Preserve comment hierarchy.
4. Attach platform interaction data.
5. Validate rendered and moderation states.

The graph works when it preserves the real author, content, order, nesting and canonical location of the rendered discussion.

A thread debating SEO workflow choices is a general discussion. A page asking one technical question and accepting competing answers is closer to QAPage. A publisher-written FAQ uses neither discussion type merely because it contains questions.

Some communities mix formats. Classify each page template rather than the entire domain. If a question thread includes comments on answers, model the Q&A structure honestly instead of forcing every response into a flat forum post. Avoid using both primary types for the same entity unless the page genuinely supports a coherent relationship.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Inspect the page’s primary interaction.
• Separate questions, discussions and reviews.
• Apply the type per template or content object.

Use forum markup for general UGC discussion and QAPage for one user-answerable question, never based on desired appearance alone.

A text post should include the complete text found on the page. Media-first posts can rely on supported ImageObject or VideoObject relationships when the visible media is the primary content. The URL should resolve to the canonical discussion, and multi-page threads should maintain a deliberate thread-level identity.

Author nodes can link to creator profiles described with ProfilePage schema. Interaction counts should represent likes, shares or other supported actions on the hosting platform. Do not import unrelated social totals or estimated engagement.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Map the original author and time.
2. Represent complete visible content.
3. Set a stable discussion URL.
4. Nest approved replies accurately.
5. Add only reproducible platform counts.

Prioritize complete content, real authorship, timestamps and canonical identity before optional engagement enrichment.

A flat chronological list loses meaning when users reply to one another. Use nested Comment relationships for threads and keep display order consistent with the interface. If the platform supports multiple sort modes, structured output should follow a stable canonical representation rather than changing identities with every sort parameter.

Deleted, hidden, quarantined and pending comments need explicit editorial rules. Do not expose private or removed text in JSON-LD. If a moderation placeholder remains visible, the graph should not secretly contain the original prohibited content.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Preserve parent-child reply relationships.
• Respect moderation and privacy state.
• Use stable contribution permalinks.

Comment markup should reproduce the public conversation tree without leaking moderated, private or alternate-sort content.

A handle can change, so retain an internal identifier and stable profile URL where policy allows. Deleted or anonymous accounts require a consistent representation that does not expose private identity. Organizations can be authors when the account genuinely belongs to and speaks for that organization.

Like, share, follow and write counts need the correct InteractionCounter type and event source. Do not sum views, likes and comments into one engagement number. Bot-filtering, deleted reactions and asynchronous counters need a documented source of truth so the page and graph remain consistent.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Resolve stable public account identity.
2. Protect private and deleted-user data.
3. Define each interaction event.
4. Compute counts from authoritative ledgers.
5. Synchronize visible and structured totals.

Stable creator IDs and source-backed interaction counters preserve accountability without inventing popularity or exposing private users.

Long threads may span several URLs. Each page needs accessible navigation and a deliberate indexing strategy. The discussion’s structured URL can represent the first or canonical thread page, while comments on later pages still need crawlable paths if they are intended for discovery.

Do not canonicalize every paginated page to page one if that makes unique later content effectively disappear from discovery. Infinite-scroll interfaces need real paginated URLs or another crawlable architecture. Sort-order and tracking parameters should not generate independent forum entities.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Make important replies crawlable.
• Consolidate sort and tracking variants.
• Keep thread and contribution IDs stable.

A sound forum architecture preserves crawlable contribution URLs and one stable discussion identity without hiding valuable paginated content.

Large communities often have several renderers: desktop, mobile, app previews and cached versions. If each produces different comments or counts, the structured graph drifts. Third-party forum plugins can also duplicate custom JSON-LD or omit full text to save payload size.

Markup should not become a path around moderation. Spam, harassment, illegal content and private data remain unacceptable merely because users submitted them. Search eligibility is secondary to user safety and platform integrity.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Classify content origin and interaction model.
2. Compare public text and reply structure.
3. Test moderation state leakage.
4. Reconcile counters and author IDs.
5. Consolidate canonical thread URLs.

Forum markup quality depends on truthful UGC classification, conversation structure, moderation integrity and stable URL identity.