検索結果のサイト名は設定ではなく希望として伝える

社名を変えた。サイトのロゴも差し替えた。ところが自分のサイト名でGoogle検索すると、検索結果の見出しの上にはまだ旧社名が出ている。あるいは、そもそも指定した覚えのない表記が並んでいる——この記事はそこで検索してきた方に向けたものです。

このとき最初に見つかるのは、たいてい「トップページにWebSite構造化データを書けば直る」という手順です。方向としては合っています。ただ、公式ドキュメントの「Google 検索のサイト名」を開いて記述を突き合わせると、そこに書かれているのは設定して上書きするという話ではありません。Googleが自動で生成し、サイト側は希望を示せる、という組み立てになっています。この差は、書いたのに変わらないときの受け止め方をまるごと変えます。

この記事では、自社サイトを自分で直せる担当者の方に向けて、公式の記述をそのまま引きながら、(1) 何が指定できて何ができないのか、(2) 自分のケースがそもそも指定の効く単位なのか、を切り分ける6ステップを、実際の構成に1回通してみせます。読み終わったときに、「書いたのに変わらない」を「そもそもこの単位では指定できない」「希望の並べ方が足りていない」「待ちの段階」のどれなのか自分で名指しできている状態を目指します。

公式が書いているのは「自動生成」と「希望の申告」

「Google 検索のサイト名」のページには、仕組みがこう要約されています。

Google generates site names in search results, automatically, but allows websites to indicate a preference. To do so, add WebSite structured data to the home page, including name

（Googleは検索結果のサイト名を自動的に生成しますが、サイト側が希望を示すことはできます。そのためには、ホームページに name を含む WebSite 構造化データを追加します。）

ここまでは、よく見かける手順の説明と一致します。読みどころは次の一文です。

While we can't manually change automatically selected site names, you can indicate alternatives for our automated system to consider if your primary preference isn't selected.

（自動的に選ばれたサイト名を手動で変更することはできませんが、第一希望が選ばれなかった場合に自動システムが検討する代替案を示すことはできます。）

つまり、構造化データに書く name は確定値ではなく第一希望です。そして、第一希望が選ばれないことがある前提で、代替案を並べる枠が用意されています。「書いたのに変わらない」は、書き方の失敗とは限らず、この仕組みの中では起こりうる結果として扱われている、と読めます。

もう1つ、名前の選び方について公式はこう書いています。

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

（サイト名を選ぶ——サイトのアイデンティティを正確に反映する、一意な名前を選びましょう。）

一意であること、そしてサイトの正体を正確に表していること。ここで求められているのは、狙いたい検索語を混ぜ込むことではなく、そのサイトが何であるかを名前として素直に示すことです。

指定が効く単位は、ドメインかサブドメインまで

「書いたのに変わらない」の相談で、記述の書式より先に効いてくるのが単位です。同じページに、こう明記されています。

Currently, Google Search only supports one site name per site, where a site is defined by the domain or subdomain. Google Search does not support site names at the subdirectory level. Note that subdomain names starting with www or m are generally considered as being equivalent.

（現在、Google検索は1サイトにつき1つのサイト名のみをサポートしており、ここでのサイトはドメインまたはサブドメインで定義されます。Google検索はサブディレクトリ単位のサイト名をサポートしていません。なお、www または m で始まるサブドメイン名は、一般に同等とみなされる点にご注意ください。）

この3文から、実務でよく引っかかる形が読み取れます。

• 1サイト＝1つのサイト名。ページごとやカテゴリごとに違うサイト名を出す、という発想は最初から範囲外です。
• 単位はドメインまたはサブドメイン。example.com と media.example.com は別々に扱われます。
• サブディレクトリ単位は非対応。example.com/media/ に本体とは別のメディア名を出す、という設定はサポートされていません。
• www と m は同等扱い。www.example.com に別名を、という切り分けは期待できません。

企業サイトの中にオウンドメディアを /media/ で持っている構成は珍しくありません。その担当者が「メディア名が検索結果に出ない」と悩んでいる場合、記述の直し方をいくら調べても解決しません。公式の記述の範囲では、そこは指定できる単位ではないからです。別の名前を出したいのであれば、単位そのものを変える（サブドメインに分けるなど）検討が先に来ます。サブドメインとサブディレクトリのどちらを選ぶかは、この一点だけで決められる話ではないので、サブドメインとサブディレクトリの選び方もあわせて考えてください。

自分のケースを仕分ける6ステップ

書式を直す前に、まず自分のケースが仕様の内側にあるかを確かめます。ブラウザとソース表示だけでできる順番にしてあります。

1. 検索結果に今どう出ているかを控える。自社サイト名で検索し、検索結果に表示されているサイト名の文字列をそのままメモします。「変わらない」の出発点を、記憶ではなく文字列で押さえます。
2. 出したい名前が、どのURLに対する名前かを書き出す。example.com 全体なのか、media.example.com なのか、example.com/media/ 配下なのか。ここで書き出したURLが、次の判定の入力になります。
3. その単位が指定できるかを判定する。ドメインまたはサブドメインなら対象。サブディレクトリなら対象外です。対象外だった時点で、書式の調整では解決しないと確定します。ここで止まれるかどうかが、無駄な作業を減らす分かれ目です。
4. 対象の単位のホームページを1つに特定する。構造化データを置く先はホームページです。https://example.com/ と https://www.example.com/ の両方が開ける状態なら、どちらが実体でどちらが転送されるのかを確認しておきます。
5. そのホームページのソースを開き、WebSite 構造化データの有無を見る。ブラウザでソースを表示し、application/ld+json と WebSite で探します。無ければ「まだ希望を伝えていない」状態、あれば name の値が、いま出したい名前と一致しているかを見ます。
6. name と alternateName の並びを確認する。第一希望が name に入っているか、認知されている略称などの代替案が用意されているかを見ます（並べ方は次の節）。

このうち、実際に手を動かして直すのは5と6だけです。1〜4は、5と6をやる価値があるかを判定するための工程になります。

6ステップを1回通してみる

架空の例で通します。文具メーカー「バーントトースト」がコーポレートサイト example.com を持ち、その中に example.com/media/ で読み物コーナーを運営している、という構成です。ブランド名の表記を「Burnt Toast」に統一したのに、検索結果には旧表記が出ている、という状況を想定します。

ステップ1——「Burnt Toast」で検索し、検索結果のサイト名が旧表記のままであることを文字列で控えます。

ステップ2——出したい名前が2つあることに気づきます。コーポレートサイト全体に対する「Burnt Toast」と、読み物コーナーに対する別のメディア名です。

ステップ3——ここで分岐します。前者は example.com というドメインなので対象。後者は example.com/media/ というサブディレクトリなので、公式の記述では対象外です。この時点で、メディア名の方は作業リストから外れます。外すのではなく「サブドメインに移すかどうかの検討課題」として別の欄に移す、という整理でもかまいません。実装の手を止める判断がここで確定するのが、この順番の効きどころです。

ステップ4——残ったコーポレートサイトについて、https://www.example.com/ が実体で、https://example.com/ はそこへ転送される構成だと確認します。構造化データを書く先は、転送先の実体側です。

ステップ5——ソースを開くと WebSite の記述が見当たりませんでした。つまり、まだ希望を一度も伝えていない状態でした。「変わらない」の原因が、記述の誤りではなく不在だった、というのはよくあるパターンです。

ステップ6——第一希望を「Burnt Toast」に置き、社内外で通っている略称も代替案として並べます。

5ステップ目までで「メディア名は対象外」「コーポレート側は未記述」という2つの結論が出ました。やることが増えたのではなく、片方が消えて片方が具体化したのが、この工程の成果です。

希望の並べ方——name と alternateName

公式ドキュメントには、代替案を優先順に並べ、最後にドメイン名を置いた例が載っています。抜粋にはその意図が添えられています。

and ending with the domain example.com as the final name preference:

（そして、最後の名前の希望としてドメイン example.com で終えます。）

例そのものは次の形です。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "Burnt Toast",
  "alternateName": ["BT", "B-T", "Burnt Toast Shop", "example.com"],
  "url": "https://www.example.com/"
}
</script>

読み取れる組み立ては次のとおりです。

alternateName を空にしたまま name だけ書いて「変わらない」と言っている状態は、公式の組み立てから見ると、第一希望が通らなかったときの受け皿を用意していない状態にあたります。代替案を示せる枠がある以上、埋めておく方が仕組みに沿います。

なお、構造化データ全般について、公式は次のように説明しています。

Google uses structured data to enhance search results with rich features. Implementing structured data can make your site eligible for these results

（Googleは構造化データを使って検索結果を豊かな機能で拡張します。構造化データを実装することで、サイトがそうした結果の対象になり得ます。）

「対象になり得る（eligible）」という書き方である点は押さえておきたいところです。書いたから必ずそう表示される、という約束の形にはなっていません。サイト名についても、手動で変更はできず希望を示せるだけ、という先ほどの記述と同じ温度感で読むのが自然です。

「変わらない」をどう判断するか

ここが一番はっきりさせにくいところなので、公式の記述で言い切れる部分と、そうでない部分を分けて書きます。

言い切れるのは、手動で変更する手段は用意されていないということです。したがって、「申請すれば直る窓口がどこかにあるはずだ」という前提で探し続けるのは、公式の記述と噛み合いません。

一方、書いてから検索結果に表れるまでの時間については、今回参照した抜粋の範囲に記述がありません。実務としては、書き換えた内容がGoogle側に取り込まれるまでには間があると考えて、しばらく置いてから見直すことになります。ただしどれくらいで反映されるかを数字で見積もることはできませんし、期間を置けば必ず希望どおりになる、というものでもありません。第一希望が選ばれない場合がある、と公式が明記している以上、待った結果として代替案の方が採用される、あるいは自動生成された別の名前のままになる、という着地も想定に入ります。

そのため、点検の観点は「いつ変わるか」ではなく、自分の側でやれることが残っているかに置くのが実務的です。

一番下の行に入ったときが、この作業の終点です。ここまで来たら、検索結果の文字列を定期的に見る以外にできることはありません。「まだ何かやれるはずだ」と記述を触り続ける方が、かえって整合性を崩します。

書き換える前後のチェックリスト

• 出したい名前の対象URLを書き出し、ドメイン／サブドメイン／サブディレクトリのどれかを判定した
• サブディレクトリだった場合は、記述の作業を止めて別の検討に移した
• 対象の単位のホームページを1つに特定した（転送元ではなく実体側）
• name に第一希望を入れた。検索語の詰め込みではなく、サイトの正体を表す一意な名前になっている
• alternateName に、実際に通っている呼び方を希望の強い順に並べた
• url にホームページのURLを書いた
• 記述に文法の誤りがないか、公式が案内している検証用のツールで確かめた
• 検索結果の現在の表示を文字列で控え、見直す日を決めた

検索結果での見え方は、サイト名だけで決まるものではありません。同じ枠の中で読まれる要素として、タイトルと説明文でクリック率を上げるや設定した説明文が検索結果に使われない理由、それにファビコンが検索結果に出ないときの確認手順も、同じ「自分では最終決定できないが、材料は渡せる」という構図で読むと通して理解しやすくなります。