最終更新日: 2026/06/13

Knowledge GraphとsameAsで自分のサイトをGoogleに正しく認識させる方法

Knowledge GraphとsameAsで自分のサイトを

「Knowledge Graph対策って何をすればいいの?」「sameAsプロパティって聞いたことあるけど、どう書くの?」そんなモヤモヤを感じている方に向けて、エンティティ認識の基本からsameAsプロパティの具体的な実装手順まで、初心者でも迷わないよう順を追って解説します。難しそうに見える内容も、一つひとつ丁寧に説明しますので安心して読み進めてみてください。

Knowledge Graph対策とは?sameAsプロパティで自分のサイトをGoogleに正しく認識させる方法

Knowledge Graph対策とは?sameAsプロパテ

Knowledge Graph対策とは、GoogleがあなたのサイトやブランドをWeb上の「実在する存在(エンティティ)」として正確に把握できるよう、情報を整える取り組みのことです。その中心的な手段のひとつが、sameAsプロパティを使った構造化データの実装です。

Knowledge Graph(ナレッジグラフ)とは何か

Knowledge Graphは、Googleが世界中の「モノ・人・場所・概念」に関する情報を関連付けて管理している巨大なデータベースです。たとえば「東京タワー」と検索すると、右側に高さ・所在地・建設年などがまとめて表示されることがありますよね。あのデータの裏にあるのがKnowledge Graphです。

Googleはキーワードの一致だけでなく、「この言葉が何を指しているのか」を理解して検索結果を返しています。Knowledge Graphはその理解を支える土台として機能しており、Webマーケティングにおいてもますます重要な存在になっています。

エンティティとは何か・なぜSEOで重要なのか

エンティティとは、一言でいえば「はっきりと識別できる存在」のことです。人・企業・場所・作品・概念など、Googleが「これはAとは違う、独立した存在だ」と認識できるものすべてがエンティティに当たります。

SEOにおいてエンティティが重要な理由は、Googleがページの内容を「キーワードの羅列」ではなく「意味のある情報の集まり」として評価するようになっているからです。あなたのサイトがエンティティとして認識されると、関連する検索クエリに対して信頼性の高いソースとして扱われやすくなります。エンティティSEOはこれからの検索最適化において欠かせない考え方です。

sameAsプロパティとは何か・何のために使うのか

sameAsは、schema.orgで定義された構造化データのプロパティのひとつです。「このサイト(またはこの情報)は、Webの別の場所にある◯◯と同じ存在ですよ」とGoogleに教えるために使います。

たとえば、あなたの会社のサイトとWikipediaのページ、TwitterアカウントのURLをsameAsでひもづけると、Googleは「これらはすべて同じ組織についての情報だ」と判断できます。これにより、分散していたエンティティ情報が統合され、Knowledge Graphへの収録や検索での正確な認識につながります。

この3つを対策するとサイトにどんな変化が起きるか

Knowledge Graph・エンティティ認識・sameAsプロパティの3つをきちんと整えると、Googleがあなたのサイトを「信頼できる実体」として扱いやすくなります。具体的には、ブランド名で検索したときにKnowledge Panel(右側の情報ボックス)が表示される可能性が出てきたり、関連する検索クエリで上位表示されやすくなったりします。

即効性のある施策ではありませんが、積み重ねることでGoogleとの「信頼関係」が築かれていくイメージです。SEOの土台を強化する長期的な取り組みとして、ぜひ前向きに捉えてみてください。

なぜGoogleはKnowledge Graphを使って検索結果を表示するのか

なぜGoogleはKnowledge Graphを使って検索

Googleが単純なキーワードマッチングを超えて、Knowledge Graphを活用するようになった背景には、検索の「意味理解」に向けた大きなシフトがあります。各セクションでその仕組みを順番に見ていきましょう。

キーワードではなくエンティティで検索を理解する時代になった背景

Googleは2012年にKnowledge Graphを導入した際、「things, not strings(文字列ではなく、モノを理解する)」という方針を打ち出しました。それまでの検索は「入力された文字に一致するページを返す」という仕組みでしたが、同じ言葉でも文脈によって意味が異なることへの限界を感じていたからです。

たとえば「Apple」という単語は、果物のリンゴなのか、IT企業のAppleなのかで意味がまったく違います。エンティティベースの理解により、Googleはこうした文脈の違いを判別して、より適切な検索結果を返せるようになりました。

GoogleがKnowledge Graphのデータをどこから集めているか

Knowledge Graphのデータソースは、大きく分けると次のようなものです。

  • Wikipedia・Wikidata(信頼性の高い百科事典的情報)
  • CIA World Factbook(地理・国家情報)
  • Freebase(Google自身が構築していたデータベース、現在はWikidataに統合)
  • 公式サイトや構造化データ(schema.orgマークアップ)
  • Google独自のクロールで収集したWeb上の情報

Googleはこれらの情報を組み合わせ、エンティティ同士の関係性を整理しています。自分のサイトから構造化データを発信することで、この仕組みに「自分から情報を提供する」形になります。

構造化データ(schema.org)がKnowledge Graphに取り込まれる仕組み

schema.orgは、GoogleやBing・Yahoo!などの主要な検索エンジンが共同で作成した、Webページの情報を構造化して伝えるための共通語彙です。HTMLページにJSON-LD形式でschema.orgの記述を埋め込むと、Googleのクローラーがその情報を読み取り、Knowledge Graphの構築に利用します。

構造化データは「このページは会社(Organization)のトップページで、名前は○○、住所は○○、公式SNSは○○です」といった情報をGoogleに直接伝えられる手段です。自然言語の文章よりも誤解なく伝わるため、エンティティ認識の精度向上に直結します。

Webサイトから自動で情報が抽出される仕組みとは

構造化データを書かなくても、Googleはページのテキストや画像から情報を自動で抽出しています。これを「非構造化データの解析」といい、自然言語処理(NLP)や機械学習の技術が使われています。

ただし、自動抽出はあくまで推測であり、間違いも起こります。会社名・人名・所在地などが正確に認識されるとは限りません。構造化データを使って「正解」を明示的に教えることで、自動抽出のエラーを補いながらGoogleのエンティティ認識精度を高められます。自分から情報を発信する能動的なアプローチが重要です。

Knowledge PanelはKnowledge Graphのどの部分が表示されるのか

Knowledge Panelとは、Googleの検索結果ページの右側(PCの場合)に表示される情報ボックスのことです。企業・著名人・場所などを検索したときに現れ、名称・説明・画像・SNSリンクなどが一覧表示されます。

このパネルは、Knowledge Graphの中にある特定のエンティティに関するデータが表示されたものです。つまり、Knowledge Panelが表示されるということは「GoogleがあなたのブランドをKnowledge Graphに収録した」証拠といえます。sameAsプロパティや構造化データを整えることで、このパネル表示の可能性を高めることができます。

Googleが自分のサイト・ブランドをエンティティとして認識するとはどういうことか

Googleが自分のサイト・ブランドをエンティティとして認識

「エンティティとして認識される」とはどんな状態なのか、少し具体的なイメージを持てると実装のモチベーションも変わってきます。ここではエンティティ認識の考え方を掘り下げていきます。

エンティティ認識とは何か・具体的なイメージ

エンティティ認識(エンティティ・レコグニション/NER)とは、文章の中から人名・組織名・地名・日付・金額などのはっきりした意味を持つ要素(エンティティ)を自動的に見つけ出し、その種類ごとに分類する自然言語処理技術のことです。Google検索やSEOの文脈では、人物・組織・場所・概念などの「エンティティ」を検索エンジンが実体として理解し、WebサイトやコンテンツとKnowledge Graphを通じて結び付けていく仕組みとして活用されています。

わかりやすく例えると、あなたが転職して新しい会社に入ったとき、同僚たちはあなたの名前・顔・仕事の役割を覚えていきますよね。Googleがエンティティを理解するプロセスも似ていて、「この企業(組織)は何という名前で、どこにあり、どのような事業を行っているか」といった情報をナレッジグラフなどで整理・学習していきます。

そのため、企業や店舗などのエンティティについては、名称・所在地・業種・電話番号などの基本情報を、Googleビジネスプロフィールや公式サイト、業界の有力サイトや大手ニュースサイト、Wikipediaなど複数の信頼性の高い情報源で一貫して提示することで、Googleによるエンティティの認識と理解が深まりやすくなります。SNSや代表者情報なども補足的な要素として有効ですが、まずは信頼性の高い情報源での一貫した情報発信を意識してみてください。

同じ名前・似た情報をGoogleが一つにまとめる「同一性解決」の考え方

Web上には、同じ企業について書かれた情報がサイト・SNS・ニュース記事など多くの場所に分散しています。Googleはそれらを「同じエンティティに関する情報だ」と判断して統合する作業を行っており、これを「同一性解決(Entity Resolution)」と呼びます。

sameAsプロパティはまさにこの同一性解決を助けるためのものです。「このサイトのOrganizationと、Wikipediaのこのページと、Twitterのこのアカウントは同一の存在です」と明示することで、Googleが正確に情報を統合しやすくなります。分散した情報を一本に束ねるイメージです。

Googleが情報の信頼度をどうやって判断しているか

Googleはエンティティに関する情報の信頼度を、「どれだけ多くの独立した信頼できるソースが同じことを言っているか」で判断しています。これはE-E-A-T(経験・専門性・権威性・信頼性)の考え方とも深く関わっています。

たとえば、自社サイトだけが「私たちは業界トップの会社です」と主張しても、Googleはすぐには信じません。しかし、Wikipediaや業界メディア・Googleビジネスプロフィールなど、複数の独立したソースが同じ情報を裏付けていると、信頼度が積み上がっていきます。sameAsで外部ソースとひもづけることも、この信頼のシグナルを強める一手です。

自分のサイトがエンティティとして認識されているか確認する方法

もっとも手軽な確認方法は、Googleで自分のブランド名・会社名を検索することです。検索結果の右側にKnowledge Panelが表示されていれば、エンティティとして認識されている可能性が高いです。

また、Google Search Consoleの「検索パフォーマンス」レポートで、ブランド名クエリへの表示回数・クリック数を確認するのも参考になります。さらに、schema.orgのバリデーターやGoogleのリッチリザルトテストを使うと、構造化データが正しく認識されているかも確認できます。

sameAsプロパティの役割と書き方を初心者向けに解説

sameAsプロパティの役割と書き方を初心者向けに解説

sameAsプロパティはどう書けばいいのか、どのURLを指定すべきなのか、初めて触れる方が疑問に思うポイントを丁寧に説明します。コード例も交えながら確認していきましょう。

sameAsプロパティが必要な理由・使わないとどうなるか

sameAsを使わない場合、Googleはあなたのサイトと外部の情報ソースが同一の存在を指しているかどうかを自力で推測するしかありません。推測が外れると、Knowledge Graphへの収録が遅くなったり、誤った情報でエンティティが認識されたりするリスクがあります。

特に「よくある会社名」や「一般的な言葉と同じ名前のブランド」を持つ場合は、同一性の混乱が起きやすいです。sameAsで「このサイトはあのWikipediaページと同じ存在です」と明示することで、Googleの認識ミスを未然に防げます。

sameAsに指定できるURLの種類と選び方

sameAsに指定できるURLは、そのエンティティと「同一である」と証明できる外部リソースのURLです。主なものを整理すると次のとおりです。

URLの種類

Wikipedia

https://ja.wikipedia.org/wiki/〇〇

Wikidata

https://www.wikidata.org/wiki/Q〇〇〇

X(旧Twitter)

https://x.com/〇〇

Facebook

https://www.facebook.com/〇〇

LinkedIn

https://www.linkedin.com/company/〇〇

Instagram

https://www.instagram.com/〇〇

Googleビジネスプロフィール

maps.google.comのURL

選び方のポイントは「実際に存在するURL」「そのエンティティを正しく指しているURL」の2点に絞ることです。無関係なURLや404になるURLは入れないようにしましょう。

WikipediaやWikidataのURLを使うべき理由

WikipediaとWikidataは、Googleが最も信頼するデータソースのひとつです。WikipediaはGoogleのKnowledge Graphのデータ収集先でもあり、ここへのひもづけはエンティティの信頼度を大きく高める効果があります。

WikidataはWikipediaの構造化版データベースで、エンティティに対してユニークなID(例:Q937=アルベルト・アインシュタイン)が割り当てられています。WikidataのURLをsameAsに含めることで、Googleのナレッジグラフとの親和性がさらに高まります。自社・自分のエンティティがWikipediaやWikidataに掲載されている場合は、必ず含めておきましょう。

SNSアカウントや公式ページをsameAsに含める方法

SNSアカウントも立派なsameAsの対象です。公式のX(旧Twitter)・Facebook・Instagram・LinkedInのURLを含めることで、Googleはそれらが同一ブランドのアカウントであると判断します。

ただし、個人アカウントや非公式アカウントのURLを誤って指定しないよう注意してください。あくまで「そのエンティティ(会社・人物)の公式アカウント」のURLを使いましょう。URLはhttps://から始まる完全な形式で記述するのが基本です。

JSON-LD形式でsameAsを書く基本の構文

sameAsはJSON-LD形式で記述します。JSON-LDはHTMLの<head>タグ内に<script type="application/ld+json">タグで埋め込む形式で、ページのデザインに影響しないため扱いやすい方法です。

基本の構文はこのようになります。

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "株式会社〇〇",
  "url": "https://example.com",
  "sameAs": [
    "https://x.com/example",
    "https://www.facebook.com/example",
    "https://ja.wikipedia.org/wiki/〇〇"
  ]
}

sameAsは配列([])で複数のURLを並べて指定できます。必ず実在するURLを使うようにしてください。

OrganizationスキーマにsameAsを組み合わせた実例コード

企業・ブランドのサイトで使う場合、OrganizationタイプとsameAsを組み合わせます。以下は実際に使える形式の例です。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "ここに会社名",
  "url": "https://your-domain.com",
  "logo": "https://your-domain.com/logo.png",
  "foundingDate": "2020",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "東京都",
    "addressCountry": "JP"
  },
  "sameAs": [
    "https://x.com/your_account",
    "https://www.facebook.com/your_page",
    "https://www.linkedin.com/company/your_company",
    "https://ja.wikipedia.org/wiki/あなたの会社名"
  ]
}
</script>

トップページの<head>内に設置するのが一般的です。名前・URL・sameAsの3点は最低限入れておきましょう。

PersonスキーマにsameAsを組み合わせた実例コード

個人ブログや著者ページなど、人物のエンティティを示したい場合はPersonタイプを使います。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "山田 太郎",
  "url": "https://your-blog.com",
  "jobTitle": "Webライター",
  "sameAs": [
    "https://x.com/your_twitter",
    "https://www.linkedin.com/in/your_profile",
    "https://note.com/your_note"
  ]
}
</script>

Personスキーマは著者ページや「このブログについて」ページに設置するのが自然です。著者情報をGoogleに正確に伝えることで、E-E-A-Tの「経験・専門性」シグナルの強化にもつながります。

sameAsプロパティを自分のサイトに実装する手順

sameAsプロパティを自分のサイトに実装する手順

概念が理解できたら、実際に自分のサイトへ実装してみましょう。7つのステップに分けて、迷わず進められるよう整理しました。

ステップ1:自社・自分のエンティティ情報を整理する

まず、自分(または自社)のエンティティとして伝えたい情報を書き出してみましょう。以下の項目を一覧にしておくと、後のステップがスムーズです。

  • 正式名称(会社名・氏名)
  • Webサイトのトップページ URL
  • ロゴ画像のURL
  • 所在地(市区町村レベルで可)
  • 業種・活動内容
  • 代表者名(法人の場合)
  • 公式SNSアカウントのURL
  • Wikipedia・WikidataのURLがあれば追記

この段階でしっかり情報を整理しておくと、コード作成時に迷いがなくなります。

ステップ2:sameAsに使うURLを収集・確認する

ステップ1で洗い出したSNSや外部サイトのURLを実際にブラウザで開き、正しくアクセスできるか確認しましょう。404エラーが出るURLや、そのエンティティと関係のないページのURLは使用禁止です。

確認のポイントは3つです。

  1. URLがhttpsで始まっているか
  2. そのページが実際に自分(または自社)を指しているか
  3. アカウントが鍵付きや非公開になっていないか

URLをメモ帳などにまとめてから次のステップへ進むと、コード作成がスムーズです。

ステップ3:JSON-LDコードを作成する

前のセクションで紹介したOrganizationまたはPersonスキーマのテンプレートを使って、自分の情報を当てはめたJSON-LDコードを作成します。

手書きが不安な方は、Schema Markup Generator(Merkle製)などの無料ツールを使うと便利です。必要な項目を入力するだけでJSON-LDが自動生成されます。作成したコードは次のステップで貼り付ける前に、必ずバリデーションチェックをしてください(ステップ6で詳しく説明します)。

ステップ4:コードをサイトのheadタグに埋め込む

作成したJSON-LDコードを、HTMLの<head></head>の間に貼り付けます。場所はどこでも構いませんが、わかりやすいように</head>の直前にまとめて置くのがよく使われる方法です。なお、Googleの仕様では<head>内だけでなく<body>内に記述しても認識されます。

<head>
  <!-- 既存のmetaタグなど -->
  <script type="application/ld+json">
  {
    // ここにJSON-LDコードを貼る
  }
  </script>
</head>

Organizationスキーマは、サイト全体で共通の組織情報として扱う場合、header.phpなどを使って全ページの<head>内に出力しても問題ありません。WordPressではこの方法がよく使われています。もちろん、サイトの構成や運用方針によってトップページのみに設置する運用も可能です。同一の情報を複数ページに記述すること自体は仕様上の禁止事項ではないので、サイト設計に合わせて設置場所を決めてみてください。

ステップ5:WordPressプラグインで実装する方法

HTMLを直接編集するのが難しい場合、WordPressサイトであればプラグインを使う方法が手軽です。代表的なプラグインは以下のとおりです。

  • Yoast SEO:「ソーシャル」タブから組織・人物情報を入力でき、自動でschema.orgを出力します
  • Rank Math SEO:スキーマ設定が視覚的に行えて、sameAsの追加もしやすい設計です
  • All In One SEO:OrganizationやPersonのスキーマを設定画面から入力できます

プラグインによっては入力フォームにsameAsの欄が用意されているため、URLをコピペするだけで設定できます。

ステップ6:Googleのリッチリザルトテストで動作確認する

コードを設置したら、Googleのリッチリザルトテストでエラーがないか確認しましょう。URLを入力してテストするだけで、構造化データが正しく読み取れているか即座にわかります。

「検出された項目」にOrganizationまたはPersonが表示され、エラーが0件であれば問題なしです。警告が出ている場合は内容を読んで修正してみてください。バリデーションを通過してから公開するのを習慣にすると、後からトラブルになりにくいです。

ステップ7:Google Search Consoleで反映状況を確認する

公開後は、Google Search Consoleの「拡張機能」メニューを確認しましょう。構造化データのエラーや警告があれば、ここに通知が届きます。

Knowledge Panelの表示やエンティティ認識の強化はすぐには反映されませんが、数週間〜数ヶ月で変化が現れることがあります。ブランド名で定期的に検索して、Knowledge Panelが出始めているか観察してみてください。焦らず、じっくり育てていくイメージで取り組むのがおすすめです。

Knowledge Graph対策としてsameAs以外にやっておきたいこと

Knowledge Graph対策としてsameAs以外にや

sameAsプロパティの実装はKnowledge Graph対策の一部にすぎません。エンティティの信頼度をGoogleに認めてもらうために、合わせて取り組むと効果的なことをまとめました。

Organizationスキーマで会社・ブランド情報を構造化する

sameAsを設定するOrganizationスキーマ自体も、できるだけ情報を充実させておくことが大切です。名前・URL・ロゴ・住所・電話番号・設立年・業種(legalNamefoundingDateなど)を丁寧に埋めることで、Googleに渡せる情報が増えます。

会社概要ページの内容とOrganizationスキーマの内容が一致しているかも合わせて確認しましょう。ページのテキストとスキーマが矛盾していると、Googleに「信頼できない情報」と判断される可能性があります。

Personスキーマで著者情報をGoogleに伝える

ブログ記事を書いている場合、各記事にPersonスキーマを使った著者情報を追加するのも有効です。Googleは誰がその記事を書いたのかを理解しようとしており、著者のエンティティが明確であるほどE-E-A-Tの評価に好影響を与えます。

Articleスキーマと組み合わせてauthorプロパティにPersonを指定する方法が標準的です。著者ページ(プロフィールページ)のURLもあわせて設定しておくと、Googleが著者情報を正確に理解しやすくなります。

サイト全体でNAP情報(名前・住所・電話番号)を統一する

NAP(Name・Address・Phone)情報の一貫性は、ローカルSEOやエンティティ認識の両面で重要です。自社サイト・Google ビジネスプロフィール・各種ビジネスディレクトリサイトで、名前・住所・電話番号が微妙に違っていると、Googleが「同じ組織の情報なのか」判断しにくくなります。

「株式会社」と「(株)」の表記ゆれ、ハイフンありなしの電話番号表記など、細かい点まで揃えるのがポイントです。一度サイト内を棚卸しして、表記を統一しておきましょう。

Googleビジネスプロフィールと連携させる

Googleビジネスプロフィール(旧Googleマイビジネス)は、Knowledge Graphとの相性が非常によいツールです。プロフィールを整備することでGoogleがエンティティ情報を取得しやすくなり、ローカルパックへの表示やKnowledge Panelの充実にもつながります。

ウェブサイトのURL・業種・説明文・写真・営業時間などを正確に入力して、自社サイトのOrganizationスキーマと情報が一致するようにしておきましょう。sameAsにGoogleビジネスプロフィールのURLを含めることも可能です。

WikipediaやWikidataへの掲載を目指す

WikipediaとWikidataへの掲載は、Googleにとって最も信頼性の高いエンティティシグナルのひとつです。ただし、Wikipediaは独自の掲載基準(特筆性)があり、誰でもすぐに掲載できるわけではありません。

まずはWikidataへの登録から始めるのが現実的です。Wikidataは独自の特筆性基準が比較的緩やかで、企業・個人・概念など幅広いエンティティを登録できます。登録後にWikidataのURLをsameAsに追加することで、Knowledge Graphとの接続がより確かなものになります。

被リンク・被引用を増やしてエンティティの信頼度を高める

エンティティとしての信頼度は、他のWebサイトからどれだけ言及・引用されているかにも左右されます。信頼性の高いメディアや業界サイトから自社名・個人名が引用されるほど、Googleは「このエンティティは実在する、評価されている存在だ」と判断しやすくなります。

プレスリリースの配信・業界ブログへの寄稿・メディア取材対応など、オフページSEOの取り組みがそのままエンティティ強化にもつながります。リンクがなくても「ブランドの言及(NAP引用)」だけでも効果があるとされています。

内部リンクを整理してエンティティの関連性を強化する

サイト内の内部リンク構造も、エンティティ認識に影響します。関連するページ同士を適切にリンクでつなぐことで、Googleはそのサイトがどのトピック・エンティティに関連しているかを把握しやすくなります。

たとえば、会社概要ページ・サービスページ・ブログ記事が相互にリンクされていると、「このサイトは○○というエンティティについて一貫した情報を提供している」とGoogleに伝えやすくなります。ページ数が多いサイトほど、内部リンクの整理は効果が出やすい施策です。

実装するときに初心者がやりがちなミスと注意点

実装するときに初心者がやりがちなミスと注意点

Knowledge Graph対策やsameAsの実装は難しくありませんが、初めてのうちは少し注意が必要なポイントがあります。よくあるミスを先に知っておくと、トラブルを未然に防げます。

存在しないURLをsameAsに書いてしまう

sameAsに指定したURLがリンク切れ(404エラー)や非公開ページだった場合、Googleはそのプロパティを無視するか、信頼性のない情報として扱う可能性があります。

SNSアカウントを削除・変更した場合や、会社名・ドメインが変わった場合は、sameAsのURLも必ず更新してください。定期的にURLが有効かどうかをチェックする習慣をつけておくと安心です。

記載内容とページ上の情報が一致していない

構造化データに書いた社名・住所・電話番号が、ページ上のテキストと異なっている場合、Googleはスキーマの内容を「正確ではない」と判断することがあります。これはGoogleのガイドラインでも注意点として挙げられているポイントです。

JSON-LDに書く内容は、ページ上に表示されている情報と一致させることが基本です。まずページのテキストを正確に整えてから、それに合わせて構造化データを作成するという順番が正解です。

サイト全体に同じコードを貼り付けてしまう

OrganizationスキーマはトップページだけでOKです。すべてのページに同じOrganizationスキーマを貼り付けると、重複マークアップとしてGoogleに認識される場合があり、かえってノイズになることがあります。

各ページのスキーマはそのページの内容に合わせて設定するのが原則です。トップページにはOrganization、記事ページにはArticle、著者ページにはPerson、というように役割を分けて設置しましょう。

検証ツールで確認せずに公開してしまう

JSON-LDは構文エラーが1文字あるだけでまるごと無効になります。コンマの位置・括弧の対応・引用符の使い方など、細かい箇所でミスが起きやすいです。

必ずGoogleのリッチリザルトテストSchema.org Validatorでエラーゼロを確認してから公開してください。「動いているはずだけど効果が出ない」という状況の多くは、構文エラーで構造化データが無効になっているケースです。

Googleのガイドラインに違反するマークアップをしてしまう

Googleの構造化データガイドラインでは、「ページに表示されていない情報をマークアップしない」「誤解を招く情報をマークアップしない」などが明記されています。違反が確認されると、リッチリザルトが非表示になるペナルティを受けることがあります。

Googleの構造化データに関する一般的なガイドラインは一度目を通しておくのをおすすめします。難しい英語のドキュメントですが、日本語翻訳版も用意されています。基本ルールを押さえておくだけで、大半のリスクは避けられます。

まとめ

まとめ

Knowledge Graph対策とsameAsプロパティの実装は、Googleに「あなたのサイトが何者なのか」を正確に伝えるための取り組みです。エンティティとして認識されることで、検索での信頼性が高まり、Knowledge Panelの表示やブランドクエリへの強さにつながっていきます。

最初のステップとして取り組みやすいのは、OrganizationまたはPersonスキーマを作成してsameAsを追加することです。SNSアカウントのURLやWikidataへのリンクを含めるだけでも、Googleへの情報発信として十分な第一歩になります。

完璧を目指すよりも、まず一つ実装して検証ツールで確認することを繰り返してみてください。エンティティSEOの成果は時間がかかりますが、確実にサイトの土台を強くしてくれます。

Knowledge Graph対策|エンティティ認識とsameAsプロパティ実装についてよくある質問

Knowledge Graph対策|エンティティ認識とsam
  • sameAsプロパティを設定するとすぐに効果が出ますか?
    • すぐに効果が出ることはほとんどありません。GoogleがsameAsを含む構造化データをクロール・インデックスするまで数日〜数週間かかることがあります。さらにKnowledge Graphへの反映やKnowledge Panelの表示は数ヶ月単位でじっくり変化するケースが多いです。焦らず継続することが大切です。
  • sameAsはどのURLを最低限入れればいいですか?
    • 最低限入れたいのは、公式サイトのURL(自分自身のドメイン)と、存在する場合はWikipedia・WikidataのURLです。それに加えて、実際に運用している公式SNSアカウントのURLを2〜3件追加するだけでも十分なスタートになります。
  • Wordpressを使っています。HTMLを触らなくてもsameAsを設定できますか?
    • はい、可能です。Yoast SEOやRank Math SEOなどのSEOプラグインを使えば、設定画面からOrganizationやPersonの情報を入力するだけで、自動でJSON-LDが出力されます。プラグインによってはsameAsの入力欄も用意されています。
  • Knowledge Panelを表示させるためにはsameAsだけで十分ですか?
    • sameAsは有効な手段のひとつですが、それだけでKnowledge Panelが表示されるわけではありません。Googleビジネスプロフィールの整備・Wikidataへの登録・信頼できる外部サイトからの言及なども組み合わせることで、Knowledge Panelが表示される可能性が高まります。
  • sameAsに設定するURLは多ければ多いほどよいですか?
    • 数が多ければよいわけではありません。実在しないURLや、そのエンティティと関係のないページを含めるとマイナスに働く可能性があります。使うURLは「実際に存在する」「そのエンティティを正しく指している」ものに限定し、質を重視して選ぶようにしましょう。
中村 一浩

監修者紹介

中村 一浩

代表取締役CEO

株式会社ココログラフ 代表取締役CEO。1982年生まれ。高校卒業後に携帯販売業界にて、インターネットとハードウェアの急速な進化に触れた後、ウェブの面白さに惹かれ、2009年に株式会社ジオコードに入社。SEOを中心にウェブマーケティングを学び、同時にウェブ制作部門、システム開発部門のマネジメントも兼務。幅広いウェブ運用知識を有する。2018年に独立・起業し、検索エンジンだけでなく検索ユーザーにまで最適化する、SEOの上位互換サービスSUOを提供。SEO / SUOの独自レポートツール、サチコレポート開発者。著書『現場のプロが教えるSEOの最新常識』(Amazon: https://amzn.to/4wPgYEK )

■得意領域
ウェブサイト改善 / SEO対策 / コンテンツマーケティング

関連記事

600社の実績、継続率78%。
“見つかる”をつくるプロに、
まず相談。

“見つかる”をつくるその先に、お客様の成果がある。ココログラフはSEO・AIO・Web制作を通じて、その実現をお手伝いします。

03-6845-138010:00〜18:00(平日)