サーチコンソールのhttpとhttps、データが無いのはどちら？見分ける3つの確認

サーチコンソールに http と https のプロパティが2つあって、片方のデータが0か、ほとんど無いなら、それは壊れているのではなく、Google が検索結果に出しているURLとは違うほうを開いている可能性が高いです。 プロパティ一覧に「http://」と「https://」が並び、どちらが本物なのか、データが2つに割れてしまったのか分からなくなった人に向けて書いています。 読み終わるころには、自分のブログでどちらを見ればいいかを3つの確認で決められ、次から迷わないようにまとめる方法も選べます。

データが入っているほうのプロパティが分かったら、その数字から「どの記事を直すか」を決める作業は機械に任せる手もあります。それは記事の最後に書きます。

URL プレフィックスでは、http と https は別のサイトとして数えられる

まず、2つのプロパティが何を集計しているのかを公式ヘルプで確かめます。プロパティを Search Console に追加するのヘルプは、ウェブサイト プロパティの種類の表で、URL プレフィックスをこう説明しています。

指定したプレフィックスで始まる URL のみが含まれます（http や https などのプロトコルも対象）。

同じ表の例が分かりやすいです。プロパティが http://example.com/ のとき、http://example.com/dresses/1234 は含まれ、https://example.com/dresses/1234 には「https が一致しません」、http://www.example.com/dresses/1234 には「www. が一致しません」と書かれています。s が1文字違うだけで、同じ記事でも別のプロパティの集計になります。www の有無も同じです。

ヘルプの入力のヒントには、こうもあります。

サイトが複数のプロトコル（http と https）に対応している場合は、プロトコルごとに個別のプロパティを追加する必要があります。

英語版も "you must add a separate property for each protocol" で、言い方の強さは同じです。日本語版のページには、AI翻訳を含む場合があるという注記が付いています。 つまり URL プレフィックスで http 版と https 版の2つを作ると、それぞれが自分のプロトコルのURLだけを数えます。2つを開いて数字が違うのは、この仕様どおりの動きです。

なぜ片方だけにデータが入るのか: 数字は Google が選んだ正規URLに付く

別々に数えるだけなら、両方に半分ずつ入りそうなものです。そうならないのは、検索パフォーマンスの数字がどのURLに付くかが決まっているからです。表示回数、掲載順位、クリック数とはの「データが割り当てられる URL」の節には、こうあります。

ページの全バリエーションのクリック数、表示回数、掲載順位のデータは、Google が各ページ向けに選択する正規 URL に割り当てられます（場合によっては、正規 URL ではなく実際の URL に割り当てられることもあります）。

そして http と https のどちらが正規URLに選ばれやすいかは、Search Central の重複した URL を統合する(最終更新日 2026-07-14 UTC)に、「正規 URL として HTTP より HTTPS を優先する」という見出しで書かれています。

Google では、HTTPS ページを同等の HTTP ページよりも優先的に正規 URL として選択します。ただし、以下のようにシグナルが競合する場合や問題がある場合は例外となります。

原文が例外として挙げている例は4つです。HTTPS ページに無効な SSL 証明書が含まれている、安全でない依存関係(画像以外)が含まれている、HTTPS ページからユーザーを HTTP ページに(または HTTP ページ経由で)リダイレクトしている、HTTPS ページに HTTP ページへの rel="canonical" が含まれている。同じ節は、HTTPS を選ばせたいときの措置として、HTTP ページから HTTPS ページへのリダイレクト、HTTP ページから HTTPS ページへの rel="canonical"、HSTS の実装の3つを挙げています。サイトマップや hreflang に HTTPS 版ではなく HTTP 版の URL を載せないことも、同じ節に注意点として並んでいます。

2つをつなげると、仕組みは1本の線になります。http を https に転送しているブログでは、上の例外に当たらない限り、正規URLは https 側になり、数字は https のプロパティに入ります。http のプロパティには数える相手がほとんど残らないので、0か、それに近い数字になります。ヘルプの但し書きのとおり実際のURLに割り当てられる場合もあるので、「必ず0」とまでは言えません。

このブログでも確かめました。2026年10月7日に http://rewrite-radar.com/ へリクエストを送ると、返ってきたのは「301 Moved Permanently」と、転送先の「https://rewrite-radar.com/」でした。この状態なら、見るのは https のほうです。

どちらを見ればいいかを、3つの確認で決める

プロパティ名だけ見比べても答えは出ません。次の3つを上から順に確かめると、見るべきほうが決まります。

1. ブラウザのアドレス欄に http:// で打って、どこへ飛ぶかを見る

自分のブログのトップを http:// から打ち込んで開き、表示されたあとのアドレス欄を見ます。https:// に変わっていれば、http から https へ転送されています。www の有無は、転送せずにどちらでも表示されるサイトもあるので、ここで見えたほうが正しいとは限りません。www は手順3の「Google が選択した正規 URL」で確かめます。

2. 両方のプロパティで、同じ期間の表示回数を並べる

2つのプロパティそれぞれで検索パフォーマンスを開き、期間を同じにして表示回数を見比べます。表示回数がまとまって入っているほうが、Google が検索結果に出しているURLのプロパティです。クリック数は少ないブログだと0の日が多いので、判断には表示回数を使うほうが確かです。

3. データがあるほうで URL 検査をし、「Google が選択した正規 URL」を見る

最後に、データがあるほうのプロパティで、よく読まれている記事のURLをURL 検査ツールにかけます。ヘルプによると、インデックスに登録されたURLは「Google が選択した正規 URL」の値で確かめられます。正規のバージョンが分かるのはインデックス登録済みのデータからだけで、ライブテストでは分からないとも書かれているので、ライブテストではなく検査結果のほうを見てください。 ここが https で始まっていれば、手順1・2と合わせて https のプロパティを見ればいいと決まります。正規URLが自分の考えていたURLと違っていたときの読み方は(自分で canonical を指定している場合)「ユーザーがマークしたページとは異なるページが正規ページとして選択されました」の対処に分けて書いています。

3つの結果の組み合わせで読む

登録したばかりで数日たってもデータが出ないときの原因は、プロパティ追加のヘルプが「https ではなく http を指定した」例を挙げて説明しています。その読み方と反映の遅れについては、サーチコンソールの登録方法は？ブログサービスで決まる種類と確認方法のよくある質問にまとめています。

ここまでで、見るべきプロパティは決まります。あとはそのプロパティの数字で記事を直していくだけです。どの記事から直すかを選ぶところは、自動でやる道具もあります。詳しくは記事の最後に書きます。

次から迷わないなら、ドメインプロパティで1つにまとめる

http と https、www の有無を毎回気にしたくないなら、プロパティの種類そのものを変える方法があります。プロパティ追加のヘルプは、ドメイン プロパティをこう説明しています。

ドメイン プロパティを指定すると、そのドメインとすべてのサブドメインおよびプロトコル（http / https）からデータが取得されます。

www ありとなしも自動で両方含まれます。ドメインプロパティなら、http と https の取り違えはそもそも起きません。まとめたうえで、プロトコルごとの数字を見たいときは、同じヘルプが「特定のプロトコルやサブドメインのデータを確認するには、検索パフォーマンス レポートにページフィルタを追加します。」と案内しています(原文の「ページフィルタ」はリンクです)。

ただし、ドメインプロパティは誰でも作れるわけではありません。Blogger のような Google のサービス上のサイトを除き、所有権の確認がDNSレコードに限られるので、はてなブログの「〇〇.hatenablog.com」のようにサービスのドメインの下で書いている人は選べません。自分がどちらを選べるかはサーチコンソールの登録方法は？に、DNSでの確認で詰まったときの考え方はサーチコンソールの所有権の確認ができないのはなぜ？に書いています。URL プレフィックスのまま使い続ける場合は、手順3で確かめた正規URLと同じアドレスで作ったプロパティを使えば十分です。

データが無いほうのプロパティは、消してもいいのか

見るべきほうが決まると、空のプロパティを消したくなります。空のほうを残しておいても困ることはなく、整理したいなら消しても構いません。ただし、途中で http から https に切り替えたブログでは、http のプロパティに切り替える前の時期の数字が残っていることがあります(下のよくある質問)。消す前に、その時期の数字が要らないかを確かめてください。削除したときに他のユーザーやデータがどうなるか、確認用のタグやファイルをどうするかはサーチコンソールのプロパティ削除、他の人とデータはどうなる？で公式ヘルプを確かめています。消す前にそちらを一度読んでください。

よくある質問

http から https に切り替えたら、https のプロパティに以前の数字がありません

切り替える前の時期は http のURLが正規だったので、その時期の数字は http のプロパティ側にあると考えられます。数字は原則として正規URLに割り当てられるので、切り替えの前後で、数字が入るプロパティも移ると読めます。なお、https のプロパティを後から作った場合に、作る前の期間のデータが見られるかどうかは、確かめたプロパティ追加のヘルプには書かれていませんでした。すでにドメインプロパティを持っているなら、切り替えの前後をそちらでまとめて見られます。これから作る場合に、作る前の期間まで見られるかどうかは、同じく書かれていませんでした。 また、http から https への変更は、サイト移転で使うアドレス変更ツールの対象外です(サイト移転でサーチコンソールは何をする？)。

http と https のプロパティの数字を足せば、サイト全体の数字になりますか

足し算で全体を出すのは勧めません。この記事で確かめた4ページ(プロパティ追加のヘルプ、重複した URL を統合する、表示回数・掲載順位・クリック数とは、URL 検査ツール)のどれにも、URL プレフィックスの2つのプロパティを足し合わせてよいとは書かれていませんでした。全体を見たいなら、http と https をまとめて集計するドメインプロパティを使ってください。

www ありとなしも、同じように別のプロパティになりますか

なります。プロパティ追加のヘルプの例では、http://example.com/ のプロパティに対して http://www.example.com/dresses/1234 が「www. が一致しません」とされています。見分け方も同じで、手順2の表示回数と手順3の「Google が選択した正規 URL」で決めます。

サイトが http のままです。https に変えないとサーチコンソールは使えませんか

使えます。URL プレフィックスなら http のプロパティを作れば、http のURLの数字がそこに入ります。https でも配信を始めると、同等の HTTP ページより HTTPS ページが優先して正規に選ばれるので(例外あり)、切り替えたあとは https 側のプロパティを見ることになります。切り替えのときにリダイレクトと canonical をどう扱うかはcanonicalタグの使い方、重複コンテンツと、指定が効かない理由に書いています。

まとめ

• URL プレフィックスのプロパティは、指定したプレフィックスで始まるURLだけを集計する(プロトコルも対象)。http と https、www の有無が違えば別のプロパティ
• 検索パフォーマンスの数字は原則として Google が選んだ正規URLに割り当てられ(実際のURLに割り当てられる場合もある)、Google は同等の HTTP ページより HTTPS ページを優先して正規に選ぶ(公式は例外として、無効な SSL 証明書など4つの例を挙げている)
• だから http を https に転送しているブログでは、データは https のプロパティに入り、http のほうは0か、ほとんど入らない。空のほうは壊れているのではない
• 見るべきほうは、転送先のアドレス・同じ期間の表示回数・URL 検査の「Google が選択した正規 URL」の3つで決める
• 次から迷わないなら、http と https をまとめて集計するドメインプロパティが使える。ただし Google のサービス上のサイトを除き、DNSレコードでの確認が必要

http と https で数字が割れて見えるのは、URL プレフィックスが文字どおりに数え、Google が正規URLを1つに決めているからです。転送の向きと表示回数を確かめれば、どちらのプロパティを開けばいいかは画面の中で決まります。

ここから先は、私が作ったツールの話です。

見るべきプロパティが決まったら、次は「その数字で、どの記事から直すか」です。そこを自動でやるツールを作りました。データが入っているほうのプロパティから検索パフォーマンスのエクスポートを落とし、ZIPのまま置くだけで、4.0〜20.5位のページを、表示回数100回以上は通常判定、30〜99回は参考判定、30回未満は本文中心の監査に分け、この順に、同じ区分の中ではCTR機会差の多い順に並べて出します。 判定と候補3記事のCTR機会差の確認、そのうち1記事分の診断カードまでは無料です。有料は2,980円(税込)の買い切りで、無料の1件を除いた3記事分の診断カードが対象です。3記事分が揃うとき(判定に出た候補が4件以上のとき)だけご案内します。生成の利用期限は購入から7日間で、月額課金や自動更新はありません。ログインも不要です。 CSVファイルそのものはブラウザの外に出ませんが、診断カードを出すときは選んだ1ページぶんの数値(URL・キーワード・順位・表示回数・CTR)を、タイトル取得を押したときは最大10件のURLを送ります。

⚠️ このツールは、どちらのプロパティを見るべきかは判定しません。エクスポートの「上位のページ」の列をそのまま読むので、データがほとんど無いほうのプロパティから落とすと、候補が0件になることがあります。掲載順位4.0〜20.5位に入るページが無いブログでも同じです。