sameAsとは？SNSとサイトの紐づけを自分で検証する手順

SNSのプロフィールに自分のサイトURLを置き、サイト側からもSNSへリンクする。この「つなぎ方」がGoogleにどう伝わるのかを、構造化データの sameAs という1つのプロパティに絞って整理します。

sameAs とは、あるSNSプロフィールや外部ページが、自分のサイトと同じ主体（同じ人・同じ組織）を指していることをGoogleに伝えるための、構造化データのプロパティです。schema.org の定義は「その項目の同一性を明確に示す参照WebページのURL」であり、検索順位を上げるための仕組みではありません。

この記事は、Googleが公式ドキュメントで実際に明言している範囲だけを扱います。そのうえで、自分のサイトで sameAs が本当に出力されているか、書いたURLが生きているか、SNS側と双方向になっているかを、curl 4本で合否まで出す手順を用意しました。所要は5分ほどです。

なお、この記事では構造化データの実装コードそのものは掲載しません。書式は公式ドキュメントに正確なサンプルが載っており、仕様が更新されたときに古い写しだけが残るのを避けるためです。ここで扱うのは「何を書くか（項目）」と「書いたものが実際に効いているかをどう確かめるか（検証）」の2つです。

sameAsとは何か｜SNSとサイトを「同じ主体」だと伝えるプロパティ

sameAs は schema.org が定義している汎用のプロパティで、Thing（schema.org が扱うあらゆる項目）に対して使えます。定義は次のとおりです。

URL of a reference Web page that unambiguously indicates the item’s identity. E.g. the URL of the item’s Wikipedia page, Wikidata entry, or official website.（その項目の同一性を明確に示す参照WebページのURL。例えば、その項目のWikipediaページ、Wikidataのエントリ、公式サイトのURL）

schema.org「sameAs」

ここに書かれているのは「同一性（identity）を明確に示す」までです。集客でも、リンクの評価でもありません。出典は schema.org のプロパティ定義ページ（2026-08-02取得）です。

Googleのドキュメントでの位置づけ

Google 検索セントラルの Organization 構造化データのドキュメントでは、sameAs はこう説明されています。

The URL of a page on another website with additional information about your organization, if applicable. For example, a URL to your organization’s profile page on a social media or review site. You can provide multiple sameAs URLs.（該当する場合、自分の組織に関する追加情報を掲載した別サイト上のページのURL。例えば、SNSやレビューサイト上にある組織のプロフィールページのURL。sameAs のURLは複数指定できます）

Google 検索セントラル「Organization (Organization) structured data」

「重要な要素です」とも「評価が上がります」とも書かれていません。ドキュメント冒頭にある効能の説明も、次の1文だけです。

Adding organization structured data to your home page can help Google better understand your organization’s administrative details and disambiguate your organization in search results.（トップページに組織の構造化データを追加すると、Googleが組織の管理情報をより正確に理解し、検索結果であなたの組織を他と区別しやすくなります）

Google 検索セントラル「Organization (Organization) structured data」

鍵になる語は disambiguate（曖昧性の解消） です。同名の別組織や別人と取り違えられないようにする、という識別の話であって、順位の話ではありません。sameAs に期待してよい上限は、公式ドキュメントの言葉でいえばここまでです。出典は Google 検索セントラルの Organization ドキュメント（2026-08-02取得・英語版）です。

「リンクの評価」とは別のレイヤーにある

SNSプロフィールに置いたサイトURLには、多くの場合 nofollow が付きます（後述の実測どおりです）。ここから「nofollow だから無意味」と説明されることがありますが、2点で不正確です。

• Googleは2019年9月10日以降、nofollow を含む rel 属性を「命令」ではなく「ヒント（hint）」として扱っている。「効果がゼロ」と断定はできない
• sameAs はHTMLのリンクではなく構造化データのプロパティであり、そもそもリンク評価とは別の層にある。nofollow が付くかどうかと sameAs が機能するかどうかは、独立した話

Googleの原文は「All the link attributes—sponsored, ugc, and nofollow—are treated as hints about which links to consider or exclude within Search.（sponsored・ugc・nofollow というリンク属性はすべて、検索においてどのリンクを考慮するか除外するかについての”ヒント”として扱われます）」です。クロールとインデックスの用途についても2020年3月1日からヒント扱いになりました。出典は Google 検索セントラル ブログ「Evolving nofollow」（2019年9月10日付）（2026-08-02取得）です。

nofollow・ugc・sponsored・noreferrer の使い分けそのものは nofollowとは？dofollow・noreferrer・sponsoredとの違い にまとめてあります。この記事では「rel 値は自分では変えられない前提で、サイト側で何を宣言するか」に話を絞ります。

Googleが公式に言っていること／言っていないこと

sameAs の解説記事は多いのですが、公式が書いている範囲と、書き手が補った推測が混ざっていることがよくあります。線を引いておきます。

公式が言っている3点

1つ目は前章の disambiguate です。2つ目は、Organization には必須プロパティが存在しないことです。

There are no required properties; instead, we recommend adding as many properties that are relevant to your organization.（必須のプロパティはありません。代わりに、自分の組織に関係するプロパティをできるだけ多く追加することを推奨します）

Google 検索セントラル「Organization (Organization) structured data」

3つ目は置き場所です。ここは実装でいちばん誤解されている箇所なので、原文をそのまま引きます。

We recommend placing this information on your home page, or a single page that describes your organization, for example the about us page. You don’t need to include it on every page of your site.（この情報はトップページ、または組織を説明する単一のページ（例えば会社概要ページ）に置くことを推奨します。サイトのすべてのページに含める必要はありません）

Google 検索セントラル「Organization (Organization) structured data」

公式が言っていない4点

次の4つは、日本語の解説でよく見かけますが、Google 検索セントラルのドキュメントに対応する記述が見当たりません。

• sameAs を設定すると検索順位が上がる
• sameAs に並べるURLを増やすほど評価が積み上がる
• sameAs を書くとナレッジパネルにSNS欄が出る
• Googleには「エンティティ単位の評価」という仕組みがある

「書かれていない＝間違い」と決めつけるのは行き過ぎですが、効果を測れない主張を根拠に工数を積むのは実務上まずい判断です。sameAs は設定コストが小さいので入れる価値はありますが、期待値は「識別の補助」に据えたほうが、あとで施策の評価に困りません。

2019年に終わったこと｜Social Profile構造化データの非推奨

かつてGoogleには Social Profile 構造化データという専用の仕様があり、ナレッジパネルに表示するSNSアカウントをマークアップで指定できました。これは2019年6月に非推奨となり、2020年5月11日に公式ドキュメントから削除されています。

Removed the following documentation that has been deprecated since June 2019: Social Profile structured data: We now automatically discover social profiles to include in Google knowledge panels. If you’re verified as an official representative, you can suggest a change directly.（2019年6月から非推奨となっていた以下のドキュメントを削除しました。Social Profile 構造化データ：Googleのナレッジパネルに含めるSNSプロフィールは、現在は自動的に検出しています。公式の代表者として確認済みであれば、変更を直接提案できます）

Google 検索セントラル ドキュメント更新履歴 2020年5月11日

同じ日に Corporate Contact 構造化データも同じ理由で削除されました。出典は Google 検索セントラルの更新履歴（2026-08-02取得・英語版の2020年5月の項）です。

何が変わったのか

• ナレッジパネルに出るSNSは、マークアップの指定ではなくGoogleの自動検出で決まる
• 旧 Social Profile のドキュメントURLは現在404を返す（2026-08-02実測）。ここを出典に置いている解説記事は、更新が止まっているとみてよい
• 構造化データの対応機能一覧（検索ギャラリー）にも Social Profile は掲載されていない

今も残っているのは、Organization・Person・Article といった汎用の型に付ける sameAs です。「SNS専用の構造化データ」はもう存在しません。この点を押さえておくと、「SNSを構造化データで登録する」といった説明に出会ったときに、どこが古いのか判断できます。対応機能の現況は Google 検索セントラルの構造化データ機能ギャラリー（2026-08-02取得）で確認できます。

ナレッジパネルの表示を変えたい場合の道筋

マークアップではなく申請です。Googleは「公式の代表者として確認済みであれば、変更を直接提案できます」と書いており、その導線としてナレッジパネルのヘルプを案内しています。手順は Googleヘルプ「ナレッジパネルの情報を更新する」（2026-08-02取得）にまとまっています。

そもそもナレッジパネル自体が「出す／出さない」を運営者側で決められるものではありません。sameAs を整えることでナレッジパネルが出るようになる、という因果はGoogleが公表していないため、この記事ではそこを目標に置きません。

今も有効なsameAsの使いどころ

Googleのドキュメントで sameAs が現役として登場するのは、次の3か所です。どこに何を書くかを表にまとめます。

組織はトップか会社概要の1枚だけに置く

前章で引用したとおり、公式は「サイトのすべてのページに含める必要はありません」と明言しています。全ページに撒くと、SNSアカウントを増減させたときに更新漏れが起き、結果として矛盾した情報が残ります。1枚に集約しておくほうが、正確性を保ちやすいという実装上の理由もあります。

店舗や事務所を持つ事業者の場合、LocalBusiness は Organization のサブタイプなので、Organization 側の推奨項目に従って構いません。Googleビジネスプロフィールとの関係を含めた整理は ローカルSEOとMEOの違いとは？Webサイト側で必要な5つの対策 にあります。

著者情報は author.url でも sameAs でもよい

Article 構造化データの author について、Googleは次のように書いています。

You can use the sameAs property as an alternative. Google can understand both sameAs and url when disambiguating authors.（代替として sameAs プロパティを使うこともできます。著者を識別する際、Googleは sameAs と url のどちらも理解できます）

Google 検索セントラル「Article (Article, NewsArticle, BlogPosting) structured data」

つまり著者まわりでは、どちらか一方に統一していれば十分です。両方書いて食い違わせるほうがリスクになります。ここでもGoogleの言葉は disambiguating authors（著者の識別）であり、著者の権威づけとは書かれていません。出典は Google 検索セントラルの Article ドキュメント（2026-08-02取得）です。

自社内の著者ページには ProfilePage という選択肢がある

author.url の指す先が自サイト内のプロフィールページである場合、Googleはそのページを ProfilePage 構造化データでマークアップすることを推奨しています。ProfilePage 自体は「作成者が一次的な視点を投稿するサイト」向けの仕様として説明されており、掲示板やコミュニティのようなサイトを主な対象にしています。自社ブログの著者ページに使えないわけではありませんが、Organization の sameAs より優先度は低いと考えて構いません。

詳細は Google 検索セントラルの Profile page ドキュメント（2026-08-02取得）を参照してください。JSON-LDの書式サンプルも同ページにあります。

実装の書式そのものは、上記3つの公式ドキュメントに正確なサンプルが載っています。この記事で写しを載せないのは、仕様が更新されたときに古いコードだけが検索結果に残るためです。コピー元は必ず公式ドキュメントにしてください。そして、書いたものが本当に出ているかは、次章の手順で確かめます。

SNS側のリンクは何を返しているのか

sameAs はサイト側からSNSへの宣言ですが、SNS側からサイトへ張られるリンクの中身も見ておきます。「SNSリンクは全部 nofollow」と説明されがちなので、実際に測りました。以下は2026-08-02に curl で取得したHTMLから rel 属性を数えた結果です。

自分で数えるときのコマンドは次のとおりです。USER は確認したいアカウント名に置き換えてください。

curl -s -A "Mozilla/5.0" https://github.com/USER | grep -o 'rel="[^"]*"' | sort | uniq -c

GitHubだけ me が付く

GitHubのプロフィール欄に登録した外部リンクは、rel=”nofollow me” を返します。me は「このリンク先のプロフィールも同じ人物のものだ」という意味で使われる値です。sameAs がやろうとしていることと、ほぼ同じ内容をSNS側が自動で表明していることになります。

ただしGoogleが rel=”me” をどう扱うかは公表されていません。「me が付いているから有利」とは書けません。ここでは「主題にど真ん中で関係する値が、SNS側から自動的に付与されている」という事実だけを押さえておきます。

X・Instagramは curl では判定できない

X（旧Twitter）と Instagram は、curl で取得したHTMLの中にプロフィール欄のリンクが現れません。JavaScriptで描画されるためです。したがってこの記事では両者の rel 値について「nofollowが付いている」とは書きません（測れていないことは書かない、という方針です）。

確かめたい場合は、ブラウザの開発者ツールを開き、Elementsパネルで該当の <a> 要素を選んで rel 属性を読みます。ブラウザの「ページのソースを表示」では描画前のHTMLしか見えないため、判定にはDOMを見る必要があります。

実務上の結論はシンプルです。SNS側の rel 値は運営者が変更できません。変えられるのはサイト側の宣言だけなので、そこを正確にしておく——という順番になります。なお、SNSでの見え方（サムネイルやタイトル）を決める OGP は sameAs とはまったく別のレイヤーの話です。そちらは OGPとTwitterカードの設定方法 にまとめてあります。

自分のサイトでsameAsの合否を出す4ステップ

ここからが本題です。sameAs は「設定したつもりで出ていない」「書いたURLが古い」といった状態になりやすく、しかも見た目には何の変化も出ないため気づけません。以下の4ステップは、自分のドメインを入れるだけで合否が出ます。コマンド内の example.com は自分のドメインに置き換えてください。

ステップ1｜そもそも出力されているか

トップページのHTMLに sameAs が実際に含まれているかを見ます。

curl -s https://example.com/ | grep -o '"sameAs":\[[^]]*\]'

• 合格：sameAs の配列が1つ以上返る
• 不合格：何も返らない。原因は「テーマやプラグインが構造化データを出していない」か「JavaScriptで後から挿入している」のどちらか

後者を切り分けるには、ブラウザの開発者ツールのElementsパネル（描画後のDOM）で sameAs を検索します。そこにあれば、静的HTMLには無いがDOMには存在する、という状態です。GoogleはJavaScriptを実行したあとのHTMLも処理しますが、レンダリングは別工程になるため、まず静的に出せるなら出しておくほうが確実です。挙動の詳細は Google 検索セントラルの JavaScript SEO の基本（2026-08-02取得）にあります。

ステップ2｜型と置き場所が合っているか

返ってきた sameAs が、どの型の配下にあるのかを見ます。ページ内のJSON-LDの型を数えるとおおよそ把握できます。

curl -s https://example.com/ | grep -o '"@type":"[A-Za-z]*"' | sort | uniq -c

• 合格：Organization（または Person）が出ており、その配下に sameAs がある
• 不合格：下層ページで同じコマンドを実行しても Organization が出てくる。それは全ページに撒いている状態

全ページに出ていた場合の一手は「トップか会社概要の1枚に寄せる」です。公式が「すべてのページに含める必要はありません」と明言している以上、増やす理由がありません。

ステップ3｜書いたURLが生きているか・301していないか

ここが実務でいちばん引っかかります。SNSのURL形式変更やサービス側のドメイン移行で、数年前に書いた sameAs が黙って301になっていることがあります。ステップ1で取り出したURLを、まとめて測ります。

for u in https://github.com/USER https://qiita.com/USER; do
  printf '%s ' "$u"
  curl -s -o /dev/null -w '%{http_code} redirects=%{num_redirects}\n' -L "$u"
done

• 合格：すべて 200 かつ redirects=0
• 不合格その1：404 が返る。すでに存在しないアカウントなので sameAs から削除する
• 不合格その2：redirects が1以上。リダイレクト後の最終URLに書き換える

リダイレクトしていても表示上は問題なく動きます。ただし sameAs は「同一性を明確に示す参照URL」なので、最終的な着地URLを書いておくほうが趣旨に合います。自社サービスのサブドメインを sameAs に入れているケースで、ルートが言語別パスへ301しているのに古いURLのまま、という取りこぼしは珍しくありません。

ステップ4｜SNS側から自分のサイトへ戻っているか

sameAs はサイト側からの一方的な宣言です。プロフィール側に自分のサイトURLが無いと、片方向のままになります。Googleが双方向性をどう扱うかは公表されていませんが、プロフィール欄が空なのは単純にもったいないので、ここも合否を出しておきます。

curl -s -A "Mozilla/5.0" https://github.com/USER | grep -c 'example.com'

• 合格：1以上が返る（プロフィール側に自分のドメインが載っている）
• 不合格：0が返る。プロフィール欄にサイトURLを入れる

注意点として、X と Instagram はJavaScript描画のため、0が返っても「載っていない」とは限りません。この2つはブラウザで目視確認してください。GitHub・Zenn・Qiita は静的HTMLに出るので、上のコマンドで判定できます。

任意｜テストツールでの確認

4ステップで合格が出たら、あとは任意です。Google のリッチリザルトテストは「Googleが対応している機能として検出できるか」を、schema.org の Schema Markup Validator は「schema.org の語彙として妥当か」を見ます。見える範囲が違うので、両方で0エラーなら十分です（いずれも2026-08-02に到達確認済み）。

ここで止めて構いません。検証の結果をさらに検証する（Search Consoleの拡張レポートを日次で追う等）ところまで広げても、sameAs の場合は判断材料が増えません。4ステップが全部合格なら、サイト側でやれることは終わっています。

構造化データが実際にどう検出されているか、他の項目も含めてまとめて見たい場合は、無料のSEO診断ツールで確認できます。

やっても意味が薄い3つのこと

逆側からも書いておきます。sameAs まわりで工数を使いがちだが、公式の記述に照らすと見返りが薄い施策です。

全ページに Organization を撒く

公式が「すべてのページに含める必要はありません」と書いています。増やしても識別の材料は増えず、更新漏れのリスクだけが増えます。テーマやプラグインの設定で全ページ出力になっている場合は、トップか会社概要に絞る設定があるか確認してください。

sameAs のURLをとにかく増やす

「多いほど強い」という記述はGoogleのドキュメントにありません。むしろ、更新が止まったアカウントや、後で消すアカウントを並べると、ステップ3で404を量産することになります。運用し続けるアカウントだけを書くのが実務的です。

ナレッジパネル狙いでマークアップを盛る

SNS欄はGoogleが自動検出すると公式に明記されています。マークアップを増やしてもここは動きません。変更したいなら申請という道筋になります。同様に「構造化データを増やせばAI検索に拾われる」といった話も、公式に対応する記述はありません。AI検索まわりの用語と、公表されている範囲の整理は AIO・AEO・GEO・LLMOとは？AI時代のSEO新概念の違い にまとめてあります。

sameAs は「設定コストが小さく、正しく書けば識別の材料になり、間違っていても気づけない」という性質のプロパティです。だからこそ、盛るより年1回この記事の4ステップを回して合否を出すほうが、実際の効果は大きくなります。

よくある質問（FAQ）

Q. sameAsを設定すると検索順位は上がりますか？

順位が上がるという記述はGoogleのドキュメントにありません。Organization 構造化データについてGoogleが書いているのは「組織の管理情報を理解しやすくし、検索結果で他の組織と区別（disambiguate）しやすくなる」という識別の話までです。順位施策ではなく、識別の材料を渡す設定だと考えてください。

Q. sameAsはどのページに書けばよいですか？

トップページか、組織を説明するページ1枚（会社概要など）で十分です。Googleは「サイトのすべてのページに含める必要はありません」と明言しています。全ページに出力していると、アカウントの増減があったときに更新漏れが起きやすくなるため、1枚に集約するほうが運用も安全です。

Q. sameAsを書けばナレッジパネルにSNSが表示されますか？

表示されません。SNSを指定するための Social Profile 構造化データは2019年6月に非推奨となり、2020年5月11日に公式ドキュメントから削除されました。Googleは「ナレッジパネルに含めるSNSプロフィールは自動的に検出しています」と明記しており、表示内容を変えたい場合はマークアップではなくナレッジパネルの申請から行います。

Q. SNSプロフィールのリンクにnofollowが付いていたら無意味ですか？

無意味ではありません。Googleは2019年9月10日以降、nofollow を含むリンク属性を「命令」ではなく「ヒント」として扱っており、完全に無視されるわけではありません。そのうえで sameAs は構造化データのプロパティであり、HTMLリンクの評価とは別のレイヤーにあるため、rel 値の有無とは独立して機能します。

Q. 著者情報にもsameAsは使えますか？

使えます。Article 構造化データのドキュメントには「代替として sameAs プロパティを使うこともできます。著者を識別する際、Googleは sameAs と url のどちらも理解できます」と書かれています。どちらか一方に統一すれば十分で、両方書いて内容を食い違わせるほうがリスクになります。

Q. sameAsに書いたURLがリダイレクトしていても問題ありませんか？

動作はしますが、最終的な着地URLに書き換えるほうが確実です。sameAs は「同一性を明確に示す参照URL」なので、途中で転送が挟まらない形が趣旨に合います。本文のステップ3のコマンドで、HTTPステータスとリダイレクト回数をまとめて確認できます。

Q. 個人サイトでも設定する意味はありますか？

あります。同姓同名や似た屋号が多いほど、識別の材料を渡す価値は上がります。個人であれば Person、屋号や法人であれば Organization を使い、運用を続けるアカウントだけを sameAs に並べてください。設定コストは小さいので、本文の4ステップで合否を出せる状態にしておくことのほうが重要です。