ファクト チェック

他者の主張を評価するウェブページがある場合は、そのウェブページに ClaimReview 構造化データを追加できます。ClaimReview 構造化データを使用すると、該当する主張の Google 検索結果に自分のページが表示されたときに、Google 検索結果にファクト チェックの概要版を表示できます。

このガイドでは、ClaimReview 構造化データの実装方法について詳しく説明します。手動で構造化データを追加したくない場合は、ファクト チェック マークアップ ツールを使用できます。詳細については、ファクト チェック マークアップ ツールをご覧ください。

構造化データを追加する方法

構造化データは、ページに関する情報を提供し、ページ コンテンツを分類するための標準化されたデータ形式です。構造化データを初めて使用する場合は、構造化データの仕組みについてをご覧ください。

構造化データの作成、テスト、リリースの概要は次のとおりです。ウェブページに構造化データを追加するための手順ガイドについては、構造化データの Codelab をご覧ください。

  1. 必須プロパティを追加します。ページ上の構造化データを配置する場所について詳しくは、JSON-LD 構造化データ: ページでの挿入場所をご覧ください。
  2. ガイドラインを遵守します。
  3. リッチリザルト テストでコードを検証します。
  4. 構造化データが含まれているページを数ページ導入し、URL 検査ツールを使用して、Google でページがどのように表示されるかをテストします。Google がページにアクセスでき、robots.txt ファイル、noindex タグ、またはログイン要件によってページがブロックされていないことを確認します。ページが正常に表示される場合は、Google に URL の再クロールを依頼できます。
  5. 今後の変更について Google への情報提供を続けるには、サイトマップを送信することをおすすめします。これは、Search Console Sitemap API で自動化できます。

「地球は平らである」という主張を評価するページがあるとします。このページに ClaimReview 要素がある場合、「地球は平らである」の検索は Google 検索結果に次のように表示されます(実際の表示デザインは異なる可能性があります)。

ページに関連付けられている 1 つの主張の審査

次は、このファクト チェックをホストするページに設定した構造化データの例です。


<html>
  <head>
    <title>The world is flat</title>
    <script type="application/ld+json">
    {
      "@context": "https://schema.org",
      "@type": "ClaimReview",
      "datePublished": "2016-06-22",
      "url": "http://example.com/news/science/worldisflat.html",
      "claimReviewed": "The world is flat",
      "itemReviewed": {
        "@type": "Claim",
        "author": {
          "@type": "Organization",
          "name": "Square World Society",
          "sameAs": "https://example.flatworlders.com/we-know-that-the-world-is-flat"
        },
        "datePublished": "2016-06-20",
        "appearance": {
          "@type": "OpinionNewsArticle",
          "url": "http://skeptical.example.net/news/a122121",
          "headline": "Square Earth - Flat earthers for the Internet age",
          "datePublished": "2016-06-22",
          "author": {
            "@type": "Person",
            "name": "T. Tellar"
          },
          "image": "https://example.com/photos/1x1/photo.jpg",
          "publisher": {
            "@type": "Organization",
            "name": "Skeptical News",
            "logo": {
              "@type": "ImageObject",
              "url": "https://example.com/logo.jpg"
            }
          }
        }
      },
      "author": {
        "@type": "Organization",
        "name": "Example.com science watch"
      },
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "1",
        "bestRating": "5",
        "worstRating": "1",
        "alternateName": "False"
      }
    }
    </script>
  </head>
  <body>
  </body>
</html>

資格に関するガイドライン

リッチリザルト テストに沿ってページを正しくマークアップしたとしても、ファクト チェックが検索結果に表示される保証はありません。構造化データを使用して、ある機能が表示されるように設定することは可能ですが、必ず表示されるとは限りません。Google のアルゴリズムは、ファクト チェックがリッチリザルトに表示される資格を、さまざまな要因に応じてプログラムで判断します。この要因には下記のガイドラインが含まれます。

ファクト チェックのコンテンツが Google 検索にファクト チェックのリッチリザルトとして表示される資格を得るには、以下のガイドラインに従う必要があります。

  • サイト内に ClaimReview 構造化データでマークされたページが複数あることが必要です。
  • すべての構造化データに関するガイドラインウェブマスター向けガイドラインを遵守する必要があります。
  • 構造化データとページ コンテンツの間に不一致(たとえば、構造化データは主張が正しいと示しているが、ページ上のコンテンツでは主張は誤りであると記述している)があってはなりません。不一致がある場合は、コンテンツと構造化データを一致させる必要があります(たとえば、両方で主張が正しいと示します)。
  • Google ニュースの一般的なガイドラインに規定されている、説明責任、透明性、読みやすさ、サイトの不実表示に関する基準を満たす必要があります。
  • 修正ポリシーか、ユーザーが誤りを報告するための仕組みが必要です。
  • 政治団体のウェブサイト(政治活動、政党、公選された役職者のサイトなど)は、この機能の対象外となります。
  • 読者が記事の本文内で主張と主張の根拠を容易に区別できることが必要です。どのような根拠に基づいてどのような結論に至ったかを読者が理解できなければなりません。
  • 特定の主張を評価する場合は、それがウェブサイト、公開声明、ソーシャルメディア、またはその他の追跡可能な出典元であるかどうかに関わらず、自身のウェブサイト以外の主張者の出典元を明確に示す必要があります。
  • ファクト チェック分析が情報源と方法について追跡可能性と透明性を有し、一次ソースを引用および参照していることが必要です。

技術に関するガイドライン

  • 同じページで、複数の ClaimReview 要素をホストできます(主張ごとに 1 つの要素)。
  • そのページで同じファクトを評価する担当者が複数いる場合は、担当者の解析ごとに別々の ClaimReview 要素を追加できます。詳細については、1 ページで複数のファクト チェックをホストする場合をご覧ください。
  • ClaimReview 要素をホストするページには、少なくともファクト チェックと評価の簡単な要約を含める必要があります(全文を含めない場合)。
  • 特定の ClaimReview を追加できるのは、サイト上の 1 ページのみです。同じファクト チェックを複数のページに繰り返し追加しないでください。ただし、同じページのバリエーションである場合は追加可能です(たとえば、あるページのモバイル版とパソコン版には同じ ClaimReview を追加できます)。
  • ファクトチェック記事を集めたウェブサイトの場合は、すべての記事が上記の基準を満たすこと、ファクトチェックを集めた全ウェブサイトの公開リストを指定することが必要です。

1 ページで複数のファクト チェックをホストする場合

1 つのページで複数の ClaimReview アイテムを指定する場合は、すべてのアイテムがページのメイントピックに関連していることを確認してください。次のいずれかの方法を使用します。

  • 複数のファクト チェックの要約を含む要約ページを作成し、それぞれのファクト チェックに独自の ClaimReview 要素を割り当てます。各ファクト チェックの全文版はそのファクト チェック独自のページに掲載します。要約ページの各 ClaimReview 要素は、要約ページではなく、全文版のページを参照します。
  • または
  • 複数の評価の全文を含む 1 つのページを作成し、それぞれの評価に HTML アンカーを割り当てます。各 ClaimReview 要素はそれぞれの summary_page.html#anchor を指します。

構造化データタイプの定義

ファクト チェックを実装するには、次の構造化データタイプが必要です。

コンテンツがリッチリザルトとして表示されるようにするには、必須プロパティを含める必要があります。また、推奨プロパティを使用することでコンテンツに関する詳細情報を追加でき、ユーザー エクスペリエンスの向上につながります。

ClaimReview に関して実装に関心がある、または問題を抱えている場合は、連絡先情報をお送りください。担当チームからご連絡差し上げます。

ClaimReview

ClaimReview の定義の全文は schema.org/ClaimReview で確認できます。

必須プロパティ
claimReviewed

Text

評価された主張の簡単な要約。モバイル デバイスに表示される際に折り返しを最小限に抑えるため、半角 75 文字(全角 37 文字)未満になるようにしてください。

reviewRating

Rating

主張の評価。このオブジェクトでは数値とテキストの両方の評価がサポートされます。現時点では、検索結果に表示される値はテキスト値のみです。

複数のファクト チェック プロジェクトで評価スキームが異なると、特に中間値に関して若干の違いが生じる場合があります。評価スキームを文書化して、数値評価の意味を明確にすることが重要です。最低でも、数値スコアを扱うすべてのファクト チェックで数値とテキストの評価が一致するシステムを作成するようにしてください。

  • 1 = 「誤り」
  • 2 = 「概ね誤り」
  • 3 = 「半分は真実」
  • 4 = 「概ね真実」
  • 5 = 「真実」

詳細については、Rating をご覧ください。

url

URL

ファクト チェックの記事全文をホストするページへのリンク。そのページに複数の ClaimReview 要素がある場合は、ファクト チェックに HTML アンカーを割り当て、このプロパティがそのアンカーを参照するようにします。例: http://example.com/longreview.html または http://example.com/summarypage.html#fact1

この URL のドメインの値は、この ClaimReview 要素をホストするページと同じドメインであるか、そのサブドメインである必要があります。リダイレクトや短縮 URL(g.co/searchconsole など)は解決されないため、ここでは機能しません。

推奨プロパティ
author

Organization

ファクト チェック記事の公開元(主張の公開元ではありません)。author には組織または担当者を指定する必要があります。author に対して少なくとも次のいずれかのプロパティを指定します。

name Text

ファクト チェックを公開する組織の名前。

url

URL

ファクト チェックの公開元の URL。ホームページ、連絡先ページなど、適切なページを指定できます。

datePublished

DateTime

ファクト チェックが公開された日。

itemReviewed

Claim

行われた主張を表すオブジェクト。詳細については、Claim をご覧ください。

Claim

Claim の定義の全文は schema.org/Claim で確認できます。

推奨プロパティ
appearance

URL または CreativeWork

この主張が表示される CreativeWork へのリンク、またはインラインの説明。

author

Organization または Person

主張者(ファクト チェックの実施者ではありません)。主張者がいない場合は、author プロパティを含めないでください。author を追加する場合は、以下のプロパティを定義してください。

nameText(必須)

主張の公開元。公開元は個人または組織です。

sameAs URL(推奨)

当事者が PersonOrganization かにかかわらず、主張元の当事者を示します。複数の公開元が同じ主張について報告する場合は、appearance プロパティを繰り返し使用することが可能です。複数の当事者が本質的に同じ主張を行っているときは、author プロパティを繰り返し使用することが可能です。

次の URL のいずれかを使用します。

  • 主張を行っている組織のホームページ。
  • 個人または組織の Wikipedia または Wikidata エントリなど、主張を行っている当事者に関する情報を提供する明確な URL。
datePublished

DateTime

主張を行った日付または主張が一般の話題になった日付(たとえば、ソーシャル ネットワークで話題になった日付など)。

firstAppearance

URL または CreativeWork

この主張が最初に行われた CreativeWork へのリンク、またはインラインの説明。

Rating

Rating の定義の全文は schema.org/Rating で確認できます。

必須プロパティ
alternateName

Text

ClaimReview.reviewRating に割り当てる真実度の評価を、短い語句のテキストで読みやすいように示します。この値が検索結果内のファクト チェックに表示されます。例: 「真実」、「概ね真実」。

長文を使用する場合は、文の末尾がディスプレイに合わせて切り捨てられる場合に備え、文の先頭で評価の意味を示すようにします。例: 「細部は概ね真実だが、主張全体では若干誤解を招く」

推奨プロパティ
bestRating

Number

数値による評価で、最低から最高までの範囲で選択可能な最大値。worstRating より大きい値を入力してください。数値として評価できる必要があります。: 4

name

Text

alternateName と同じで、alternateName が指定されていないときに使用されます。ただし、name より alternateName を使用することをおすすめします。

ratingValue

Number

この主張の数値による評価で、worstRatingbestRating の範囲。整数値が推奨されますが、必須ではありません。この数値が bestRating に近いほど真実度が高く、worstRating に近いほど誤りである可能性が高くなります。数値による評価は、数値として評価できる必要があります。: 4

worstRating

Number

数値による評価で、最低から最高までの範囲で選択可能な最小値。bestRating 未満で指定してください。数値として評価できる必要があります。最小値は 1 である必要があります。: 1

Search Console でリッチリザルトを監視する

Search Console は、Google 検索におけるページのパフォーマンスを監視できるツールです。Search Console に登録していなくても Google 検索結果に表示されますが、登録することにより、Google がサイトをどのように認識しているかを把握して改善できるようになります。次の場合は Search Console を確認することをおすすめします。

  1. 構造化データを初めてデプロイした後
  2. 新しいテンプレートをリリースした後やコードを更新した後
  3. トラフィックを定期的に分析する場合

構造化データを初めてデプロイした後

ページがインデックスに登録されたら、関連するリッチリザルトのステータス レポートを使用して、問題がないかどうかを確認します。有効なページが増え、エラーや警告が増えていない状態が理想的です。構造化データに問題が見つかった場合の手順は次のとおりです。

  1. エラーを修正します
  2. 公開 URL の検査を行い、問題が解決したかどうかを確認します。
  3. ステータス レポートを使用して検証をリクエストします。

新しいテンプレートをリリースした後やコードを更新した後

ウェブサイトに大幅な変更を加えた場合は、構造化データのエラーや警告が増加しないかどうか監視します。
  • エラーが増加した場合は、新しく公開したテンプレートが正常に機能していないか、既存のテンプレートの動作に問題が生じていることが原因と考えられます。
  • 有効な項目が減少している(エラーの増加と一致しない)場合は、ページに構造化データが埋め込まれていない可能性があります。URL 検査ツールを使用して問題の原因を特定します。

トラフィックを定期的に分析する場合

パフォーマンス レポートを使用して Google 検索のトラフィックを分析します。このデータから、検索でページがリッチリザルトとして表示される頻度、ユーザーがページをクリックする頻度、検索結果におけるページの平均掲載順位がわかります。Search Console API を使用して、このデータを自動的に取得することもできます。

トラブルシューティング

構造化データを実装する際に問題が発生した場合は、以下のリソースを確認してください。