Search Consoleの4プロパティ、結局どれを見る？ドメインと正規URLで迷わない整理法

Search Consoleの4プロパティをドメインプロパティと正規URLに整理する考え方を示したアイキャッチ画像 ブログ運営
本サイトはプロモーションが含まれています

Search Consoleを開くたびに、似たようなプロパティがいくつも並んでいて、地味に混乱していました。

たとえば、こんな感じです。

http://example.com/


Example Domain
example.com



Example Domain
www.example.com



Example Domain
www.example.com

http と https。wwwあり と wwwなし。合計4つです。

昔はこれが普通だと思っていましたし、むしろ丁寧に登録しているつもりでした。

でも実際にSearch Consoleを見ると、「で、結局どれを普段見ればいいの？」となるわけです。

Search Consoleに4つのプロパティが並び、どれを見ればいいか迷っている様子のイラスト

特に私のように、WordPressでサブディレクトリごとに複数サイトを運営していると、さらにややこしくなります。

そこで今回、Search Consoleのプロパティをどう整理して見るか、自分なりに決めました。

結論はこうです。

  • 全体はドメインプロパティで見る
  • 普段見るのは現在の正規URL
  • 必要なサブディレクトリやサブドメインだけ個別追加

この考え方が、一番迷いにくいと思います。

先に結論

Search Consoleのプロパティを全体把握と日常監視と個別追加に分けて整理した図

私なら、Search Consoleのプロパティをこう整理します。

役割見るプロパティ使い方
全体把握ドメインプロパティドメイン全体の検索状況を見る
日常監視現在の正規URLのURLプレフィックス普段の本番URLを見る
個別確認サブディレクトリやサブドメインのURLプレフィックス必要な範囲だけ細かく見る
調査用旧 http、旧 www など変なURLが残っていないか確認する
ステージング原則として検索に出さない監視より先にアクセス制限や noindex を考える

要するに、「全部をひとつにまとめれば終わり」ではなく、「全体を見る場所」と「普段見る場所」を分けるということです。

ドメインプロパティは便利ですが、範囲が広い分、日常監視には少し広すぎることがあります。なので私なら、

  1. ドメインプロパティで全体を見る
  2. 正規URLのURLプレフィックスで普段の本番URLを見る
  3. 必要なサブディレクトリだけ追加する
  4. 旧URLは常用せず調査用にとどめる

という形にします。

なお、Search Consoleのプロパティを整理しても、それだけでSEO評価が上がるわけではありません。これは順位改善の施策というより、検索状況を確認しやすくするための運用整理です。

URLプレフィックスとは、「指定したURLから始まる範囲だけを見るプロパティ」のことです。
たとえば https://example.com/ を登録すると、そのURLから始まるページが対象になります。
一方で、http://example.com/ や https://www.example.com/ は別扱いです。
だから昔は、http / https / wwwあり / wwwなし をそれぞれ登録していたわけです。

なぜ昔は4プロパティ登録していたのか

昔のSearch Consoleではhttpとhttpsとwwwの違いで4つ登録していたことを示すイラスト

昔の4プロパティ登録は、間違いではありません。

Search ConsoleのURLプレフィックスプロパティでは、指定したURLから始まる範囲だけが対象になります。つまり、次の4つはそれぞれ別の範囲として扱われます。

http://example.com/


Example Domain
example.com



Example Domain
www.example.com



Example Domain
www.example.com

人間から見ると同じサイトでも、Search Console上では別物なんですよね。だから昔は、次のような目的で4つ登録しておくのは自然な判断でした。

  • すべてのURLパターンを確認する
  • http から https への移行状況を見る
  • wwwあり / wwwなし の統一を確認する
  • リダイレクトや canonical の整合性を見る

特にSSL化や wwwの正規化をした時期には、4つある方が確認しやすい場面もありました。

「4つ登録していたのは間違いだったのか」というと、そうではないと思います。ただ、今もその4つを全部ふだん使いする必要があるかというと、それは別の話です。

今はドメインプロパティを軸にできる

ドメインプロパティがhttpやhttpsやサブドメインやサブディレクトリをまとめて把握できる図

今のSearch Consoleには、ドメインプロパティがあります。

example.com のように登録するタイプで、そのドメイン配下をまとめて確認できます。具体的には、

  • http / https
  • wwwあり / wwwなし
  • サブドメイン
  • サブディレクトリ

これらを一括で見られます。つまり、昔は分けて見ていたものを、ドメイン単位でまとめて把握できるわけです。

ただし、範囲が広いのがネックです。サイト構成によっては情報が広がりすぎることもあるので、私の考えとしては、

  • ドメインプロパティは全体把握用
  • 日常的な確認は、今使っている正規URLのURLプレフィックス

この役割分けが一番分かりやすいです。

URLプレフィックスとドメインプロパティの違い

種類見られる範囲向いている使い方
URLプレフィックスプロパティ指定したURLから始まる範囲本番URL、サブディレクトリ、サブドメインなどを個別に見る
ドメインプロパティドメイン配下をまとめて見るサイト全体を俯瞰する

たとえば、URLプレフィックスで https://example.com/ を登録した場合、そこから始まるURLが対象になります。

一方、ドメインプロパティで example.com を登録すると、http・https・wwwあり・なし・サブドメイン・サブディレクトリまでまとめて見られます。

整理するとこうなります。

  • 全体像を見るなら　ドメインプロパティ
  • 現在の本番URLを日常的に見るなら　URLプレフィックス
  • サブディレクトリ単位で見たいなら　その範囲のURLプレフィックス

単一サイトなら、基本はこの2つで十分

1つのWordPressサイトだけを運営している場合、私なら基本的にこの2つを見ます。

  • example.com のドメインプロパティ
  • https://example.com/ のURLプレフィックスプロパティ

ドメインプロパティでサイト全体を俯瞰し、URLプレフィックスで普段の本番URLを確認する形です。

旧 http や旧 www は、毎日見る必要はほぼありません。移行確認や異常調査のときに見る程度で十分です。

サブディレクトリで複数WordPressを運営している場合

1つのドメイン配下に複数のサブディレクトリサイトがある構成を示した図

私の場合、メインドメインにサブディレクトリを作り、それぞれにWordPressを入れて複数サイトを運営しています。イメージとしてはこういう構成です。

example.com/
example.com/site-a/
example.com/site-b/
example.com/site-c/

この場合、ドメインプロパティで全体は見られます。ただ、サブディレクトリごとに実質別サイトとして運営しているなら、ドメインプロパティだけでは広すぎることがあります。

検索パフォーマンスを見るだけなら、ドメインプロパティや正規URLのURLプレフィックスでページURLを絞り込めば足りる場合もあります。ただ毎回フィルタをかけるのは手間ですし、サブディレクトリごとにサイトマップやインデックス状況を分けて見たいこともあります。

そういう場合は、サブディレクトリ単位のURLプレフィックスプロパティを追加すると便利です。

https://example.com/site-a/


Example Domain
example.com

まとめると、

  • パフォーマンスだけ確認するなら　フィルタで対応できることが多い
  • 継続監視や管理を分けたいなら　専用プロパティが便利

サブドメインやステージング環境がある場合

本番サブドメインとステージング環境を分けて管理する考え方を示した図
www.example.com
shop.example.com
media.example.com
staging.example.com

このような構成でも、考え方は同じです。ドメインプロパティで全体把握はできますが、本番で運営しているサブドメインがあるなら、それぞれURLプレフィックスを作っておくと管理しやすくなります。

ステージング環境は少し別の話です。「Search Consoleで見分けられればいい」という話ではなく、そもそも検索結果に出ないようにしておくべきものです。

もし staging.example.com が外部公開されていてGoogleに見つかる状態なら、ドメインプロパティの中に入ってくる可能性があります。それ自体は発見には役立ちますが、対策としては不十分です。

ステージング環境では、

  • Basic認証などでアクセス制限する
  • 必要に応じて noindex を設定する
  • 本番サイトと混ざらないようにする

このあたりを優先すべきです。外部に見せたくないステージングなら、noindexだけに頼るより、アクセス制限を優先した方が安心です。

ステージング環境とは、本番公開前にWordPressの更新やデザイン変更、プラグインの動作確認をするためのテスト用サイトです。
たとえば staging.example.com のようなサブドメインで作ることがあります。
ただし、ステージング環境は本来、検索結果に出すものではありません。Search Consoleで監視する前に、Basic認証などでアクセス制限し、必要に応じて noindex を設定しておく方が安全です。

旧httpや旧wwwは削除すべきか

旧httpや旧wwwのプロパティを調査用として残す考え方を表した図

ドメインプロパティを作ったあと、「旧 http や旧 www のプロパティは消していいのか」と迷うことがあります。

私の考えでは、すぐ削除しなくていいですが、常用もしません。調査用に残しておくのが一番現実的です。

たとえば次のような確認に使えます。

  • http URLがまだ拾われていないか
  • wwwありURLが混ざっていないか
  • 移行直後にリダイレクトが効いているか
  • 想定外のホストがインデックスされていないか

一方で、https統一・wwwの正規化・移行確認がすべて安定していて、プロパティが多すぎて迷っているなら、普段使いからは外していいと思います。

判断の基準は「残すか消すか」ではなく、「常用か、補助か、調査用か」で考えると整理しやすいです。

ドメインプロパティの確認はDNSのみ

ドメインプロパティを作るときは、所有権の確認方法に注意が必要です。

URLプレフィックスプロパティでは、HTMLファイル・HTMLタグ・Googleアナリティクス・Googleタグマネージャー・DNSなど複数の方法が使えます。一方、ドメインプロパティはDNS確認のみです。

設定場所はWordPressではありません。たとえば、

  • DNS管理をCloudflareでしているなら → Cloudflare側で設定
  • ConoHa WINGでDNS管理しているなら → ConoHa側で設定

Googleから指定されたTXTレコードを、DNSを管理しているサービスに追加するイメージです。Cocoonの設定画面に貼る話とは別です。

DNS権限がない場合は、先に正規URLのURLプレフィックスで運用を始めて、後からドメインプロパティを追加するのも現実的な方法です。

サイトマップは管理対象の範囲と合わせると分かりやすい

サイトマップは、管理対象の範囲に合うプロパティで確認すると整理しやすいです。

  • ドメイン全体を見るなら → ドメインプロパティ
  • /site-a/ 配下だけを見たいなら → https://example.com/site-a/ のURLプレフィックス

これが絶対のルールではありませんが、プロパティの範囲とサイトマップの中身がずれていると、あとで管理しにくくなります。

WordPressでは wp-sitemap.xml が標準で使われる場合がありますが、SEOプラグインを使っていると別のURLになっていることもあります。サイトマップを確認するときは、「このサイトマップはどの範囲のページを送っているのか」を意識しておくと良いです。

新しく追加したプロパティは、すぐ数字がそろうとは限らない

Search Consoleのレポートはリアルタイムではありません。プロパティを追加した直後に数字がきれいにそろうとは限らないので、追加直後に数値が少なかったり他のプロパティと見え方が違っても、すぐ異常と決めつけなくて大丈夫です。

検索パフォーマンスやインデックス状況は、少し日を置いてから確認した方が落ち着いて判断できます。

プロパティ整理はSEO評価を直接上げる施策ではない

ここは誤解しないようにしたいところです。

Search Consoleのプロパティを整理しただけで、検索順位が上がるわけではありません。SEOに直接関係するのは、たとえばこういう部分です。

  • 正規URLの統一
  • リダイレクト設定
  • canonical の整合性
  • XMLサイトマップの整備
  • インデックス管理
  • コンテンツ改善

Search Consoleの整理は、これらを確認しやすくするための土台です。「順位を上げる作業」というより、「問題に気づきやすくする作業」だと思っています。整理しておくと、Search Consoleを開くときのストレスがかなり減ります。

迷ったときの最終回答

「結局どう残せばいいのか」だけ知りたいなら、私ならこうします。

単一サイトの場合

常用するもの：

  • ドメインプロパティ
  • 現在の正規URLのURLプレフィックス

調査用：

  • 旧 http
  • 旧 www

サブディレクトリで複数運営している場合

常用するもの：

  • ドメインプロパティ
  • 現在の正規URL全体のURLプレフィックス

必要に応じて追加するもの：

  • 継続監視したいディレクトリのURLプレフィックス

調査用：

  • 旧 http
  • 旧 www

サブドメインがある場合

常用するもの：

  • ドメインプロパティ
  • 各本番サブドメインのURLプレフィックス

注意するもの：

  • ステージング環境は、監視より先に検索に出ない状態を作る

まとめ

Search Consoleのプロパティ整理を全体把握と日常監視と個別追加でまとめた図

昔のhttp / https × wwwあり / なし の4プロパティ運用は、当時としては自然な判断でした。URLプレフィックスプロパティでは、それぞれ対象範囲が異なるからです。

ただ今はドメインプロパティがあるので、昔の4分割をそのまま常用する必要はほぼありません。私なら今はこう整理します。

  • 全体把握　ドメインプロパティ
  • 日常監視　現在の正規URLのURLプレフィックス
  • サブディレクトリ・サブドメイン　必要なものだけ追加
  • 旧 http・旧 www　調査用
  • ステージング　監視より先に検索に出ない状態を作る
  • プロパティ整理そのものはSEO評価を直接上げる施策ではない

「全部を1つにまとめる」ではなく、「全体を見る場所と、普段見る場所を分ける」。

この形にすると、Search Consoleを開くたびに「結局どれを見ればいいのか」と迷う場面がかなり減ります。

参考情報

Google Search Console ヘルプ「プロパティを Search Console に追加する」
https://support.google.com/webmasters/answer/34592

Google Search Console ヘルプ「所有権を確認する」
https://support.google.com/webmasters/answer/9008080

Google Search Console ヘルプ「サイトマップ レポート」
https://support.google.com/webmasters/answer/7451001

Google Search Console ヘルプ「検索パフォーマンス レポート」
https://support.google.com/webmasters/answer/7576553

Google Search Central Blog「Announcing domain-wide data in Search Console」
https://developers.google.com/search/blog/2019/02/announcing-domain-wide-data-in-search

スポンサーリンク

コメント