Google UGC Fresh Data Programの対象条件と申請方法

重要なポイント

Google の UGC Fresh Data Program は、承認されたプラットフォームが新しいユーザー投稿とインタラクション信号を専用経路で送る仕組みです。この記事では、対象条件、申請前の準備、通常クロールとの違いを確認します。

Google の UGC Fresh Data Program は、公開され、投稿者を特定できるユーザー生成コンテンツを大量に扱う承認済みプラットフォーム向けの専用データ送信経路です。新鮮で話題性のあるソーシャル投稿やフォーラムの議論が対象で、一般的なウェブページを送信する仕組みではありません。Google の説明では、通常の自然検索クロールや Indexing API とは独立しており、参加してもページが検索結果に表示される保証はありません。

フォーラム、コミュニティ、ソーシャルプラットフォームを運営しているなら、以下の条件で申請を検討できるか確認しましょう。一般的な企業ブログや会社案内サイトであれば、クロール可能性、内部リンク、サイトマップの整備を優先してください。

まず、適切な Google の仕組みを選ぶ

次の3つは、それぞれ目的が異なります。対象条件を満たすプラットフォーム向けに専用パイプラインを提供するのが UGC プログラムです。それ以外の一般的なウェブページや、限られた種類の速報性が必要なページには、通常の方法を使います。

方法

対象

チームで行うこと

自然検索クロール

ウェブ上で Google が発見し、クロールできるページ

ページへのアクセスとインデックス登録を妨げず、わかりやすいリンクとサイトマップを用意します。発見や登録は保証されません。

Indexing API

VideoObject 内に JobPosting またはライブ配信の BroadcastEvent を含むページ

対応するページ種別だけに使います。通知を受けた Google がクロールをスケジュールする仕組みで、あらゆるページを早くインデックスさせる API ではありません。

UGC Fresh Data Program

話題性のあるユーザー投稿やインタラクション信号を扱う承認済みプラットフォーム

専用の取り込みパイプラインへのアクセスを申請します。選定後に Google から技術仕様とオンボーディングが提供されます。

Google は 2026年10月8日にこのプログラムの説明を公開しました。通常の自然検索クロールや Indexing API とは別の仕組みです。構造化データを追加したり Indexing API を呼び出したりしても、UGC プログラムへの参加にはなりません。

申請準備の前に対象条件を確認する

これは点数をつける表ではなく、申請に進めるかどうかの確認ゲートです。Google は条件を示していますが、トラフィック、投稿数、アクティブユーザー数の数値基準は公表していません。独自の基準を作ったり、利用者が多いだけで対象になると判断したりしないでください。

1. サービスの中心がユーザー投稿か確認する

プラットフォームは、ソーシャル投稿やフォーラムの議論のように、ユーザーが独自に作成したコンテンツを主に扱う必要があります。コメント欄付きの企業ブログ、編集記事を中心とする出版社のサイト、他所のコンテンツを主に転載するページは適合しにくいでしょう。

主なコンテンツ形式と、それぞれの作成者を整理してください。代表的な URL もいくつか添えます。示したいのは、UGC が付随機能ではなく、サービスの中核だということです。

2. ページ単位の URL と公開アクセスを確認する

投稿や議論ごとに、安定して使える個別 URL が必要です。プロフィールページやスクロール式フィードでは、投稿ごとの専用ページの代わりになりません。ページはユーザーと Googlebot の両方から公開アクセスできる必要があります。ログイン、ペイウォールなどで保護されたコンテンツは、公表されている条件では対象外です。

ログアウト状態のブラウザーでサンプル URL を開き、robots ルールやページ単位の指示で Googlebot をブロックしていないか確認します。URL が正常なページを返し、投稿本文をアカウントなしで読めるかも確認してください。アプリ内や会員セッションでしか読めない投稿があれば、申請前に解消しましょう。

3. 投稿者の表示、モデレーション、通報手段を確認する

各 UGC は作成者と結び付けられ、作成者のプロフィールを公開できる必要があります。また、プラットフォームには継続的なモデレーションと、ユーザーがコンテンツを通報する方法が必要です。Google は違法コンテンツを除外しています。

通報を担当する人、ユーザーが通報する方法、通報後の対応を記録してください。サポート窓口に非公式に連絡してもらうだけなら、申請前に通報手段を明確で使いやすい形に整えましょう。

4. 構造化データと認証を点検する

Google は対象 URL に有効な Schema.org マークアップを求めています。例として SocialMediaPosting や DiscussionForumPosting が挙げられ、エンゲージメント情報には interactionStatistic を使います。テンプレートだけでなく、実際の投稿ページで検証し、マークアップがページ上でユーザーに見える内容と一致することを確かめてください。

連携には安全な OAuth 2.0 API 認証も必要です。申請前に、認可、データ送信、アクセス管理を担当するチームを決めておきます。Google が詳細な開発者向けドキュメントを提供するのは選定後です。公開されていないエンドポイントを前提に実装を計画したり、送信形式を推測したりしないでください。

5. 新鮮なデータを送れる運用か確認する

Google は、新しいコンテンツは作成から数分以内に送ることが望ましいと説明しています。エンゲージメント数の更新は定期的に行い、投稿作成から72時間以内に送信する必要があります。これは運用上の期待値なので、現在の公開・イベント処理と比べてください。

投稿の作成からイベントを安定して送れるまでの時間を測ります。いいね、返信などのインタラクション数がどの頻度で更新されるかも確認してください。データが日次エクスポート経由だったり、カウンターの更新が数日遅れたりする場合は、その差と解消に必要な作業を申請前に明らかにしましょう。

Google UGC Fresh Data Program の適合性を確認する判断フロー。

4つのゲートを確認し、申請準備に進むか、課題を直すか、通常のクロールを使うか判断します。

申請準備のための資料をまとめる

簡潔な根拠資料があれば、申請の回答をまとめやすくなり、未解決の問題も見つけやすくなります。事実に沿って書き、公開されているサンプル URL を使ってください。

  • プラットフォームの概要: ユーザーが何を投稿するか、なぜ UGC といえるか、投稿量や利用者規模の概算。社内推計にはその旨を添えます。Google は最低基準を公表していません。
  • サンプルページ: 主な UGC 形式ごとの安定した URL を複数用意し、ログアウト状態で確認します。
  • アクセスと投稿者の表示: Googlebot のアクセス、公開プロフィール、投稿と作成者の結び付きについて記録します。
  • 安全運用: モデレーションの担当、通報手段、通報後の対応を簡潔にまとめます。
  • 技術面の根拠: 実際に表示される JSON-LD、検証結果、OAuth 2.0 と連携セキュリティの担当チーム。
  • 鮮度に関する根拠: 投稿から送信までの実測時間と、エンゲージメント数の更新頻度。

この概要の代わりに、ユーザー個人を特定できる情報を送らないでください。公開されている適格性ページには要件が記載されていますが、詳細な取り込み仕様は選定後に提供されます。

Google の公式プログラムページから申請する

主要な条件を満たしていることを確認したら、Google のUGC Fresh Data Program ドキュメントにある関心表明フォームを使います。プラットフォームを簡潔に説明し、各適格性条件に対応する根拠を示してください。「すべてのコンテンツがインデックス可能」「即時掲載」などの表現は避けましょう。このプログラムは検索結果への表示を約束していません。

Google によると、申請への返答には6〜8週間かかる見込みです。選定されたプラットフォームには、技術連携のドキュメントとオンボーディングが提供されます。その間も、一般的なコンテンツ発見とクロールを支える仕組みを維持してください。申請はサイトマップや基本的なテクニカル SEO の代わりにはなりません。

審査前に条件を再確認し、通常の方法も整える

送信前に別の担当者が資料を確認し、公表されている条件すべてに「はい」と答えられる状態にします。UGC がプラットフォームの中心であること、投稿ごとに公開の安定 URL があること、作成者を特定できること、モデレーションと通報手段があること、構造化データが有効であること、OAuth 2.0 の担当が決まっていること、鮮度の期待値を満たせることを確認してください。

条件に不足があれば、担当者を決めて解消してから申請を再検討します。対象に合わないサービスでは、Google の技術要件に沿って対応してください。Googlebot がアクセスできる状態にし、正常な HTTP ステータスを返し、コンテンツをインデックス可能にします。ページを見つけやすいリンクとサイトマップも用意し、個別 URL や全体の状況は Search Console の URL 検査とインデックス登録レポートで調べます。これらは適格性の確認に役立ちますが、インデックス登録を保証するものではありません。

プラットフォーム担当者からよくある質問

`DiscussionForumPosting` の構造化データを追加すれば対象になりますか?いいえ。有効な構造化データは複数条件のうちの1つです。それだけで専用パイプラインへのアクセスが認められるわけではありません。

どのウェブサイトでも申請できますか?公表されている条件は、独自の UGC を主に扱い、個別の公開ページと必要な安全・技術運用を備えたプラットフォームを対象としています。Google は一律の数値基準を公表していません。

選定されればインデックス登録や順位が保証されますか?いいえ。Google は、参加してもコンテンツが検索結果に表示される保証はないと明記しています。

一般的なブログは代わりに Indexing API を使うべきですか?ページが JobPosting またはライブ配信の BroadcastEvent という対応用途に当てはまる場合に限ります。それ以外のページでは、通常のクロールアクセスとサイトマップを整えてください。

Martin Hayes は、SEO とグロースチーム向けに手順型の実践ガイドと運用チェックリストを作成しています。

このトピックを読む

同じテーマの記事を続けて読む