検索結果の「サイト名」は自分で決められるのか ── 情報源の優先順位を確認する13項目（2026年9月時点）

01 何が起きたか — 検索結果に出る「サイト名」は、誰が決めているのか

検索結果のリンクの上に出ている、あの文字列

検索結果でページのリンクを見ると、URLの代わりにサイトの名前らしき文字列が表示されていることがある。これはGoogleがサイト名（Site Names）と呼んでいる機能で、Google Search Centralの「サイト名の管理」ページに、その仕組みが公開されている。多くのWEBディレクターは「titleタグに書いた文字列がそのまま出る」あるいは「サイトの正式名称を自分で登録できる」と考えがちだが、公式ページの説明は、それより少し複雑な仕組みを示している。サイト名の管理画面や申請フォームのようなものは用意されておらず、マークアップと既存のページの情報から、Googleが自動的に判断するという前提を踏まえないまま作業を進めると、いつまでも意図した名前が反映されない状態が続くことになる。

"When Google lists a page in search results, it shows the name of the site the page comes from."

（訳: Googleが検索結果にページを表示する際、そのページの発信元であるサイトの名前を表示する。）

この名前は、ページごとに変わるものではなく、サイト単位で決まる。1つのサイトの中で複数の名前が使い分けられることは想定されていない。ここでいう「サイト」の単位が具体的に何を指すのかは、次の章で確認する。

「決められる」のか、「候補を伝えられるだけ」なのか

結論から言うと、サイト運営者ができるのは候補を示すことまでである。公式ページは、自動で選ばれた名前を手動で変更する手段が無いことをはっきりと書いている。これはSearch Consoleに直接問い合わせても変えてもらえるものではなく、公式ヘルプにも個別のサポート窓口は案内されていない。

"While we can't manually change automatically selected site names, you can indicate alternatives for our automated system to consider."

（訳: 自動で選ばれたサイト名を手動で変更することはできないが、自動化されたシステムが検討するための代替案を示すことはできる。）

つまり、サイト運営者と検索結果の間には常にGoogleの自動システムが介在しており、「指定」ではなく「提案」という関係になっている。この前提を踏まえておくと、思ったとおりに反映されなかった場合の探し方も変わってくる。

なぜ、URLの文字列ではなく「名前」を表示するのか

検索結果には元々URLがそのまま表示されていた時期があり、現在でもパンくず形式でURLの階層を示す表示は残っている。サイト名という別の表示要素が加わったのは、URLの文字列だけでは、そのページがどのサイト・どの組織から発信されているかを、検索結果を見る側が瞬時に判断しにくい場合があるためだと考えられる。ドメイン名と、そのサイトが実際に名乗っている名前が一致しないケース（旧ドメインを使い続けている、海外向けドメインを使っているなど）では、この違いがより大きくなる。

02 なぜ・背景 — ページ単位の情報と、サイト単位の情報を分ける理由

titleタグが「ページの内容」を、サイト名が「発信元」を示す

titleタグは基本的に、そのページ固有の内容を要約するために使われる。一方でサイト名は、そのページがどのサイトから発信されているかという発信元の情報である。この2つの役割が同じ1つの文字列に混在すると、検索結果を見るユーザーにとって、内容と発信元のどちらを見ているのか分かりにくくなる。Googleがサイト名という別の概念を用意しているのは、この2つの役割を検索結果の表示上で分離するためだと考えられる。ページごとにtitleタグを書き分けている以上、そのすべてにサイトの正式名称を毎回含めるのは非効率であり、発信元の表示を検索エンジン側の仕組みに任せられるという点は、運営する側にとっても負担が減る変化だと言える。

この「同じ情報に見えて役割が違う」という構図は、当サイトが以前に確認した、出力自体は存在するのに実際には使われていなかった項目の事例（出力は在った。だから誰も測らなかった）とも重なる。titleタグとサイト名は見た目が近いため、「titleさえ整えれば十分」という思い込みが生まれやすい。

複数の情報源を突き合わせて、1つの答えを選ぶという設計

公式ページが示す情報源は、構造化データ・og:site_name・title・見出しなど複数にわたる。これらが常に同じ名前を示しているとは限らず、サイトの歴史が長いほど、過去の実装がバラバラに残っていることがある。Googleが複数の情報源を突き合わせて1つの名前を自動選択する設計になっているのは、単一の情報源だけに頼ると、古い表記や誤字がそのまま採用されてしまうリスクがあるためだと考えられる。

「Choosing your site name」に書かれている、選び方の基準

公式ページの「サイト名を選ぶ」というセクションには、汎用的な名前を避けること以外にも、いくつかの基準が示されている。

"Choose a unique name that accurately reflects the identity of your site."

（訳: サイトのアイデンティティを正確に反映した、独自性のある名前を選んでほしい。）

この基準に続けて、簡潔で広く認知されている名前を使うこと、ホームページ全体で名前の表記を統一すること、代替名を用意することという3つの推奨事項が並んでいる。これらはどれも新しい概念ではなく、SEOやブランディングの基本として以前から言われてきたことだが、公式がサイト名という機能の文脈で改めて明記した点に意味がある。

03 この記事で出てくる用語

og:site_nameは、OGP（Open Graph Protocol）の一部

og:site_nameは、SNSでの表示形式を定めるOpen Graph Protocolの一部として広く使われているプロパティである。もともとFacebookでの表示のために普及した経緯があるが、公式ページはこれをサイト名の判断材料の1つとして挙げている。ただし構造化データほどの重要度は無いとされている。多くのCMSやテーマには、SNSでのシェア表示を整えるためのog:site_name出力機能が標準で組み込まれていることが多く、気づかないうちに設定済みになっているケースも少なくない。その場合、この値がtitleタグやWebSite構造化データの表記とずれていないかを、あらためて確認する価値がある。

04 型別 — 適用範囲・この記事が測っていないこと・手順

🅰 適用範囲 — どの単位、どの言語に適用されるか

サイト名の機能はドメインまたはサブドメイン単位で適用され、サブディレクトリ単位（例: 1つのサイトの中の特定のカテゴリだけ）には対応していない。また、公式ページには次の記述がある。

"Site names are available in all languages where Google Search is available."

（訳: サイト名は、Google検索が利用可能なすべての言語で利用できる。）

複数言語でサイトを運営している場合の具体的な挙動（言語ごとに別の名前を示せるか等）については、公式ページに詳細な記述は無い。日本語のサイトを運営している場合は、少なくとも日本語の検索結果においてこの機能が働くことは確認できる。

適用されない範囲 — ページ単位のブランディングとは別の話

サイト名はサイト全体に1つだけ決まるものであり、ページごとに異なるブランド名を出し分けるような使い方は想定されていない。複数のブランドやサービスを1つのドメインの下で運営している場合、サブディレクトリごとに違う名前を検索結果に出したいという要望が出ることがあるが、公式ページが示す仕組みの範囲では、それはサイト名の機能では実現できない。ブランドごとにドメインまたはサブドメインを分けるかどうかは、サイト名以前の設計判断になる。

必須プロパティ以外にも、技術的な条件がある

name・urlという必須プロパティを正しく書くだけでは足りない場合がある。公式ページは、WebSite構造化データをホームページ自体に設置すること、そのホームページがGoogleにクロール可能であること、HTTPとHTTPSのように重複するホームページが存在する場合は両方に同じ構造化データを設置することを、技術的な条件として挙げている。これらはプロパティの中身ではなく、構造化データを「どこに」「どう」置くかという設置の条件であり、見落とされやすい。トップページ以外の下層ページにだけ構造化データを設置していても、サイト名の判断材料としては扱われない。

🅱 この記事が測っていないこと・分からないこと

公式ページには、複数の情報源が食い違っている場合にどの情報源が優先されるかの明確な順位付けまでは示されていない。「構造化データが最も重要」という記述はあるが、og:site_nameとtitleのどちらがより強く参照されるかという、2番目以降の順位は明記されていない。また、名前を変更してから実際に検索結果へ反映されるまでの具体的な期間についても、公式ページは数値を示していない。この記事では、そうした反映速度の比較は行っていない。同じサイトの中で構造化データとタイトルを別々の時期に修正した場合、どちらの修正がどの程度サイト名の表示に影響したのかを切り分けることも、公式の記述だけからは難しい。

🅲 手順 — 自分のサイトで確認する流れ

確認の流れは次のようになる。まずホームページのソースを開き、titleタグ・og:site_name・WebSite構造化データのnameプロパティの3つを見比べ、同じ名前を示しているかを確認する。次に、実際の検索結果でそのサイトがどう表示されているかを検索して確かめる。もし意図した名前と違う場合は、公式ページの「望ましいサイト名が選択されない場合」に示された確認項目（構造化データの記法・ホームページのクロール可否・情報源同士の一致など）を順に見直す。それでも変わらない場合は、修正内容が実際にGoogleへ再クロールされているかを、URL検査ツールでホームページのステータスを確認することで切り分けられる。表示が古いままなのか、修正自体が反映されていないのかを区別しないまま待ち続けると、原因の特定が遅れる。

05 明日、自分のサイトで確認できることチェックリスト

チェックリストの観点と、かかる時間の目安

ここまでの内容を、今日から手を動かせる作業に翻訳した。観点は、現状の確認（5項目）、構造化データの整備（5項目）、反映後の確認（3項目）の3つに分かれる。チェックの状態はブラウザ内にのみ保存され、サーバーには送信されない。

• ホームページのソースを開き、titleタグに含まれる文字列を書き出す
• 同じホームページのog:site_nameプロパティの値を書き出す
• WebSite構造化データが実装されているか、Rich Results Testで確認する
• WebSite構造化データが実装されている場合、nameプロパティの値を書き出し、上記2つと同じ表記か比較する
• 実際に検索エンジンでサイト名を検索し、現在どう表示されているかを確認する
• WebSite構造化データが未実装の場合、name・urlの2つの必須プロパティを含む形で新規に追加する
• 正式名称のほかに、略称や通称がある場合はalternateNameプロパティとして追加する
• 選んだ名前が、Googleの言う「一般的すぎる名前」に当てはまっていないか見直す
• 構造化データが、ホームページ自体に設置されているか（下層ページではないか）を確認する
• HTTPとHTTPS、wwwありとなしなど、重複するホームページが存在する場合、両方に同じ構造化データが入っているか確認する
• 構造化データを追加・修正したら、Rich Results Testでエラーが出ていないか確認する
• 修正から2週間程度を目安に、検索結果での表示が変わったかを再度確認する
• 変わらない場合、公式ページの「望ましいサイト名が選択されない場合」の確認項目を上から順に見直す

13項目の内訳は次のとおりである。最初の5項目は現状の確認、6番目から10番目までは構造化データの整備、11番目以降は反映後の確認に対応している。すべてに目を通す時間の目安は1サイトあたり20分程度である。すでにWebSite構造化データを実装済みの場合、6番目・7番目は読み飛ばしてよい。

06 代替・他の選択肢（表で）

サイト名の候補を示す4つの手段

サイト名の候補を示す方法は1つではない。以下は、それぞれの手段が「できること」と「できないこと・限界」を整理した表である。

4つの手段のうち、公式が最も重要と位置づけているのはWebSite構造化データである。当サイトの🔧 構造化データ自動作成ツールは、その土台を作る役には立つが、それだけで望んだ名前が採用されるわけではない点は変わらない。

表に入れなかった手がかり — 見出しやその他のテキスト

公式ページが挙げる情報源には、上の表の4つのほかにホームページの見出し（h1など）やその他のテキストも含まれている。これを表に入れなかったのは、「その他のテキスト」という範囲が具体的にどこまでを指すのか、公式ページに明確な定義が無いためである。見出しやテキストを個別に操作する手段として案内できるほどの具体性が無い以上、この記事では「補助的に参照されることがある」という位置づけにとどめている。ホームページのh1が、titleやサイト名の候補とかけ離れた文言になっていないかを確認しておく程度が、現時点で取れる現実的な対応になる。

07 当サイトの実例

3つの情報源が、実際にどう揃っているか

このテーマについて、当サイトのホームページで実際に確認できることがある。当サイトのホームページのソースを開くと、titleタグ・og:site_name・WebSite構造化データのnameプロパティの3つは、いずれも「WEBサイトサポート」という同じ文字列で揃っている。一方で、WebSite構造化データにはurlとnameは設定されているが、alternateName（代替名）は設定していない。公式ページが推奨事項として挙げている項目のうち、この部分はまだ対応できていないことになる。

この「3つの情報源を同じ表記に揃える」という考え方は、当サイトが以前に確認した「4層の整合性」（Google が求める 4 層整合性）と同じ発想である。あちらはsitemap・canonical・内部リンク・末尾スラッシュの一貫性を扱っていたが、サイト名についても複数の情報源をバラバラにしないという基本は変わらない。

alternateNameを、まだ設定していない理由

alternateNameを設定していない理由は、単純に、正式名称と別に広く使われている略称や通称が今のところ存在しないためである。公式ページは代替名の提供を推奨事項として挙げているが、存在しない略称を無理に作って登録することは推奨されていない。この項目は、実際に別名で呼ばれる機会が生まれた時点で追加すればよい任意項目として扱っている。すべての推奨事項を無理に埋めようとするより、実態に合った範囲だけを正確に書くほうが、公式が挙げる「アイデンティティを正確に反映する」という基準には近い。

08 このテーマの、これまで

「出力は在ったのに、誰も見ていなかった」回

og:typeやdatePublishedなど、出力そのものは存在していたのに実際には確認されていなかった項目を扱った回がある（出力は在った。だから誰も測らなかった）。02章で触れた「titleとサイト名は見た目が近いので混同しやすい」という論点は、この回で確認した構図と重なる。どちらの事例も、値そのものは既に出力されているのに、それが正しい値かどうかを確認する作業が抜け落ちていたという点で共通している。

「複数の層を揃える」ことを扱った回

sitemap・canonical・内部リンク・末尾スラッシュという4つの層を、curl数行で確認する方法を整理した回がある（Google が求める 4 層整合性）。07章で確認した「3つの情報源を揃える」という考え方は、この回の延長線上にある。技術的な設定を1つずつ個別に見ていくと問題無く見えても、複数の設定を並べて突き合わせて初めて、ずれに気づけることが多い。

「顔」を整えることを扱った回

faviconを、検索結果やAI引用に表示される「名乗り」として整理した回がある（faviconは「飾り」から「名乗り」になった）。サイト名もfaviconと同様に、検索結果でサイトの発信元を示す要素の1つである。faviconが視覚的な「顔」だとすれば、サイト名は文字による「名乗り」であり、どちらも運営者が一方的に決められるものではなく、検索エンジン側の仕組みを通して初めて成立する表示だという点で共通している。