SSL化済みなのにHTTPSの警告が出るときの点検手順

証明書は入れた。ブラウザにも鍵のマークが出ている。それなのに検索側からは、まだHTTPSが使われていないと言われる。

このとき手を入れる先は、たいてい証明書ではありません。Googleが「このページの代表はどの住所か」を決めるときに使っている材料が、まだhttp側を向いたまま残っている。疑うならそちらが先です。

しかも材料は数えられます。感覚で設定を巻き戻す必要はありません。

「安全ではない」ではなく「代表が違う」と読む

Googleは、同じ内容を持つ複数のURLから代表を1つ選びます。これを正規化と呼び、選ばれたURLが正規URL（そのページの本物の住所として扱われるURL）になります。

公式ドキュメントは、重複したページが生まれる原因として、地域、端末、プロトコルの違い、サイトの機能、そして事故を挙げています。httpとhttpsの併存は、このうちのプロトコルの違いにあたります。つまり、SSL化を済ませた直後のサイトは、公式の説明どおりに「重複が生まれやすい状態」を自分で作ったことになります。

そして選ばれた正規ページは、内容と品質を評価するときの主な材料として使われます。検索結果が指すのも通常は正規ページのほうです（重複のどれかが検索ユーザーにとって明らかに適している場合を除きます）。

ここが効いてきます。代表としてhttp側が選ばれたままなら、証明書が正しく入っていることと、検索側から見た住所がhttpsであることは、別の話として残り続けるわけです。

代表を選ぶときに名前が挙がる材料

同じドキュメントには、選択に影響するものが具体的に並んでいます。HTTP/HTTPSの別、リダイレクト（転送）、サイトマップ、そしてrel="canonical"の記述です。あわせて、選ばれる結果がサイト側の希望と異なることもある、とも書かれています。

希望どおりにならないことがある。この一文は、点検の性格を決めます。「https側を正しいと宣言したか」ではなく、「http側を指す記述がどこかに残っていないか」を数える作業になるからです。

名前が挙がっているものは、いずれも自分のサイトで開いて確かめられます。ならば1つずつ潰せます。

表の上3行は、公式が名前を挙げている転送・rel="canonical"・サイトマップを、自分のサイトで開いて確かめられる場所に置き換えたものです。4行目の内部リンクと読み込み先は、正規URLの選択材料として名前が挙がっているものではありません。サイト移転の準備として内部リンクの更新が挙げられているため、点検の対象に加えています。1行目の転送は、Search Consoleヘルプが「恒久的な移動としてHTTPS版が正規であることを検索エンジンとブラウザに示し、ユーザーをhttpからhttps版へ転送する」と説明している部分にあたります。2行目と3行目は正規化の説明に出てくるrel="canonical"とサイトマップ。4行目は次の手順で扱います。

点検の6ステップ

上から順にやると、途中で原因が確定して残りが不要になることがあります。だから順番に意味があります。

1. 代表にしたいURLを1本決める。サイト全体ではなく、まず1ページです。流入の多い記事や、警告として名前が挙がったURLを選びます。
2. http://側を実際にたたく。ブラウザではなく、コマンドで応答だけを見るほうが確実です。curl -I http://example.com/page/ のように送り、返ってきたステータス行と転送先を控えます。200が返ってきたら、その時点で原因の1つは確定です。
3. https://側のソースで正規URL指定を確認する。ページを開いてソースを表示し、canonicalという文字列を検索します。書かれている住所がhttpなら、宣言と実体が食い違っています。
4. サイトマップの中身を開く。送信しているファイルを直接開き、http://という文字列が1件でも含まれていないかを見ます。生成プラグインの設定が古いままだと、ここだけ取り残されがちです。
5. 本文と読み込み先をhttps側にそろえる。記事中のリンク、画像、読み込んでいるスクリプトの参照先を確認します。自分のサイト内を指すリンクにhttpが残っていれば、それも「http側を指す記述」です。
6. 対応表を作って残りのページに広げる。1ページで原因が分かったら、同じ生成元から作られているページはすべて同じ状態のはずです。URLの対応表にして一括で直します。

6番目は思いつきではありません。httpからhttpsへのURL変更は、公式ドキュメントが「URLの変更を伴うサイト移転」の例として名前を挙げているものです。そこで準備として挙げられているのが、旧URLと新URLの対応表を作ること、内部リンクを更新すること、新しいサイトマップを作ること、そして旧から新へのサーバー側の転送（301／308）を実装することでした。手順の2・4・5・6は、この4項目とそのまま重なります。

実際に1本通すとこうなる

コラム記事を1本選んだとします。仮に/column/price/とします。

手順2でhttp://側をたたくと、301が返ってきました。ここまでは問題ありません。ところが転送先を見ると、記事ではなくトップページのhttps://でした。1ページ単位で見れば、代表になるべき記事の住所は、httpからたどると消えてしまっています。

手順3に進みます。https側の記事を開くと、正規URL指定はhttpsの記事URLを正しく指していました。宣言は合っている。しかし前の段で見たとおり、転送のほうが別の住所を指しています。

手順4でサイトマップを開くと、URLはすべてhttpsでした。ここも問題なし。

手順5で本文を見ると、関連記事へのリンク3本のうち1本がhttp://のままでした。過去に手書きで貼ったリンクです。

ここまでで、見た材料のうち2つがhttp側または別の住所を向いていました。直す対象は、転送のルール（トップ集約をやめて1対1にする）と、本文の古いリンク1本です。証明書は最初から一度も触っていません。

手順6に進むと、同じ転送ルールが全ページに効いていることが分かりました。つまりこれは1ページの事故ではなく、設定1か所の問題です。対応表を作る価値があるのはこの場合です。

つまずきやすいところ

外部から読み込んでいるものが残る。 Search Consoleヘルプは、第三者から配信されるリソース（CDNやjquery.comなど）について選択肢を挙げています。プロトコル相対URLを使うか、相手がHTTPSを提供していないなら提供を依頼する（jquery.comを含め、多くはすでに提供済みだとされています）。あるいは、HTTPとHTTPSの両方を提供する自分の管理下のサーバーから配信する方法です。自分のサイトの記述をすべて直しても、読み込み先が古いままなら作業は終わりません。

HSTSを先に入れてしまう。 同じヘルプには、最終的にはHTTPリクエストをHTTPSへ転送してHSTS（常に暗号化した接続を使うようブラウザに覚えさせる仕組み）を使うべきだが、それは移行プロセスの後の段階で行う必要がある、と書かれています。順番が決まっているということです。転送とhttps側の記述が固まる前に入れると、切り分けの手段を自分で減らすことになりかねません。

HTTPSにすれば順位が上がると期待する。 Googleは2014年8月に、HTTPSをランキングシグナルとして使い始めたと公表しています。ただし同じ発表で、現時点ではクエリの1%未満に影響する軽微な要素だとされていました。Search Consoleヘルプの側も、HTTPSを検索品質の肯定的な指標として使うと書くにとどまります。ですから、警告を解消しても順位の動きは目に見えないことがあります。これは失敗ではありません。

一時的な転送で様子を見る。 恒久のつもりで設定したものが、実は一時的な転送になっていることもあります。手順2で控えたステータス行を、そのまま見返してください。どちらを選ぶかで迷ったら、301と302の使い分けを先に読むほうが早いです。

直したあとに確認すること

• http://側をたたいたとき、対応するhttpsの同じページへ渡っているか（トップページへまとめて送っていないか）
• https側のソースの正規URL指定が、httpsの自分自身を指しているか
• サイトマップにhttp://が1件も残っていないか
• 本文リンクと画像・スクリプトの読み込み先にhttpが残っていないか
• 直した範囲が1ページだけで終わっていないか（同じ生成元のページも直したか）

材料をひととおりhttps側にそろえても、代表として選ばれる結果がサイト側の希望と一致するとは限りません。公式の説明が「異なることもある」と断っているとおりです。それでも、材料を数えて片付けたあとなら、残った差は自分の設定以外の要因として切り分けられます。

正規化そのものの考え方は重複コンテンツとcanonicalの整理に、URLの構造ごと変える移転の進め方はサイトリニューアルでURLを変えるときのリダイレクト設計にまとめています。