DiscussionForumPosting markup suits pages where visitors, not your editors, write the posts and others reply. If your site hosts a community forum, a member discussion board or a social feed, this is the structured data type Google documents for it. Articles, blog posts and product reviews do not belong in it. The advice here is for forum owners, community managers and developers who maintain the page templates. Google does not guarantee any search feature from markup, so the realistic goal is accurate data that matches what the page shows.
Does your page count as a forum?
What Google's documentation covers
Google's discussion forum structured data page (Opens in a new tab) describes the markup for forum-style posts in which people share their own first-hand perspective. Three kinds of site are named: community forums about a topic, general forum platforms hosting varied subforums, and social platforms where users post and reply. For generic social media the parent type SocialMediaPosting applies with the same requirements.
The page also draws two lines. Content written by the publisher or its agents, such as articles and blog posts, is out of scope, and so are product reviews. For those, the page points to Article, ImageObject or VideoObject. If the site is mainly questions with answers, the page points to Q&A markup instead. Anything beyond those statements, such as how a mixed site should split its sections, is an inference you will have to make yourself.
Three questions that settle most cases
Practical suggestion for classifying a template: who wrote the main text, can other people respond to it, and is it a personal viewpoint rather than an editorial piece? Member-written, open to replies and personal points to a forum thread. Editor-written points to an article. One question with several submitted answers points to Q&A. These questions restate the documented boundaries in working form; they are not a quotation of the page.
| Page type | Fits the documented use? | What the page says to do |
|---|---|---|
| Member thread with replies | Yes | DiscussionForumPosting with Comment replies |
| Generic social media post | Yes, as the parent type | SocialMediaPosting, same requirements |
| One question, many submitted answers | Better served by Q&A | Use QAPage markup |
| Editorial article or blog post | No | Use Article and related types |
| Product review | No | Not covered by this markup |
| Category, topic or profile listing | Not as a post | Collection or ItemList |
Listing pages versus discussion pages
Per the documentation, list pages such as profiles, topics and categories should use Collection or ItemList, and a post should not be set as the main entity unless the page is a discussion page for it. For a single-post page, mainEntity or mainEntityOfPage identifies the primary post. The mistake to avoid is stamping a category page with markup that implies the whole page is the first thread in the list.
Building the markup: which properties matter
The required core for a post
For the post itself the documentation requires author (a Person or Organization), author.name, datePublished in ISO 8601 format, and one of text, image or video. The content property may be omitted for a post that is represented on another page through an external url. In plain terms, the minimum is who wrote it, when, and what it says.
Recommended properties for a post
The recommended set is author.url, comment, commentCount, creativeWorkStatus, dateModified, digitalSourceType, headline, image, interactionStatistic, isPartOf, sharedContent, text, url and video. Practical suggestion: add whatever your forum already stores and displays, and skip anything you would have to invent. A property you cannot back with a visible fact on the page is a liability, not a bonus.
Required and recommended properties for a reply
A reply, marked up as Comment, needs author, datePublished and one of text, image or video. Recommended properties mirror the post list: author.url, comment for nested replies, commentCount, creativeWorkStatus, dateModified, digitalSourceType, image, interactionStatistic, sharedContent, url and video.
| Property | Post | Reply | Practical note |
|---|---|---|---|
| author with name | Required | Required | Use the display name shown on the page |
| datePublished | Required | Required | ISO 8601 |
| text, image or video | One required | One required | Match what the page shows |
| author.url | Recommended | Recommended | Only if the profile is publicly reachable |
| dateModified | Recommended | Recommended | Update when the author edits |
| comment, commentCount | Recommended | Recommended | Reflect the real reply tree |
| interactionStatistic | Recommended | Recommended | Only counts the page displays |
| creativeWorkStatus | Recommended | Recommended | Deleted for removed posts kept for context |
| digitalSourceType | Recommended | Recommended | Declare machine-made content |
Deleted posts and machine-made content
Two details deserve attention. When a removed post stays in the thread for context, creativeWorkStatus can be set to Deleted. When content comes from a language model, digitalSourceType takes TrainedAlgorithmicMediaDigitalSource, and when it comes from a reply bot, AlgorithmicMediaDigitalSource. If the property is omitted, the content is assumed to be human-generated. A forum that allows assisted or automated replies should declare them rather than rely on that default.
Interaction statistics, images and shared content
The interactionStatistic property supports like, dislike, view, comment or reply, and share actions, and each InteractionCounter needs userInteractionCount and interactionType. Use only numbers your forum displays and can count reliably. For media, image holds inline images only, with no default, icon, placeholder or author images, while link-preview images belong inside the image field of a WebPage under sharedContent. Video uses inline VideoObject items.
Modeling threads and replies
Threaded and linear boards
The documentation separates two layouts. On a threaded forum, comments are nested in a tree matching the forum's own threading. On a linear forum, all replies are nested as comment items directly under the original post. If your interface indents replies to replies, you are threaded; if everything flows in one column, you are linear.
| Layout | How the replies are nested |
|---|---|
| Threaded | Each reply sits under the reply it answers |
| Linear | Every reply sits one level under the original post |
| Multi-page thread | The post url points to the first page; later pages can repeat the original post with the main page URL |
Threads that span several pages
For long discussions split over pages, the documentation says to set url to the first page's address. Practical suggestion: store that first-page address as the thread's canonical identifier in your database and have every page template read it from there, rather than deriving it from the current page number.
Example scenario: a retro electronics forum
Example scenario: a forum about repairing vintage audio gear has a thread where a member asks why a turntable motor hums. Four replies follow, and one of them is answered by the original poster. The board shows indented replies, so it is threaded. The developer marks the opening post as DiscussionForumPosting, nests the four replies as Comment items, and places the poster's answer beneath the reply it addresses. The thread has three pages, so the post url is always the first page's address. The forum's front page, which lists the newest threads, uses ItemList and does not mark any single thread as its main entity. A staff announcement pinned at the top is excluded from the markup, since it is the site's own content and not a member's post.
Full text, user content only
Two content guidelines apply to every thread: include the entire text of the post and of each comment shown on the page, and mark up only user-generated posts. Summaries, trimmed excerpts and moderator notices do not meet those rules.
Choosing a syntax
The page recommends Microdata or RDFa to avoid duplicating large blocks of text, and notes that JSON-LD remains fully supported. On forums with long posts the duplication argument is real, because JSON-LD puts the same text in the body and again in the script. Which syntax fits depends on how your templates are built, and that is a decision for your developer.
Keeping spam and thin threads out of the markup
Markup describes, it does not vouch
The documentation warns that spammy content or spammy markup can cause problems the Rich Results Test will not detect, and that structured data is ignored on pages with a manual action even though the page can still appear in results. For a forum owner this is a plain consequence: markup describes whatever is on the page, so spam threads you leave published are marked up along with everything else. Moderation therefore comes first. Rules for approval queues and link attributes are covered in the pieces on forum and community backlinks and on dofollow, nofollow, sponsored and ugc links, which share a page template with the markup discussed here.
Removed and hidden posts
If a moderator deletes a post, it should leave the markup along with the page. Where a placeholder stays for thread context, use the Deleted status the documentation describes. Practical suggestion: never carry the removed text into the markup; describe only what a visitor can see.
Login walls and crawl access
The rollout steps in the documentation ask you to make sure pages are not blocked by robots.txt, noindex or login requirements. Markup on a members-only section is invisible to a crawler that cannot open the page. Decide which sections are public first, then add markup only there.
Profiles and the ProfilePage page
Google's ProfilePage documentation (Opens in a new tab) describes markup for pages about a single person or organization. Valid uses include forum and social media user profiles, news author pages, blog about-me pages and employee pages. mainEntity is required and points to the Person or Organization. The page notes that discussion forum and Q&A data often involve several authors and that profile pages can be linked from authors. Practical suggestion: set author.url in your post markup to the public profile address so the two structures connect.
| Markup | Main focus of the page | Required core |
|---|---|---|
| DiscussionForumPosting | One post and its replies | author, datePublished, content |
| ProfilePage | One person or organization | mainEntity with a name |
| ItemList or Collection | A list of posts, topics or profiles | Not detailed on these pages |
For ProfilePage, the recommended dateModified should reflect human edits to the profile, not incidental changes such as new inbound links, and placeholder images should be omitted. Home pages that are mostly not profile content are not valid uses. Whether profile links are worth leaving for the member is a separate matter discussed in blog comment and profile links.
Thin threads
Not every thread is substantial. A one-line post with no replies adds little. The two documents say nothing about indexing such pages, so the following is a practical suggestion: consider noindex or merging for threads with almost no content, and read thin content: how to find and fix it for detection methods.
Rollout, testing and monitoring
The documented sequence
The documentation lists the steps: add the required properties and follow the guidelines, validate with the Rich Results Test and fix critical errors, deploy a few sample pages and inspect them with the URL Inspection tool, request recrawling if needed, and submit a sitemap. It notes that crawling can take several days.
- Decide whether the board is threaded or linear.
- Add the required properties to one thread template.
- Compare the markup text with the visible page text.
- Run the Rich Results Test and clear critical errors.
- Publish a handful of live threads and inspect them.
- Check that your sitemap includes the thread URLs.
- Watch the reports before extending the template to every section.
How long to watch before extending is not specified in the documentation, so choose an interval that suits how often your site is crawled.
What to monitor
After the first deployment and after template changes, check the rich result status report in Search Console. The performance report shows impressions, clicks and average position. Interface labels may differ slightly by account language, so look for the report names as they appear in your own Search Console. A jump in invalid items after a template change is your signal to compare against the previous version.
Common failures
| Symptom | Likely cause | Check |
|---|---|---|
| Missing required property | Author name or date empty for some posts | How closed accounts are stored |
| Date format error | Local format instead of ISO 8601 | Template date formatting |
| Replies absent from markup | Replies loaded after the page opens | Whether initial HTML contains the reply text |
| Stale text in markup | Cache serving an old version | Cache clearing on edit |
| Passes the test but no report data | Page blocked or not yet crawled | URL Inspection and robots rules |
Mapping forum data to properties
| Property | Source in your forum | May be empty? |
|---|---|---|
| author.name | Member display name | No |
| author.url | Public profile address | Yes, when profiles are private |
| datePublished | Creation time of the post | No |
| dateModified | Last edit time | Yes, when never edited |
| headline | Thread title | Yes, but supply it when a title exists |
| commentCount | Reply count shown on the page | Yes |
The mapping is a practical suggestion; the required versus recommended split comes from the documentation. If a member closed their account and the author name is empty, use the label the page shows rather than leaving the property blank or inventing a name.
Example scenario: an association forum with mixed content
Example scenario: a hobby association site posts board announcements in the same layout as member threads. The developer separates them. Announcements are the organization's own content and stay outside the forum markup. Member threads use DiscussionForumPosting, member pages use ProfilePage, and the thread index uses ItemList. Each change is validated on a small sample, then rolled out section by section.
Setting expectations
The documentation states that Google does not guarantee features that consume structured data will show up in search results. Treat the markup as a clear description of your pages. For a small site, a cleaner template and a better-defined content structure may be the main gain. Requirements in Google's pages can change, so check the current documentation before you implement.
If you have no forum
A site that only has blog comments under editorial posts does not host a forum in the documented sense, since blog posts are explicitly out of scope. Do not add this markup unless you operate a discussion area where members start and answer threads. Use Article for posts and consider QAPage only for single-question pages with submitted answers.
Template safety and ownership
Generating markup from stored data
Practical suggestion: generate the markup from stored fields instead of writing it by hand for each thread. That keeps the visible text and the data aligned, but it brings its own failure modes. User posts contain quotation marks, line breaks and unusual characters, so the generating code must escape them properly or the data block breaks and validators report errors. Edits matter too: when a member changes a post, the markup text and the dateModified value should change with it. If pages are cached, tie cache clearing to post edits so the old text does not linger in the markup.
Decision rule for each forum section
Practical suggestion: walk every section of the site through the same ordered questions.
- Is the section public and open to crawlers? If not, skip it.
- Are the posts written by members? If not, use a type that fits the content, such as Article.
- Is each page built around one question and its answers? If so, read the QAPage documentation instead.
- Is the page a list of threads, profiles or topics? If so, use ItemList or Collection and do not name a post as the main entity.
- Otherwise, use DiscussionForumPosting and nest replies according to the real layout.
Each step follows a boundary stated in the documentation; the order is chosen for convenience, not taken from the page.
Who owns which part
| Role | Responsibility | Hand-off |
|---|---|---|
| Community manager | Decides which sections hold member content and which are editorial | A short list of section types |
| Developer | Builds the template and the field mapping | A sample page for review |
| QA reviewer | Runs the validator, compares markup and visible text, checks crawl access | A pass or fail with notes |
On a small site one person may hold all three roles. Separating the steps still reduces mistakes, and re-running the validator after each template change should be a fixed part of the routine.
Pre-launch audit
Checklist
- Every marked-up page is public and not blocked by robots.txt, noindex or a login.
- Only member-written posts are marked up; staff notices and editorial pages are not.
- The full text of each post and each reply on the page appears in the markup.
- Required properties are filled for every post and reply, including edge cases such as closed accounts.
- Reply nesting matches the board layout, threaded or linear.
- Multi-page threads use the first-page address as url.
- Interaction counts match what the page displays.
- Machine-made replies, if allowed, carry the right digitalSourceType.
- The sitemap lists the thread URLs.
- Spam moderation is working, so that unwanted posts are not marked up.
Questions a reviewer can ask
If you review someone else's implementation, ask what is visible but not in the markup, and what is in the markup but not visible. The first gap suggests missing replies or truncated text. The second suggests invented counts, hidden content or stale cache. Either gap breaks the documentation's rule that the markup should reflect the post text and comments shown on the page.
What to do when the validator passes but nothing appears
A passing test only says the syntax is acceptable. Check whether the live page is reachable, whether it has been crawled, and whether a manual action applies. The documentation notes that structured data is ignored on a page with a manual action. Then wait: it also says crawling can take several days. Beyond that, there is no guarantee of any special result, and the documents offer no further diagnostic steps.
Frequently Asked Questions
Can I use DiscussionForumPosting for blog comments?
Google's documentation excludes content written by the publisher, such as articles and blog posts, and points to types like Article for it. Comments beneath an editorial post do not turn the page into a forum. A separate discussion area where members start threads is closer to the documented use.
What does a minimal DiscussionForumPosting need?
According to the documentation: author with author.name, datePublished in ISO 8601 format, and one of text, image or video. Replies need author, datePublished and one of text, image or video. Check the current page before implementing, since requirements can change.
Will the markup make my forum appear with a special result?
No guarantee exists. The documentation says Google does not guarantee that features consuming structured data will appear in results, and that structured data is ignored when a manual action applies to the page.
Should I mark up forum sections behind a login?
The documentation asks that pages are not blocked by robots.txt, noindex or login requirements. Markup that crawlers cannot reach has no use, so add it only to public sections.
How should I handle a deleted post that stays for context?
The documentation lets you set creativeWorkStatus to Deleted. As a practical suggestion, do not carry the removed text into the markup.
How are profile pages related to forum markup?
ProfilePage markup describes one person or organization and requires mainEntity. Forum and social media user profiles are listed as valid uses. Pointing author.url in your post markup to the public profile address links the two.
Conclusion
DiscussionForumPosting fits member-written, reply-driven pages and nothing else. The core is author, publication date and content, replies follow the real thread structure, and the markup must carry the full visible text of user posts. Moderate first, since markup also describes spam. Classify your sections, build one template, validate it, publish a small sample and watch the reports. Rich result features are not guaranteed and the documentation can change.
If you also want to earn links beyond your own community, the backlink packages are one option to consider.
Post a comment
Please log in to leave a comment. Login