この記事の要点:
- エンティティSEOとは、自社・人物・商品などを、検索エンジンやAIが「どの対象の話か」を取り違えずに理解できるよう、名前・基本情報・つながりを整える取り組みです。Googleの公式用語ではありません。
- やることは大きく3つです。名称と基本情報をそろえる、構造化データ(Organization・著者・sameAs)で対象を示す、サイトのテーマをまとまりとして見せる、の3つです。
- 構造化データはページに見えている内容と一致させ、sameAsには同じ対象を説明する公式のページだけを書きます。
- 順位やAIの回答への採用を約束する方法ではありません。整えた後は、ナレッジパネル、Knowledge Graph Search API、Search Consoleの指名検索で状況を確かめます。
エンティティSEOとは何か
エンティティとは、人物・組織・場所・商品・概念など、ほかと区別できる「もの・こと」のことです。エンティティSEOとは、自社や自社の商品、記事を書く人などを、検索エンジンやAIが1つの対象として正しく理解できるよう、名前・情報・つながりを整える取り組みを指します。
Googleがこの名前の施策や評価の仕組みを公表しているわけではありません。名称の統一、構造化データ、著者情報、テーマの整理など、以前からある取り組みを「対象を正しく伝える」という目的でまとめた呼び方です。
判断の基準は単純です。自社名で検索したとき、またはAIに自社のことを尋ねたときに、別の会社と混同されず、正しい基本情報で説明されるか。そのための材料がウェブ上にそろっているかが、エンティティSEOで見る点です。
キーワードとエンティティは何が違うのか
キーワードは「検索される言葉」、エンティティは「その言葉が指す対象」です。同じ言葉が別の対象を指すことがあるため、検索エンジンは文脈から対象を見分けようとします。語の一致ではなく意味で情報を探す検索の仕組みはセマンティック検索の記事で説明しています。
Googleは2012年にナレッジグラフを発表した際、「things, not strings(文字列ではなく、もの)」という考え方を示しました。発表では、例として「taj mahal」が建築物・音楽家・カジノのどれを指すかを見分ける話が挙げられています(Google公式ブログ)。ナレッジグラフは、人物・場所・組織などの事実と関係をまとめたもので、検索結果のナレッジパネルなどに使われています。
| 見方 | キーワード | エンティティ |
|---|---|---|
| 単位 | 検索される言葉 | 言葉が指す対象 |
| 例 | 例:「〇〇株式会社 評判」 | 例:〇〇株式会社という組織そのもの |
| 主に整えるもの | 題名・見出し・本文の言葉 | 名称、基本情報、外部の情報とのつながり |
| 確かめる場所 | Search Consoleの検索語 | ナレッジパネル、指名検索、AIの回答 |
両方は対立するものではありません。どの言葉で探されるかはキーワード選定で決め、その言葉が指す対象を取り違えられないようにするのがエンティティの側の仕事です。
整えると何が変わり、何は変わらないのか
期待できることと、期待しすぎてはいけないことを分けておきます。
| 期待できること | 約束されないこと |
|---|---|
| 同じ名前の別の会社・人物と取り違えられにくくなる | 検索順位が上がること |
| ロゴや公式サイトのURLなど、表示に使う情報の候補をGoogleに伝えられる | ナレッジパネルが表示されること |
| 誰が書いた記事かを機械にも読める形で示せる | AIの回答で自社が取り上げられること |
| 古い社名や所在地が混ざる原因を減らせる | 外部サイトに残る誤った情報が消えること |
Googleは、組織(Organization)の構造化データについて、運営の詳細を理解し、検索結果で組織を区別するのに役立つと説明しています。ロゴのように表示に影響しうる項目もありますが、表示するかどうかはGoogleが判断します(組織の構造化データ)。
AIの回答は、学習した文章や検索したページをもとに作られます。自社について書かれた情報がばらばらだと、古い情報や別の会社の情報で説明される可能性があります。エンティティを整えることは、その可能性を減らす土台の一つです。
自社の情報を整える手順
最初に「どの対象を伝えるか」を決めます。多くのサイトでは、運営する組織、記事を書く人、主な商品・サービスの3種類です。次の順に進めると、手戻りが少なくなります。
- 名称を決める:正式名称、略称、英語表記を1つずつ決めます。商品名・サービス名も同じです。表記ゆれ(例:全角と半角、「株式会社」の位置)を一覧にしておきます。
- 基本情報のページを作る:社名、所在地、連絡先、事業内容、代表者を会社概要のページにまとめます。運営者が分かることは、読者の信頼にもつながります。
- 著者のページを作る:記事に著者名を表示し、経歴や担当分野をまとめたプロフィールページへリンクします。
- 外部のプロフィールをそろえる:公式SNS、店舗ならGoogleビジネスプロフィールなど、自社が管理する外部のページで、名称・所在地・公式サイトのURLを合わせます。旧社名や古い所在地が残っていないかも確かめます。
- 構造化データで示す:決めた名称と、そろえた外部ページのURLを構造化データに書きます(次の節)。
- テーマのまとまりを作る:事業に関わるテーマを、まとめのページと詳しい記事で体系的に扱い、内部リンクでつなぎます。
サイトの種類ごとの優先順位
すべてを一度に整える必要はありません。サイトの種類によって、先に手を付ける対象が変わります。
| サイトの種類 | 最初に整える対象 | 次に整える対象 |
|---|---|---|
| 会社のサイト | 社名・会社概要・トップページのOrganization | 商品・サービス名の表記、公式SNSとのsameAs |
| 記事が中心のメディア | 著者名・プロフィールページ・記事のauthor | テーマごとのまとめページ |
| 店舗・地域のビジネス | Googleビジネスプロフィールと公式サイトの名称・所在地・電話番号 | 店舗ページの情報とトップページのOrganization |
| 個人で運営するサイト | 運営者の名前・プロフィールページ | 外部のプロフィール(SNSなど)とのsameAs |
名称の一覧の作り方
手順1の名称は、表にして社内で共有すると表記ゆれが減ります。例として、次のような列を用意します。
| 対象 | 正式名称 | 略称・英語表記 | 使わない表記 | 説明しているURL |
|---|---|---|---|---|
| 例:運営会社 | 例株式会社 | 例社/Example Inc. | (株)例、例 株式会社 | 会社概要のページ |
| 例:主力サービス | 例サービス | Example Service | れいサービス | サービス紹介のページ |
「説明しているURL」の列は、そのまま構造化データの url や sameAs の候補になります。旧社名がある場合は、別の行に「旧称」として残し、新旧の関係を会社概要に書いておくと、読者にも機械にも経緯が伝わります。
外部サイトに誤った情報が載っている場合、ナレッジパネルのヘルプでは、まずその情報源に連絡し、それでも変わらない場合にフィードバックを送る流れが示されています。店舗などの事業者の情報は、ナレッジパネルではなくGoogleビジネスプロフィールから変更を提案します(ナレッジパネルについて)。
構造化データで対象を示す方法
構造化データは、ページの内容を機械が読める形で書き添えるものです。エンティティSEOでよく使うのは次の4つです。
| 書く場所 | 型・項目 | 役割 |
|---|---|---|
| トップページ | Organization(name・url・logo・sameAs) | 運営する組織を示す |
| 著者のプロフィールページ | ProfilePage と Person | 書き手を示す |
| 記事 | Article・BlogPosting の author(名前と url) | 記事と書き手をつなぐ |
| 記事・一覧ページ | about・mentions(schema.org の項目) | 何について書いたかを示す |
組織とsameAsの書き方
sameAsには、同じ組織について説明している別のページのURLを書きます。Googleの説明では、SNSや口コミのプロフィールなどが例に挙がっています。@idを決めておくと、ほかの構造化データから同じ組織を指せます。
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "例株式会社",
"url": "https://example.com/",
"logo": "https://example.com/logo.png",
"sameAs": [
"https://公式SNSのURL",
"https://自社が管理する外部プロフィールのURL"
]
}
上は説明用の例です。名前やロゴは、ページに見えている内容と一致させます。
著者の書き方
Googleの記事の構造化データのガイドでは、著者が人なら Person、組織なら Organization を使い、author.urlには著者を一意に示すページ(プロフィールページなど)を書くよう勧めています。名前の欄には肩書きを入れず、名前だけを書きます。サイト内のプロフィールページは ProfilePage でマークアップし、sameAs で外部のプロフィールを示すこともできます(記事の構造化データ)。
aboutとmentionsの扱い
about(主に扱うテーマ)と mentions(触れている対象)は schema.org の項目です。Googleがサポートする構造化データの一覧(検索ギャラリー)には含まれておらず、リッチリザルトの対象ではありません。検索での使われ方は公表されていないため、効果を断定せず、記事の主題を整理する道具として使うのが無難です。
記事側では、次のように著者と主題を1つの構造化データにまとめて書けます。publisher には、トップページで決めた組織の @id を指定すると、別々に書いた情報が同じ組織だと分かります。
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "記事の題名",
"author": {
"@type": "Person",
"name": "山田花子",
"url": "https://example.com/authors/yamada/"
},
"publisher": { "@id": "https://example.com/#organization" },
"about": { "@type": "Thing", "name": "記事の主題" }
}
これも説明用の例です。著者名やプロフィールのURLは、記事に表示している内容と同じにします。
サイトのテーマをどうまとめるか(当サイトの例)
個々の記事だけでなく、「このサイトはどの分野について詳しいか」も伝わるようにします。テーマごとに、全体を説明するページと個別の記事を作り、相互にリンクします。考え方は「ピラーページ」で説明しています。
当サイト(seoagent.jp)では、記事の主題を検索エンジンに推測させる状態で、カテゴリーページは記事が並ぶだけでした。そこで次のように組み替えました。
- 記事ごとに主題・扱うテーマ・言及する対象を決め、構造化データで宣言しました。辞書は93語で、WikidataのIDは確認できた語だけに付けています。
- カテゴリーを解説文付きのトピックページにし、CollectionPageの構造化データを入れました。記事には mainEntity・about・mentions を入れています。
- パンくずリストと記事下の案内から、トピックページを経由するようにしました。記事のURLは変えず、分類だけを組み替えています。
この変更による順位や流入の変化は、まだ測定前のため書けません。確かめ方は次の節のとおりです。組み替えた先の例として、LLMO対策の記事一覧もトピックページの1つです。
認識されているかを確かめる方法
エンティティの状態は、1つの数字では分かりません。次の4つを組み合わせて見ます。
| 確かめ方 | 分かること | 注意点 |
|---|---|---|
| 自社名・人名で検索する | ナレッジパネルの有無と、表示される内容 | 表示は自動判断で、出ないことも多い |
| Knowledge Graph Search API | ナレッジグラフに該当する対象があるか、種類(Organizationなど) | APIキーが必要。結果は検索の表示と同じとは限らない |
| Schema Markup Validator | 構造化データが文法どおり読めるか | about・mentions はリッチリザルト テストには出ない |
| Search Consoleの検索パフォーマンス | 社名・商品名を含む検索の表示回数とクリック | 指名検索のフィルタは表示回数の少ないサイトでは使えない |
AIの回答を確かめるときは、次の手順で記録すると比べやすくなります。
- 確かめる質問を3〜5個決めます。例:「〇〇株式会社とは」「〇〇サービスの運営会社は」。
- 使ったAIの名前、日付、質問、回答の要点を表に残します。
- 社名・所在地・事業内容に誤りがあれば、その情報がどこから来ていそうかを、回答に示された出典から探します。
- 自社が管理するページなら直し、外部のページなら運営者に連絡します。
- 同じ質問を、間隔を空けて繰り返します。
社名を含む検索の見方は「指名検索とは」で説明しています。AIの回答は質問のしかたや時期で変わるため、同じ質問を日付と一緒に記録し、変化を比べるのが現実的です。
よくある間違い
- sameAsに、自社と関係のないページや、他社が書いた紹介記事を入れる
- 構造化データに、ページにない情報や事実と違う情報を書く
- 会社概要、フッター、SNSで社名やURLの表記が違う
- 著者の名前の欄に肩書きや社名まで入れる
- 本業と関係の薄いテーマまで宣言し、何の専門のサイトかがぼやける
- 構造化データを入れた直後に、検索結果やAIの回答が変わると考える
どれも「機械に伝える情報」と「人に見せている情報」がずれることで起きます。迷ったら、ページに見えている内容に合わせます。
よくある質問
小さな会社や個人でもエンティティSEOは必要ですか?
名称の統一、会社概要、著者情報は規模に関係なく役に立ちます。構造化データも、トップページのOrganizationと記事の著者から始めれば十分です。会社のサイト全体で何から手を付けるかは「コーポレートサイトのSEO」で説明しています。
Wikipediaに載っていないと認識されませんか?
Googleは、ナレッジグラフの情報はさまざまな公開情報から集めると説明しています。特定のサイトへの掲載が条件だとは示していません。まず自社が管理できる情報をそろえます。
ナレッジパネルは申請すれば表示されますか?
申請で表示されるものではありません。表示はGoogleが自動で判断します。すでに表示されている場合は、本人や代表者が認証を受けて変更を提案できることがあります。
sameAsにはいくつURLを書けばよいですか?
決まった数はありません。同じ対象を説明している公式のページだけを書きます。数を増やすより、すべてが同じ名称・同じ公式サイトを指していることが大切です。
構造化データはプラグインで入れても大丈夫ですか?
問題ありません。ただし、複数のプラグインがそれぞれOrganizationを出力していないか、名前やロゴが会社概要と一致しているかを、Schema Markup Validatorで確かめます。
SEOAGENTでできること
SEOAGENTでは、自社の資料や文体を登録して記事の材料にし、テーマごとの記事のまとまりと、記事どうしのつながりを確認できます。



