sameAsとは 構造化データの書き方と並べてよい先を公式で確認

構造化データのsameAsとは何なのか。自社のサイトに、どう書けばよいのか。何を並べてよく、何を並べてはいけないのか。

中小企業の経営者やWeb担当者に向けて、schema.orgの定義とGoogle検索セントラルの文書を、書かれている範囲だけで確かめながら答えます。

先日、Q&Aサイトでこのような切実な悩みを拝見しました。

質問者は、Googleの検索結果で自社のサイトが「ドメイン名」で表示されていて、競合は社名やサービス名で表示されている、と書いていました。社名で見せたいと考え、公式の手順を読み、構造化データを書いてテストツールに入れたところ、「構造化データのアイテムが検出されない」と出て止まっている、という内容です。

自社の名前を、検索やAIに正しく伝えたい。その気持ちは、このプロパティを調べる人の動機と同じ場所にあります。

この記事では、先に質問へ直接答え、そのあとで書き方と注意点を順に説明します。

先に答え：sameAsは「ここに載っている同じ会社を指す」ためのプロパティ

このプロパティは、構造化データで「このデータが指しているものは、あのページに載っているものと同じです」と示すためのプロパティです。会社の場合は、自社サイトの会社概要に加えて、公式のSNSや地図のページなど、同じ会社の情報が載っているページのURLを指します。

書き方は、JSON-LDの中にURLを並べるだけです。ただし、並べてよい先には条件があります。

schema.orgの定義を、そのまま確かめる

意味は、schema.orgのプロパティの説明に書かれています。原文は英語です。

原文を日本語に直すと、「そのものの同一性をはっきり示す、参照用のウェブページのURL。たとえば、そのものについてのWikipediaのページ、Wikidataの項目、公式ウェブサイトのURL」となります。

この日本語訳は筆者によるものです。確かめたのは、schema.orgのsameAsの説明ページで、利用されるタイプはThing（あらゆるものの親のタイプ）とされています。つまり会社にも、人物にも、商品にも書けます。

同じページには、利用状況の記載もあります。Googleのウェブインデックスの2026年8月の集計にもとづき、このプロパティは1,000万を超えるドメインで使われている、と表示されていました。

Googleは、組織の構造化データの中でこう説明している

Google検索セントラルの「組織（Organization）の構造化データ」には、このプロパティの説明があります。

「組織に関する追加情報が別のウェブサイトにある場合、必要に応じてそのページの URL を含めます。たとえば、ソーシャル メディアやレビューサイトにある組織のプロフィール ページの URL などです。」

「必要に応じて」という言葉が付いています。このプロパティは、書かなければならないものではありません。同じ文書には「必須プロパティはありません」とも書かれています。

3つの答えを、先に表で見る

次の表で、全体像をつかんでください。

知りたいこと	答え	確かめた先
意味	同じものについての、別のページのURLを指す	schema.orgのsameAsの説明
書く場所	会社概要など、組織の説明を載せたページの構造化データ	Google検索セントラルの組織の文書
並べる先	自社が管理している公式のページ。管理していないページは入れない	同上と、構造化データの一般的なガイドライン

先に断っておくこと

書いても、検索順位が上がるとは、どの公式文書にも書かれていません。

AIの答えに自社が出るようになる、とも書かれていません。この点は、後の章で公式の文書を引いて確かめます。

役割は、同じ会社を指す手がかりを、機械が読める形で渡すことです。手がかりが正しければ、取り違えを減らす助けになる、というのがこの記事の立場です。

sameAsの書き方：Organizationの最小形から

ここからは、実際の書き方です。会社の情報を伝えるOrganizationの構造化データに、1項目を足します。

最小の書き方

次のJSON-LDが、最小の形です。社名や住所は架空の例です。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "株式会社サンプル商店",
  "url": "https://www.example.com/",
  "sameAs": [
    "https://www.instagram.com/example_shop/",
    "https://www.example.org/profile/sample-shop"
  ]
}
</script>

上の2行のURLは、書き方を示すための例です。実際には、自社が運営している公式のページのURLに置き換えます。

各行の意味を表で確かめる

行	意味	公式文書での扱い
@context	schema.orgの語彙を使うという宣言	構造化データの共通の書き出し
@type	このデータが組織であることを示す	最もよく当てはまるタイプを使うよう推奨
name	組織の名前	サイト名と同じ値を使うよう記載あり
url	組織のウェブサイトのURL	「Googleが組織を一意に識別するのに役立ちます」
sameAs	同じ組織についての、別のページのURL	複数指定できる

urlと外部URLの欄は、役割が違う

urlには、自社サイトの代表のURLを1つ書きます。こちらには、自社サイトの外にある、同じ会社のページを並べます。

Googleの文書は、urlについて「組織のウェブサイトのURL（必要に応じて）。これは、Google が組織を一意に識別するのに役立ちます。」と説明しています。自社サイトのURLを、外部URLの欄に重ねて書く必要はありません。

値は、1つでも配列でもよい

先頭の例のように、角括弧でURLを並べると、複数を指定できます。1つだけのときは、角括弧なしで書いても構いません。

Googleの文書の例でも、2つのURLを角括弧で並べています。書いたあとは、検証ツールに通して確かめます。

質問者のつまずきに戻る

冒頭の質問では、WebSiteの構造化データがテストツールで検出されませんでした。原因は質問文だけでは分かりません。

ただ、書いた直後に確かめる順番は決まっています。ページを公開しているか、テストツールに入れたコードがscriptタグごと正しく貼れているか、全角の引用符が混ざっていないか、です。確認の手順は、後の章でまとめます。

Person（代表者・著者）に書くときの形

会社だけでなく、人物にも同じことができます。理由は、このプロパティが、あらゆるものの親にあたるThingに属しているからです。

代表者や記事の著者を、AIや検索エンジンに取り違えられたくない場合に使います。著者情報そのものの整え方は、E-E-A-Tと著者情報の整え方で説明しています。

人物の書き方の例

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "山田 太郎",
  "jobTitle": "代表取締役",
  "url": "https://www.example.com/about/",
  "worksFor": {
    "@type": "Organization",
    "name": "株式会社サンプル商店"
  },
  "sameAs": [
    "https://www.example.org/profile/yamada-taro"
  ]
}
</script>

氏名も会社名も架空の例です。実在の人物のプロフィールを指すURLだけを、同じ欄に入れます。

同姓同名の人がいる場合に効く理由

同じ名前の人物は、世の中に何人もいます。名前だけでは、どの人物の話かを機械は決められません。

そこで、本人が管理している別のページのURLを渡します。schema.orgの説明にある「同一性をはっきり示す」という目的は、この場面でそのまま働きます。

会社と人物を、同じページでつなぐ

1つのページに会社と人物の両方を書くときは、項目どうしをつなぐ方法があります。

Googleの構造化データの一般的なガイドラインには、ページ上に複数のアイテムがあるとき、アイテムどうしを関連づけるために@idを使う、という説明があります。文書の例はレシピと動画ですが、考え方は会社と代表者にも当てはまります。

ただし、文書が例に挙げているのはレシピと動画だけです。会社と代表者での@idの使い方は、文書に明記されているわけではないので、筆者の応用として読んでください。

どこに置くか：会社概要のページに1か所で足りる

次に、書く場所です。サイトのすべてのページに入れるべきか迷う人もいますが、公式文書の説明は明快です。

Googleの文書には、次の一文があります。

「この情報を、ホームページまたは組織の説明を掲載した単一のページ（例: 企業情報ページ）に配置することをおすすめします。サイトのすべてのページに含める必要はありません。」

置き場所を、表で整理する

置き場所	向いているか	理由
ホームページ	向いている	公式文書が挙げている場所の1つ
会社概要のページ	向いている	組織の説明を載せたページとして挙げられている
すべてのページ	必要ない	「含める必要はありません」と明記されている
ブログ記事ごと	会社の情報には必要ない	会社の情報は1か所で足りる。著者情報は別の話

会社概要の本文と、書く内容を合わせる

構造化データの内容は、同じページの本文にも書かれている必要があります。

Googleの文書は、「ページの読者に表示されないコンテンツをマークアップしないでください。」と書いています。会社概要の本文にない住所や電話番号を、構造化データにだけ書くのは、この指針に反します。

会社概要の表記の揃え方は、AIに自社を正しく伝える会社概要ページの作り方にまとめています。社名の書き方が揺れていると、このプロパティを書いても手がかりが揃いません。

数は、必要な分だけでよい

並べるURLの数に、公式文書の定めはありません。Googleの文書には「sameAs URL は複数指定できます。」とあるだけです。

数を増やすことが目的ではありません。次の章で説明する条件に合うページだけを、必要な分だけ並べます。

何を並べてよく、何を並べてはいけないのか

ここがこの記事の中心です。公式の文書が直接書いているのは、「組織のプロフィールページのURL」の例までです。

その先は、公式文書が書いている原則から、筆者が判断した基準です。基準は2つの問いで決めます。「そのページの持ち主は、自社か」と「そのページは、自社そのものについて書かれているか」です。

並べてよいもの

2つの問いにどちらも「はい」と答えられるページです。

• 自社が開設して運営している、公式のSNSのプロフィール
• 自社で登録して情報を管理している、地図や口コミサイトの自社のページ
• 実在する、自社のWikidataの項目（自社の項目が実際にある場合だけ）

Googleの文書が例に挙げているのは、「ソーシャル メディアやレビューサイトにある組織のプロフィール ページ」です。

並べてはいけないもの

どちらか1つでも「いいえ」になるページは、並べません。

• 自社が管理していないページ（他人が作った紹介ページ、勝手に作られた口コミのまとめ）
• 自社の社名が一部に出てくるだけの記事（ニュースの記事、他社の事例紹介）
• 社名が似ている別の会社のページ
• すでに閉鎖した、またはログインできない古いアカウント

迷うものを、表で判定する

並べたいページ	持ち主は自社か	自社そのものの話か	判定
自社の公式SNSのプロフィール	はい	はい	並べてよい
自社が登録した地図のページ	はい	はい	並べてよい
代表者が個人で使っているSNS	代表者個人	会社の話ではない	会社には並べない。Personに書く
自社が紹介されたニュース記事	いいえ	一部だけ	並べない
取引先のサイトの事例ページ	いいえ	一部だけ	並べない
社名が同じ別の会社のページ	いいえ	いいえ	絶対に並べない

「怪しい」と思われないための注意

Googleの構造化データの一般的なガイドラインには、次の一文があります。

「関連性がないコンテンツや誤解を招くコンテンツ（虚偽のレビュー、ページの内容と関係のないコンテンツなど）をマークアップしないでください。」

無関係なページを並べると、この指針に触れるおそれがあります。同じ文書には、違反があれば手動による対策が実施されることがある、とも書かれています。

sameAsに期待してよいことと、期待しすぎないこと

書き方と並べる先が分かったところで、期待の大きさを揃えます。ここを誤解したまま作業を始めると、時間だけが過ぎます。

先に、全体の流れを図で見てください。

公式文書が書いている効果

Googleの組織の文書は、構造化データを追加する目的を、次のように説明しています。

「ホームページに組織の構造化データを追加すると、Google は組織の管理情報の詳細を把握して、検索結果で組織を明確化できるようになります。」

書かれているのは「明確化」です。順位が上がる、とは書かれていません。

検索結果に表示されるとは限らない

構造化データ全般について、Googleは次のように注意しています。

「重要: 構造化データが検索結果に表示されるとは限りません。」

正しく書いてテストを通しても、表示は約束されません。理由として、ページの主要な内容を表していない、ユーザーに見えない内容を参照している、などが挙げられています。

生成AI検索には、特別なマークアップは要らない

AIの答えに出たい人にとって、最も大事な一文です。Google検索セントラルの生成AI向けの文書に、次の記載があります。

「生成 AI 検索に構造化データは必要ありません。追加する必要がある特別な schema.org マークアップもありません。」

続けて、リッチリザルトの対象になる助けになるので、SEO全体の一部として使うことは勧められています。

つまりこのプロパティは、AIに出るための魔法の設定ではありません。名前の取り違えを減らす土台の1つ、という位置づけです。

期待の大きさを、表で揃える

期待すること	公式文書の記載	判断
検索順位が上がる	書かれていない	期待しない
AIの答えに出る	特別な対策は不要と明記	期待しない
組織を明確に識別される助けになる	「明確化できるようになります」と記載	期待してよい。ただし表示の保証は無い
社名の取り違えが減る	直接の記載は無い	手がかりの1つとして試す。結果は点検で確かめる

弊社が測った、AIの答えに自社の名前が出る現実

公式文書の話は、ここまでです。実際に、AIの答えに自社のページは出るのか。弊社は自社で測っています。

条件を先に書きます。結果だけが一人歩きすると、誤解を招くからです。

測ったのはClaudeであり、Googleではない

測定の相手は、Anthropic社のClaudeです。GoogleのAIモードやAIによる概要ではありません。

数字は、AIの答えに自社が出ることの難しさを示す参考として読んでください。

社名なしの質問を聞くと、22回中1回だった

弊社は2026年10月に、Claudeで各2回、社名を入れずに事業に関わる11問を質問しました。

合計22回の回答のうち、弊社のページが引用元に入ったのは1回でした。

弊社はLLMOの記事を書いている会社です。それでも、社名なしで聞かれると、ほとんど出てきませんでした。

社名を入れて聞く場面は、別の話になる

この測定は、社名を入れない質問の結果です。読者の悩みである「社名を入れたときに、別の会社と混同される」は、測っていません。

だから次の章では、弊社の数字を借りずに、読者が自分で確かめる手順を書きます。

測定結果の読み方

見るところ	内容	読み方
質問	社名を入れない11問	買い手が最初に打つ形に近い
回数	各2回で22回	少ない。傾向の参考にとどめる
結果	引用元に入ったのは1回	出ることは約束されない
相手	Claude、2026年10月	Googleの結果とは別に測る必要がある

AIの答えで社名が混同されるときの点検

ここからが実践です。AIの答えで、自社が別の会社として説明されたり、情報が混ざったりするときの確かめ方を説明します。

構造化データは、点検の最後に出てくる直し方の1つです。最初にやるのは、何が起きているかを記録することです。

手順1：社名を含む質問を3種類つくる

質問は、次の3種類を用意します。

質問の型	例	見たいこと
社名だけ	株式会社サンプル商店とは	会社の説明が合っているか
社名と所在地	株式会社サンプル商店 大阪	別の会社と混ざっていないか
社名と事業	株式会社サンプル商店 どんな事業	事業の内容が合っているか

手順2：同じ質問を、複数のAIに聞いて記録する

AIは、聞くたびに答えが変わります。1回の結果で判断しないでください。

同じ質問を、ChatGPT・Gemini・Claude・Perplexityなどで、それぞれ数回ずつ聞きます。答えと、引用元として出たページを、日付つきで記録します。

手順3：間違いの型に分ける

記録を見て、間違いを型に分けます。型が分かると、直す場所が決まります。

間違いの型	例	疑う原因
別の会社の情報が混ざる	同じ社名の別の会社の事業が出る	同名の会社がいる
古い情報が出る	移転前の住所、旧社名	外部の古いページが残っている
事業の説明が違う	扱っていないサービスが出る	自社の説明が少ない、表記が揺れている
会社が見つからない	一般的な説明しか出ない	公式のページが少ない

手順4：AIが引用元にしたページを開く

AIの答えに、引用元のページが付いているときは、そのページを実際に開きます。

間違いの出どころが、そこに書かれていることがあります。自社の古い紹介記事、移転前のプロフィール、同名の別の会社のページなど、原因が目で見て分かります。

引用元が付かないときは、答えの中の文を、そのまま検索してみます。同じ言い回しのページが見つかることがあります。

手順5：記録を月に1回、同じ質問で取り直す

直したあとの確認は、同じ質問を同じ方法で聞くことで行います。質問を変えると、前の結果と比べられません。

弊社の測定でも、記事を足した直後の追加測定では、変化はすぐに現れませんでした。直した結果は、時間をかけて確かめる前提で、記録を残します。

記録表は、1枚で足りる

欄	書く内容
日付	聞いた日
AIの名前	どのAIに聞いたか
質問	3種類のどれか
答えの要約	合っている点と、間違っている点
引用元	出たページのURL
間違いの型	上の表の4つのどれか

混同の型ごとの直し方：構造化データは直し方の1つにすぎない

点検で間違いの型が分かったら、型ごとに直す場所を決めます。構造化データを書き足す前に、他の場所で済むことが多いからです。

直す場所を、表で決める

間違いの型	まず直す場所	構造化データの出番
別の会社の情報が混ざる	自社の会社概要に、所在地と事業を具体的に書く	住所と電話番号、公式ページのURLで手がかりを足す
古い情報が出る	外部の古いプロフィールを自分で更新する	更新した公式ページを指す
事業の説明が違う	会社概要と事業のページで、同じ言葉で説明する	説明文を会社概要の本文と合わせる
会社が見つからない	公式のプロフィールを開設して、情報を揃える	開設した公式ページを指す

1つ目の手当て：自社サイトの会社概要を整える

最初に直すのは、自社の会社概要のページです。社名、所在地、事業の説明、代表者名、設立年を、1か所にまとめて書きます。

構造化データは、ページの内容を機械が読める形にしたものです。元の本文が曖昧だと、手がかりも曖昧になります。

2つ目の手当て：外部の公式ページの表記を揃える

次に、自社が管理している外部のページを開きます。SNSのプロフィール、地図のページ、各種の登録サイトです。

社名の表記、住所、電話番号、事業の説明が、会社概要と同じかを見比べます。1文字違いの社名も、取り違えの原因になり得ます。

3つ目の手当て：揃ったページだけを、構造化データで指す

表記が揃ったページだけを、自社サイトの構造化データに並べます。揃っていないページを並べても、食い違いがそのまま機械に渡るだけです。

この順番を守ることが、この記事で最も伝えたいことです。

同名の別の会社がいるときの考え方

同じ社名の別の会社がある場合は、構造化データだけで解決しようとしないでください。

所在地、設立年、事業の内容といった、2つの会社を見分ける情報を、会社概要の本文に具体的に書きます。見分けがつく情報があれば、読み手にも機械にも、区別の手がかりになります。

質問者の悩みに戻る：検索結果の社名表示とWebSiteの構造化データ

冒頭の質問が尋ねていたのは、検索結果での社名の見え方でした。同じ「社名を正しく伝えたい」という悩みなので、公式文書で確かめた範囲を書きます。

検索結果の社名は「サイト名」と呼ばれる

Google検索セントラルの「Google 検索に対してサイト名を指定する」には、検索結果に表示される取得元サイトの名前を、サイト名と呼ぶと書かれています。

サイト名はページごとのタイトルとは異なり、サイト全体で1つです。

希望するサイト名を伝える方法

文書には、次の説明があります。

「希望するサイト名を指定するには、ホームページに WebSite 構造化データを追加します。」

サイト名の決定には、タイトルや見出し、og:site_nameなども考慮されます。ただ、希望する名前を伝えるためにはWebSite構造化データが最も重要だと書かれています。

手動では変えられない

文書は、「Google では自動生成されたサイト名を手動で変更することはできません。」とも書いています。

希望を出せるだけで、必ずその名前が表示されるとは限りません。表示の確定は、Google側の自動の判断です。

書く場所と、必要なプロパティ

項目	文書の記載
書く場所	サイトのホームページ。サイトのすべてのページに追加する必要はない
必須プロパティ	name（ウェブサイトの名前）とurl（ホームページのURL）
省略可能なプロパティ	alternateName（略称などの代替名）
単位	ドメインまたはサブドメインごとに1つ。サブディレクトリには対応していない
名前の条件	ホームページ全体で一貫した名前。他の情報源の名前と一致させる

組織の構造化データとの関係

組織の構造化データの文書には、nameとalternateNameについて、「サイト名に使用しているのと同じ name と alternateName を使用します。」という記載があります。

つまり、WebSiteと組織の2つの構造化データで、社名の表記は同じにします。ここが食い違うと、手がかりが割れます。

組織の構造化データの全体像は、組織（Organization）の構造化データの解説で説明しています。

質問者が確かめるとよい点

テストツールで項目が検出されなかった原因は、質問文だけでは断定できません。確かめる点を、表にします。

確かめる点	見る場所
コードをホームページに設置して公開しているか	実際のページのソース
scriptタグごと、記号を壊さずに貼れているか	全角の引用符や、波括弧の欠けがないか
公開したURLを、URLで入力して検査したか	リッチリザルトテスト
ホームページがクロールできる状態か	robots.txt、noindex、ログインの要否

書いたあとの確認手順：公式文書の順に進める

構造化データは、書いて終わりではありません。組織の文書が示している手順に沿って、順に確かめます。

手順1：リッチリザルトテストで検証する

文書には、「リッチリザルト テストでコードを検証し、重大なエラーを修正します。」と書かれています。

重大ではない問題の修正も検討するよう、勧められています。ただし、リッチリザルトの対象になるために必ずしも必要ではない、とも書かれています。

手順2：URL検査で、Googleがページをどう見ているか確かめる

構造化データを入れたページを数ページ公開したら、URL検査ツールで、Googleにページがどう表示されるかをテストします。

Googleがページにアクセスできること、robots.txt、noindexタグ、ログインの要件でブロックされていないことを確かめます。

手順3：再クロールをリクエストして、数日待つ

ページが正常に表示されたら、Googleにそのページの再クロールを依頼できます。

文書は、ページを公開した後にGoogleが検出してクロールするまで、数日かかる場合があると注意しています。書いた当日に反映されなくても、慌てません。

手順4：サイトマップを送信しておく

今後の変更をGoogleに伝え続けるために、サイトマップの送信が勧められています。会社概要のページの内容を変えたときも、更新が伝わりやすくなります。

手順5：エラーのレポートを、月に1回見る

文書は、構造化データのエラーの一覧と、解析不能な構造化データに関するレポートを確認するよう案内しています。

社名や住所を変更したときは、会社概要の本文と構造化データを同じ日に直します。片方だけ直すと、食い違いが生まれます。

確認手順を、表にまとめる

順番	何をするか	使う場所	終わりの目安
1	コードを検証する	リッチリザルトテスト	重大なエラーが無い
2	公開ページの見え方を確かめる	URL検査	Googleがアクセスできている
3	再クロールを依頼する	URL検査	数日待つ
4	更新を伝え続ける	サイトマップ	送信済み
5	エラーを監視する	Search Consoleのレポート	月に1回見て、エラーが無い

よくある失敗：sameAsで避けたい書き方

ここまでの内容を踏まえて、実際に起きやすい失敗を整理します。公式文書に直接書かれていないものは、筆者の判断です。

失敗1：数を増やすために、関係の薄いページを足す

並べる数に決まりはありません。数を増やしても、効果が増えるという記載は、どの公式文書にもありません。

関係の薄いページが混ざると、前の章で見たように、無関係なコンテンツをマークアップしない、という指針に触れるおそれがあります。

失敗2：構造化データにだけ、本文にない情報を書く

会社概要の本文に書いていない住所や電話番号を、構造化データにだけ入れる書き方です。ページの読者に表示されないコンテンツをマークアップしない、という指針に反します。

書き足したい情報があるときは、先に本文へ書き、そのあと構造化データを合わせます。

失敗3：古いアカウントのURLを残す

閉鎖したアカウントや、ログインできなくなったプロフィールのURLが、構造化データに残っているケースです。

年に1回は、並べたURLを実際に開いて、自社が管理できているかを確かめます。

失敗4：社名の表記が、ページごとに違う

ある場所では「株式会社サンプル商店」、別の場所では「サンプル商店(株)」と書かれている状態です。

構造化データを足す前に、表記を1つに決めます。決め方は、会社概要ページの作り方で説明しています。

失敗5：書いただけで、確かめない

書いたあとにテストを通さず、公開しっぱなしにするケースです。引用符の誤りや波括弧の欠けは、見た目では気づきません。

検証と、年に1回の再点検を、作業の一部に入れます。

失敗を表で見比べる

失敗	何が起きるか	防ぎ方
関係の薄いページを足す	指針に触れるおそれ	2つの問いで、並べる前に判定する
本文にない情報を書く	指針に反する	本文を先に直す
古いURLを残す	古い情報を指し続ける	年に1回、全URLを開く
表記が揺れている	手がかりが割れる	表記を1つに決める
確かめない	誤りが残る	検証と再点検を作業に入れる

最初の3か月の進め方

作業は、小さく始められます。中小企業の担当者が1人で進める場合の、目安の順番です。

1か月目：現状の記録をつくる

最初の月は、直す前の記録を取る月です。社名を含む3種類の質問を、複数のAIに聞き、記録表に残します。

あわせて、自社が管理している外部のページを全部書き出します。数えてみると、忘れていたアカウントが出てくることがあります。

2か月目：表記を揃えて、構造化データを書く

2か月目は、会社概要と外部の公式ページの表記を揃えます。揃った分から、構造化データに並べます。

書いたら、前の章の手順で検証し、再クロールを依頼します。構造化データ全体の組み立て方は、中小企業の構造化データ入門が参考になります。

3か月目：同じ質問で取り直して、比べる

3か月目は、最初と同じ質問を、同じAIに聞いて記録します。間違いの型が減ったか、増えたかを比べます。

変化が無くても、それ自体が情報です。原因が表記以外にあるかもしれないので、記録表の引用元のページを、もう一度開いて確かめます。

検索結果の見え方は、別の話として扱う

ナレッジパネルの表示や、組織の情報の確認については、別の記事で説明しています。

関心がある場合は、ナレッジパネルが表示されない中小企業へを参照してください。

よくある質問

Q. sameAsを書かないと、何か困りますか？

困りません。Googleの文書では、このプロパティを含めるのは「必要に応じて」とされ、必須プロパティは無い、と書かれています。

書く目的は、同じ会社を指す手がかりを、機械が読める形で渡すことです。

Q. sameAsを書けば、AIの答えに自社が出ますか？

出る保証は、公式文書のどこにもありません。Googleは、生成AI検索に構造化データは必要なく、追加する必要がある特別なschema.orgのマークアップも無い、と書いています。

社名の取り違えを減らす手がかりの1つとして使い、結果は点検の記録で確かめます。

Q. FacebookやXなど、SNSのURLを入れてもよいですか？

自社が運営している公式のアカウントであれば、並べてよいと考えます。Googleの文書も、ソーシャルメディアにある組織のプロフィールページを例に挙げています。

代表者が個人で使っているアカウントは、会社のデータに入れず、人物のデータに書きます。

Q. WikipediaやWikidataのURLは必要ですか？

必要ではありません。schema.orgの説明は、参照用のページの例としてこれらを挙げていますが、自社の項目が実際にある場合の話です。

項目が無いのに、近い名前の別の項目を指すと、取り違えの原因になります。無ければ、書きません。

Q. 会社と代表者の両方に、sameAsを書く必要がありますか？

どちらも必須ではありません。社名の取り違えが悩みなら、会社から始めます。代表者や著者の取り違えが悩みなら、人物のデータにも書きます。

まとめ

sameAsは、構造化データで「別のページに載っているものと同じです」と示すプロパティです。会社の場合は、組織の構造化データの中に、自社が管理している公式のページのURLを並べます。

Googleの文書では、書くかどうかは任意です。書く場所は、ホームページか会社概要のページで足ります。

並べてよいのは、持ち主が自社で、自社そのものについて書かれたページです。管理していないページや、無関係なページは並べません。

書いても、順位が上がる、AIの答えに出る、といった効果は公式文書に書かれていません。社名の取り違えが起きているなら、先に点検で型を調べ、会社概要と外部ページの表記を揃えます。そのうえで、揃ったページを指します。

作業は、記録、表記の統一、構造化データの追加、取り直しの順です。小さく始めて、同じ質問で結果を確かめます。

今日できる点検

次の表の項目を、上から順に確かめてください。1項目ずつ、15分以内に終わります。

点検の項目	確かめる場所	合格の目安	直すこと
社名を含む質問3種類を、AIに聞いた	複数のAI	答えが記録されている	記録表を作る
自社が管理している外部ページを書き出した	社内の記録	一覧が1枚ある	忘れているアカウントを探す
社名・住所・電話番号の表記が揃っている	会社概要と外部ページ	すべて同じ表記	表記を1つに決めて直す
並べるURLが2つの問いに合格している	一覧表	持ち主が自社で、自社の話	合格しないURLは外す
構造化データを検証した	リッチリザルトテスト	重大なエラーが無い	コードを直す
会社概要の本文とデータの内容が同じ	実際のページ	本文にない情報が無い	本文を先に直す
再クロールを依頼した	URL検査	リクエスト済み	数日後に再確認する

ページを増やしても問い合わせが来ないなら、原因はページの外にあります。その場合は、下の入口からご相談ください。