WEBサイトUGC Fresh Data Programは、投稿が主役のプラットフォームだけが対象 ── 自社が6つの条件に当てはまるかを判定する13項目（2026年10月時点）
UGC Fresh Data Programは、投稿が主役のプラットフォームだけが対象 ── 自社が6つの条件に当てはまるかを判定する13項目（2026年10月時点）
目次
01 何が起きたか — Googleが、投稿を速く届ける専用の窓口「UGC Fresh Data Program」の説明ページを10月8日に公開した
2026年10月8日に追加された説明ページ
Google検索セントラルの文書の更新履歴には、2026年10月8日の項目として、次の1行がある。2026年10月9日に開いて確かめた。
"Added documentation on the UGC Fresh Data Program"
（訳: UGC Fresh Data Programの文書を追加した。）
同じ項目は、追加の理由を、次のように書いている。
"To explain the purpose of the program and help prospective applicants understand the eligibility criteria and how to participate."
（訳: プログラムの目的を説明し、申請を考える人が、対象になる条件と、参加の方法を理解できるようにするため。）
説明ページの本文は、このプログラムを、次のように書き出している。
"The UGC Fresh Data Program is an initiative designed to help platforms display fresh, high quality, and authentic user-generated content (UGC) across various features on Search."
（訳: UGC Fresh Data Programは、プラットフォームが、新鮮で、質が高く、本物の利用者作成コンテンツ（UGC）を、検索のさまざまな機能に表示できるよう助ける取り組みである。）
UGCは、利用者が書いた投稿を指す。この記事の問いは1つで、自社のサイトが、このプログラムの対象になりうるのかである。先に答えを書くと、公式の条件を上から当てはめると、投稿が主役ではないサイトの多くは、最初の条件で外れる。その判定を、05章の13項目で、自分の手で行う。
「特定の種類の投稿だけ」の専用の流れ
説明ページは、このプログラムの範囲を、2文で限っている。
"The UGC Fresh Data Program is a specialized pipeline designed exclusively for trending UGC content."
（訳: UGC Fresh Data Programは、話題になっているUGCのためだけに設計された、専用の流れである。）
"It's independent of the Google Indexing API and traditional organic crawling for general web content."
（訳: これは、Google Indexing APIとも、一般のウェブの内容に対する従来の自然なクロールとも、独立している。）
2つめの文は、このプログラムが、通常のクロールとは別の流れであることを示している。ページの本文には、参加しないサイトに何かを求める文は、見つからなかった。この読み方は、本文を通して読んだ筆者の整理であり、公式がそう言い切っているわけではない。
載るとは限らない
"This program doesn't guarantee that content will appear in Search."
（訳: このプログラムは、内容が検索に表示されることを保証しない。）
参加できても、表示は保証されない。対象外であっても、それで何かが不利になる、という文はない。
出典
説明ページの末尾には「Last updated 2026-10-08 UTC.」（訳: 最終更新 2026年10月8日 UTC）とある。更新履歴の10月8日の項目と、日付が一致している。
02 なぜ・背景 — 申請して選ばれる形で、詳しい技術の文書は承認のあとに渡される
誰でも使える機能ではない
説明ページは、参加を限っている理由を、次のように書いている。
"Due to the technical requirements and the nature of the integration, participation is limited to platforms that meet specific content quality and volume guidelines."
（訳: 技術的な要件と、連携の性質のため、参加は、内容の質と量について決まった基準を満たすプラットフォームに限られる。）
申請の流れも、書かれている。申請しても参加は約束されず、返事は6〜8週間後である。
"Submitting an application doesn't guarantee participation in the program."
（訳: 申請を出しても、プログラムへの参加は保証されない。）
技術の詳細は、承認のあとに渡される
次の1文が、この記事の限界を決めている。
"We will share developer documents with more details once accepted into the program."
（訳: プログラムに受け入れられたあとに、より詳しい開発者向けの文書を共有する。）
つまり、データを実際にどう送るかは、2026年10月9日の時点で、公開されていない。この記事は、送り方を推測で書かない。書くのは、申請の前に、自社が条件に当てはまるかを判定するところまでである。
投稿の構造化データの文書は、前からある
投稿のページに付ける構造化データ（DiscussionForumPosting）の公式の文書は、今回のプログラムとは別に、前から公開されている。2026年10月9日に開くと、最終更新は2026年9月8日（UTC）だった。検索結果の「ディスカッションとフォーラム」の枠に、自社が出られているかを扱った記事は、当サイトの記事「「ディスカッションとフォーラム」枠はRedditが8割 ── Google検索で自社サイトが負けている場面を確認する14項目（2026年8月時点）」にある。この記事は、その内容を繰り返さない。
03 用語 — 読み違えやすい言葉を先にそろえる
UGC（利用者作成コンテンツ）
公式の説明ページは、UGCを、次のように定義している。
"UGC is any digital material hosted and distributed by an online platform or aggregator, but created entirely by independent users rather than the platform itself."
（訳: UGCとは、オンラインのプラットフォームや集約サイトが掲載し配信するが、プラットフォーム自身ではなく、独立した利用者がすべてを作ったデジタルの素材である。）
鍵は「entirely」（訳: すべて）である。自社が書いた記事の下に、利用者のコメントが付いているだけのページは、この定義の中心ではない。
DiscussionForumPostingとSocialMediaPosting
どちらも、投稿を表す構造化データの型である。公式の文書は、2つの関係を、次のように書いている。
"If your site is more like a generic social media platform, you can use SocialMediaPosting, which is the parent type of DiscussionForumPosting, with the same requirements."
（訳: 自社のサイトが、一般的なソーシャルメディアに近いなら、DiscussionForumPostingの親にあたる型のSocialMediaPostingを、同じ要件で使える。）
interactionStatistic（反応の数）
投稿へのいいねや閲覧、返信の数を書くための項目である。公式の文書は、対応する反応の種類として、いいね・低評価・閲覧・コメント・共有の数を挙げている。この項目の値が、画面に出ている数と合っているかは、自分で見比べるしかない。
用語
OAuth 2.0は、外部のサービスに、パスワードそのものを渡さずに、決まった範囲の権限だけを渡す方式である。公式の条件の4つめに出てくる。この記事は、設定のやり方には触れない。
04 型別 — 6つの条件を、自社のサイトに1つずつ当てはめる順番
🅰 適用範囲 — 投稿が主役のプラットフォームだけが対象
最初の条件は、次の文である。
"The platform must primarily host UGC, social postings, or forum discussions."
（訳: そのプラットフォームは、UGC、SNSの投稿、またはフォーラムの議論を、主に掲載していなければならない。）
続けて、投稿のページについて、次のように書いている。
"The UGC content should be hosted on dedicated pages with stable URLs, not on profile or feed pages."
（訳: UGCは、プロフィールやフィードのページではなく、安定したアドレスを持つ専用のページに置かれているべきである。）
企業の公式サイト・サービスの紹介サイト・採用サイト・自社で書くブログは、「主に」の部分で外れると読める。外れたら、残りの5つは確かめなくてよい。05章の項目2で「0か所」と書けたサイトは、項目13に進めば終わる。
🅱 この記事が確かめていないこと
注意
この記事は、申請の中身（申請のフォーム）を開いていない。承認されたサイトの数や、参加したあとの表示の変化も、2026年10月9日の時点では公表されておらず、確かめていない。「対象外と判断した」は、公式の条件に自社を当てはめた結果であり、Googleが判断した結果ではない。
🅲 手順1 — 投稿が主役かを、置き場の数で仕分ける
自社のサイトで、利用者が公開の場に書き込める場所を、数える。口コミの欄・掲示板・コメント欄・投稿のフォームである。0か所なら、ここで終わる。1か所以上ある場合は、その場所に出ている投稿を、直近1か月の本数で、利用者が書いたものと、自社が書いたものに分けて数える。
🅲 手順2 — 公開されているか、固有のアドレスがあるかを見る
3つめの条件には、公開についての文がある。
"Content must be on public web pages accessible to Googlebot and users; gated content (requiring a login or paywall to view) is ineligible."
（訳: 内容は、Googlebotと利用者がアクセスできる公開のウェブのページに置かれていなければならない。ゲートの内側の内容（見るのにログインや有料の壁が要るもの）は、対象外である。）
確かめ方は簡単で、ログアウトした状態で、投稿のページを開く。ログインを求められたら、その投稿は対象になれない。さらに、公式は、投稿が書いた人に結びつくことを求めている。
"Additionally, all UGC must be attributable to a creator with a public profile."
（訳: さらに、すべてのUGCは、公開のプロフィールを持つ作成者に結びつけられなければならない。）
実務のヒント
ログアウトの状態は、別のブラウザか、シークレットウィンドウで作る。同じブラウザのままだと、ログインの記憶が残り、「見える」と読み違えやすい。
🅲 手順3 — 構造化データの型と、必須の項目を確かめる
公式の構造化データの文書は、DiscussionForumPostingの使い方を、次のように限っている。
"Only use DiscussionForumPosting markup to describe a user-generated post on a website."
（訳: DiscussionForumPostingのマークアップは、ウェブサイト上の、利用者が作った投稿を表すためだけに使う。）
"Don't use this markup for content that's primarily authored by the publishers of the website or their agents."
（訳: このマークアップを、ウェブサイトの発行者やその代理人が主に書いた内容に使ってはならない。）
つまり、自社が書いた記事に、この型を付けると、型の使い方として合っていない。必須の項目は、書いた人の名前・投稿の日時・本文か画像か動画のどれかである。反応の数の項目（interactionStatistic）は、投稿の文書では「推奨」の側にあるが、今回のプログラムの説明ページは、条件の例に挙げている。書く場所はあっても、値が実際の数と合っていなければ意味がない。
| 公式の条件 | 自社で確かめること | 外れたときの読み |
|---|---|---|
| Content focus（中心の内容） | 投稿が主役か。投稿ごとに固有のアドレスがあるか | 自社が書く記事が主なら、対象外 |
| Volume and audience（量と利用者） | 直近1か月の投稿の本数と、利用者の数 | 公式は基準の数字を書いていない。数字は申請の側で聞く |
| Content accessibility（公開） | ログアウトで本文が見えるか。書いた人のプロフィールが公開か | ログインが要るなら、対象外 |
| Technical readiness（技術） | 投稿の型と必須の項目が、検査ツールで通るか | 通らないなら、先に直す。OAuthの準備は担当者に聞く |
| Content health and moderation（健全性） | 通報の仕組みがあるか。荒らしを止める手順があるか | 無いなら、申請の前に用意する |
| Content freshness（鮮度） | 投稿が公開のページに出るまでの時間。反応の数の更新 | 数分で出ないなら、条件の「できるだけ新鮮」に届かない |
🅲 手順4 — 通報の仕組みと、荒らしを止める手順を確かめる
5つめの条件は、安全の面の条件である。
"The platform must not publish illegal content and must maintain active content moderation, including a user reporting mechanism."
（訳: プラットフォームは、違法な内容を載せてはならず、利用者が報告する仕組みを含む、活発な内容の管理を続けなければならない。）
Googleの別の文書は、荒らしを減らす具体策を書いている。新しい利用者の投稿には、noindexを付けるという案も、その1つである。
"Since many comment spammers want their content in search engines, consider adding the noindex robots meta tag on posts that come from new users that don't have any reputation on your platform."
（訳: コメントのスパムを書く人の多くは、自分の内容を検索エンジンに載せたいので、プラットフォーム上で評判のない新しい利用者の投稿には、noindexのrobotsメタタグを付けることを考える。）
🅲 手順5 — 公開までの時間と、反応の数の更新を測る
6つめの条件は、時間についての条件である。
"Content submitted must be as fresh as possible, ideally sent within minutes."
（訳: 送られる内容は、できるだけ新鮮でなければならず、望ましくは数分以内に送られる。）
"Additionally, you must be able to submit regular updates of engagement counters (within 72 hours of creation)."
（訳: さらに、反応の数の定期的な更新を、（作成から72時間以内に）送れなければならない。）
確かめるのは、新しい投稿を1件出してから、公開のページに出るまでの秒数と、反応の数が画面でどう動くかである。
05 自分のサイトで確認するチェックリスト
下の13項目は、1項目5分ほどでできる作業である。項目1が公式の確認、項目2〜4が手順1と手順2、項目5〜7が手順2、項目8〜10が手順3、項目11が手順4、項目12〜13が手順5と、まとめの判定に対応している。項目2で「0か所」と書いたら、項目3〜12は飛ばして、項目13に進む。チェックの状態は、ブラウザの中にだけ保存され、サーバーには送られない。
- 公式の説明ページを開き、末尾の「Last updated」の日付（2026-10-08 UTC）と、条件の見出し6つ（Content focus・Volume and audience・Content accessibility・Technical readiness・Content health and moderation・Content freshness）を、メモに書き写す
- 自社のサイトで、利用者が公開の場に書き込める場所（口コミ・掲示板・コメント欄・投稿フォーム）を数え、「0か所」か「1か所以上」で書く（「0か所」なら項目13へ）
- 項目2で書いた場所のうち1つを選び、直近1か月の投稿の本数を、利用者が書いたものと自社が書いたものに分けて、別々に数えて書く
- 投稿のページを3つ開き、アドレスが投稿ごとに違うかを、「3件中◯件が固有」の形で書く（プロフィールやフィードのページを数えない）
- ブラウザのシークレットウィンドウで、投稿のページを1つ開き、本文がログインなしで見えるかを「見える」か「見えない」で書く
- 投稿を3件開き、書いた人の名前と、その人の公開のプロフィールへのリンクが付いているかを、「3件中◯件」で書く
- 投稿のページのHTMLを開き、DiscussionForumPostingかSocialMediaPostingの語を探して、「あり」か「なし」で書く
- 項目7が「あり」なら、そのページのアドレスをRich Results Test（リッチリザルトテスト）に入れ、エラーの数と警告の数を、書く
- 投稿の構造化データに、interactionStatistic（いいね・閲覧・返信などの数）があるかを、「あり」か「なし」で書く
- 投稿の構造化データの反応の数と、画面に出ている反応の数を、3件で見比べて、「3件中◯件が一致」の形で書く
- 投稿のページに通報の仕組みがあるかを探し、押して通報の画面が開くかを、「開く」か「開かない」で書く
- 新しい投稿を1件出し、公開のページに表示されるまでの秒数を、時計で測って書く。続けて、反応の数を1時間あけて2回読み、「変わる」か「変わらない」で書く
- 6つの条件のうち「満たす」の数を書き、1つでも満たさないものがあれば、「対象外と判断した」日付を書く（項目2で0か所の場合も、その日付を書く）
時間が限られているときは、項目2・5・11・13の4つだけでも、「投稿が主役か」「公開か」「通報の仕組みがあるか」「判定の日付」は決まる。
06 代替・他の選択肢 — 対象外のときと、対象でも申請しないとき
対象外なら、通常の流れで届ける
説明ページが書くのは、このプログラムが通常のクロールと独立している、ということだけである。対象外のサイトは、これまでどおり、サイトマップを出し、ページをGoogleが見つけて読む流れに任せる。投稿の構造化データの文書は、公開してから見つけられるまでの時間を、次のように書いている。
"Note: Allow time for re-crawling and re-indexing."
（訳: 注意: 再クロールと再インデックスの時間を見込むこと。）
同じ文書は、続けて、公開してから見つけられて読まれるまでに数日かかることがある、とも書いている。サイトマップを出す手順は、公式の文書でも勧められている。サイトマップを作る場面では、当サイトの無料ツール🔧 WEBサイトの sitemap.xml 作成ツールが使える。
注意
対象外だと分かったサイトが、自社の記事に、投稿の型を付けてはならない。公式の文書は、自社が主に書いた内容への使用を認めていない（手順3の引用）。
プログラムに申請せず、構造化データだけを入れる
公式の構造化データの文書は、この型の目的を、次のように書いている。
"Discussion forum markup is designed for any forum-style site where people collectively share first-hand perspectives."
（訳: ディスカッションフォーラムのマークアップは、人々が、自分で体験した見方を、みんなで共有する、フォーラムの形のサイトのために設計されている。）
投稿が主役のサイトは、プログラムに申請しなくても、この型を正しく入れる選択がある。入れたあとは、Rich Results Testで検査し、URL検査で、Googleがページをどう見るかを確かめる、と公式の文書は書いている。構造化データのたたきファイルを作る場面では、当サイトの無料ツール🔧 WEBサイト・構造化データ自動作成ツールが使える。
荒らしを減らす、公式の3つの手
投稿を受け付けるサイトに共通する、公式の文書の手を3つ挙げる。1つめは、新しい利用者の投稿にnoindexを付ける案（手順4の引用）。2つめは、信用できない内容のリンクに、nofollowかugcの属性を付ける案である。公式の文書は、ugcの値を勧めている。
"We recommend marking user-generated content (UGC) links, such as comments and forum posts, with the ugc value."
（訳: コメントやフォーラムの投稿のような、利用者が作った内容（UGC）のリンクには、ugcの値を付けることを勧める。）
3つめは、疑わしい投稿を、人が見てから公開する承認の運用である。
当サイトの無料ツールと、記事
Search Consoleの数字の見方に迷うときは、当サイトの無料ツール🔧 Google Search Console お助け。もうちょっと詳しく知りたいよツールが使える。SNSの投稿を、Search Consoleでどう測れるかは、当サイトの記事「SNS投稿もGoogle検索に測れる日 ── Search Console『Platform Properties』、ドメインなしで検証できる初のプロパティ」で扱った。その続きは、「宣言した宿題の期限が来た日 ── Search Console プラットフォームプロパティに繋いだら、「48時間待て」と言われた」にある。
07 当サイトで確かめたこと
当サイトは、UGCのプラットフォームではない
当サイトの記事は、当サイトの運営側が書いている。そのため、最初の条件（主に利用者の投稿を載せている）で外れる。この判断を、記事の書き方だけで済ませず、外から見える公開のページで確かめた。
公開ページ39枚を、数えた
2026年10月9日に、当サイトのサイトマップの349本の公開アドレスから、9本おきに39本を選び、1本ずつ開いた。39本とも200で返った。見たのは、公開のページだけで、会員のページには入っていない。
各ページのHTMLからコメントの中を除き、構造化データの中だけを数えた。DiscussionForumPostingとSocialMediaPostingの型はどちらも0件、interactionStatisticも0件、CommentとReviewの型も0件だった。数え方が動いているかは、同じ39本で、構造化データの中のBlogPostingが45件、Articleが37件と数えられたことで確かめた。
ここで1つ、数え方によって答えが変わった。構造化データの中ではなく、ページ全体の文字からinteractionStatisticを探すと、38ページで見つかった。中身を開くと、38ページとも、ページに埋め込まれた用語の説明の中の1語だった。構造化データではない。語を探すだけの数え方では、「あり」と読んでしまうところだった。
入力欄と、送信の窓口も見た
入力欄（textarea）は、39ページの全部にあり、案内の文字は、どのページも「メモを残せます」の1つだった。そのうち1ページには、ほかに、ツールの出力を表示する欄（案内の文字は「生成されたコードがここに表示されます。」）が1つあった。どちらも、投稿やコメントを促す文言ではない。フォームは、数えると、送信先が検索のものが39個、ログインのものが1個、別の送信先のものが4個、送信先を指定しないものが22個あった。
この結果から言えることと、言えないこと
言えるのは、外から開いた公開ページ39枚の範囲では、投稿を主とする作りも、投稿の構造化データも見つからなかったことである。言えないのは、サイトマップに載らないページや、会員のページの中身である。当サイトは、条件の1つめで外れるので、残りの5つは当てはめていない。
外から見える範囲を、画面の見た目だけで判断しない考え方は、当サイトの記事「外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけた」で書いた。構造化データの値だけが食い違っていた例は、「出力は在った。だから誰も測らなかった ── datePublished・og:type・用語ハイライト・sitemapで見つけた4つの「値だけ違う」穴」にある。
08 このテーマの、これまで
投稿に関する公式の文書の、最終更新日
投稿に関わる公式の文書を、2026年10月9日に開き、ページの末尾の最終更新日を書き写した。日付は、すべてUTCである。
| 文書 | 最終更新（UTC） | 内容 |
|---|---|---|
| UGC Fresh Data Program | 2026年10月8日 | 専用の流れの条件と、申請の方法 |
| Discussion forum structured data | 2026年9月8日 | DiscussionForumPostingの使い方と必須の項目 |
| Q&A page structured data | 2026年9月8日 | 質問と答えの形のページの構造化データ |
| Profile page structured data | 2026年9月8日 | 書いた人のプロフィールのページの構造化データ |
| Googleウェブ検索のスパムに関する方針（Spam policies） | 2026年8月28日 | 利用者が作ったスパムを含む、スパムの方針 |
| Prevent user-generated spam | 2025年12月10日 | 投稿の荒らしを減らす具体策 |
表の日付を見ると、10月8日に新しく出たのは、専用の流れの説明だけで、構造化データやスパム対策の文書は、それより前から公開されていた。今回の更新が、投稿の構造化データの要件を変えた、という記録は、更新履歴にも、各文書にも、見つけていない。
当サイトの、関連する過去の記事
- 「ディスカッションとフォーラム」枠はRedditが8割 ── Google検索で自社サイトが負けている場面を確認する14項目（2026年8月時点） — 検索結果のディスカッションとフォーラムの枠と、自社の位置の確かめ方。
- schema.orgに語が増えても、Googleが使うとは限らない ── 自社の構造化データを3つの段で確かめる13項目（2026年10月時点） — 構造化データを、書く・読まれる・使われるの3つの段で確かめる記事。
- FAQとHow-toのリッチリザルト廃止は、同じ時期の話ではなかった ── 自分のサイトの構造化データを確認する13項目（2026年9月時点） — 構造化データの確認と、リッチリザルトの廃止の時期の違い。
- FAQPageスキーマが壊れていた — 確認したら気づいた3つのこと、当サイトの修正と展開の全記録（2026年6月） — 構造化データが壊れていたと気づいた、当サイトの修正の記録。
- SNS投稿もGoogle検索に測れる日 ── Search Console『Platform Properties』、ドメインなしで検証できる初のプロパティ — SNSの投稿をSearch Consoleで測る話。
現在の貴方のIPアドレス
このサイトで書いている人
