Search Console プロパティ設計: Domain property 一本化
📌 記事の取り扱いについて（公開当時の内容を含みます — タップで詳細）
本記事は公開当時の体験・気づきをまとめたものです。現在のツール数・プラン数・対象年齢・記事数・仕様とは異なる場合があります。最新の内容は各ツールページをご確認ください。ツールや外部サービスの仕様・料金は変更されることがあるため、利用前には各公式情報も併せてご確認ください。記載に誤りを見つけられた場合はお問い合わせフォームよりご連絡いただけると助かります。
サブドメインを増やしながらサイトを運用していると、Googleの管理画面（自分のサイトが検索からどう見えているか確認するもの。Search Console と呼ばれているものです）の登録管理が、思ったより面倒になってきて困りました。最初はサブドメインごとに別々のプロパティ（登録の単位）を作っていたのですが、最終的に「ドメイン プロパティ」（Domain property）＝ドメイン丸ごとを1つにまとめる登録方式を中心にしたところ、運用がだいぶ楽になりました。先に結論を書くと、ドメインを自分で管理していて DNS 設定（ドメイン名についての案内情報を登録する設定。サーバーの住所を結びつけるのもここです）を触れるなら、最初からこの方式で登録しておけばよかったなあ、と振り返っています。
URL プレフィックスとドメイン プロパティの違い
Googleの管理画面でウェブサイトを登録する方法には、二種類あるらしいです。「URL プレフィックス プロパティ」と「ドメイン プロパティ」と呼ばれています（ほかに、SNSなどのアカウントを登録する方式もあるようですが、私は使っていません）。違いをざっくりまとめると、こんな感じでした。
URL プレフィックスのほうは、https://example.com/ のように、指定したURLの前方一致（その文字列から始まるURLをまとめる、という区切り方）で区切る登録方式です。同じサイトでも、http と https、www あり/なし、サブドメインごとに、必要ならそれぞれ別の登録として扱うことになります。所有確認（このサイトが自分のものだと証明する手続き）は、HTML ファイルを置く・HTML タグを貼る・条件を満たせば Google アナリティクスのコードを使う、といった手軽な方法が選べます。
ドメイン プロパティのほうは、example.com というドメイン配下をまとめて扱える登録方式です。http でも https でも、www あってもなくても、すべてのサブドメイン（hotel.example.com, sim.example.com など）も、すべてのパスも、まとめて一つの登録として扱ってくれます。ただしこちらは所有確認のやり方が DNS（ドメイン名についての案内情報を登録する設定）に限られていて、私の場合は確認用の印として TXT レコードを足しました。別の書き方（CNAME レコード）や、ドメインを借りている会社の画面から確認する方法もあるようです。いずれにしても URL プレフィックスより一手間かかりました。
ドメイン プロパティに統一して何が変わったか
この方式に一本化してから、まず数字の見通しがよくなって安心でした。「サイト全体で、検索からどう見られているか」を一画面で見られるようになり、サブドメインごとに登録を行き来する手間がなくなりました。データそのものも、別々に見ていた頃より広い範囲をまとめて見られているように感じます。
サブドメイン別に絞って見たいときは、管理画面の絞り込み機能の「ページ」で https://hotel.example.com/ のようにサブドメインまで含むURLを指定すれば、その範囲のレポートだけを見られます。登録を切り替えなくていいので、あちこち見比べるのがずいぶん楽になりました。
おまけのような効果ですが、新しいサブドメインを立ち上げたときに、Googleの管理画面で新しいプロパティを毎回追加しなくてよい、というのも助かりました。ドメインに新しいサブドメインを生やせば、クロール（Googleがページを見に来る巡回）やデータ反映が進むにつれて、ドメイン プロパティのレポートで一緒に見られるようになります。サブドメインを立ち上げるたびに、プロパティ追加・所有確認を毎回やり直す手間が減ったのは、地味ですが大きかったです。sitemap（Googleにページの一覧を伝えるファイル）は必要に応じてドメイン プロパティ側で送信するようにしています。
移行作業で気をつけたこと
古いほうの URL プレフィックスの登録を残したまま、ドメイン プロパティを追加することもできます。データの扱いが心配だったので、最初は両方を残して、しばらく並べて使ってみました。ドメイン側でも必要なデータが見られていると確認できてから、URL プレフィックス側を残すか整理するか考える、という慎重なやり方です。
ただ、レポート系（検索からの表示やクリックの数など）は登録ごとに別々に集計されているらしく、URL プレフィックス時代の履歴はドメイン プロパティのほうに引き継がれません（統合されません）。あとで過去の数字を見るかもしれないなら、古い登録はしばらく消さずに残しておくのが無難だと感じました。
sitemap も、ドメイン プロパティ側で各サブドメインの分を必要に応じて登録し直しました。古い登録で送信した sitemap は、新しいほうのレポートには表示されません。新しい側でも状態を確認したかったので、私はサブドメインごとに https://<sub>.example.com/sitemap.xml を一つずつ送信し直しました。これは少し面倒でした。
DNS 認証の落とし穴
ドメイン プロパティの所有確認は、ドメインの設定に、確認用の印（私の場合は TXT レコード）を足す形になります。この印はDNSの反映までに時間がかかることがあるので、設定してすぐには通らないこともある、と見込んでおくほうがよかったなと思っています。
ドメインの設定サービスによっては、印の書き方に癖があるらしく（引用符が要る・要らない、改行を入れてはいけない、など）、コピペで貼る前に、画面に出てくるサンプルを丁寧に見比べました。設定したあと、その印がちゃんと返ってくるかを確認してから、管理画面の「確認」ボタンを押すと、一発で通ってくれました。
逆に、所有確認に使った印を後から消してしまうと、確認済みの所有者としての権限を失って、その登録を見られなくなることがあるそうです（登録そのものが消えるわけではないようです）。Googleの管理画面のための印は、使い続けるあいだは消さずに残しておくのが基本でした。有効な確認用のレコードを最低でも一つは残しておくと安心です。
サブドメインごとの細かい運用
ドメイン プロパティにまとめても、サブドメインごとに細かく見たい場面はあります。たとえば、ホテル検索のサブドメインだけ平均の表示順位を追いたいとき。これも先ほどと同じ絞り込みで追えるようになりました。
新しいサブドメインを立ち上げた直後は、管理画面にデータが反映されるまで時間がかかることもあります。一本化したからといって、新しいサブドメインの分析がその日のうちにできるわけではない、という点だけは頭に置いています。
新しいサブドメインでは、巡回ルールを書く robots.txt と sitemap.xml が必要かどうかを確認するようにしています。あわせて、管理画面の「ページ インデックス登録」（検索への登録状況）のレポートを見て、対処が要る項目が出ていないか確かめるのを習慣にしました。
振り返り
最初からドメイン プロパティで登録しておけば、二つを並べて使ったり乗り換えたりする作業はそもそも要らなかったので、最初の選び方でだいぶ手間が変わるんだなあ、と感じました。ドメインを持っているなら、最初の所有確認のときに、確認用の印を入れる一手間を惜しまないほうが、あとあと楽になる気がします。
URL プレフィックスのほうは、「特定のパスの下だけ」を別に見たいときなどに、必要に応じて残しておけば十分でした。私のサイトでは、ドメイン プロパティで全体をながめて、絞り込みで個別のサブドメインを掘る、という形に落ち着いています。Googleの管理画面は、設定さえ済ませてしまえば、あとは登録を行き来する回数が減ったぶん、最初にかけた手間を上回って助けてくれるなあ、と感じています。
← 他の制作記を見る ｜ トップ ｜ お問い合わせ