Webサイト利用者やGoogleを適切にHTTPSに誘導する方法

常時SSL Lab.編集部 更新日 公開日 Google,HTTPS,SEO,アクセス解析,コード編集,記述方法,転送,

［目次］

Webサイトを常時SSL化して公開しても、一般的な利用者はそのことを知りません。
Webブラウザのブックマークに登録されたURLも、おそらく「http://」のままになっていることでしょう。

また、Googleのような検索サイトも「http://」のURLをインデックスしたままです。

利用者やGoogleがWebサイトにアクセスしたときに、「ページが見つかりません」のような状態になっていると、閉鎖されたと勘違いしてしまうかもしれません。

そんなことが起きないように、今回は利用者やGoogleを適切にHTTPSに誘導する方法をご紹介します。

作業の進め方

今回紹介する作業は、検索ロボットによるインデックスやサーバーの挙動などに影響する可能性があります。

テストサーバーでのテストも必要ですが、自信がなければHTTPとHTTPSを併存させて常時SSL化の作業を進めるのもひとつの方法です。

後述するcanonicalによるGoogleのインデックス状況の変化や、301転送の動作の動作が問題ないことを確認した上で、HTTPの方のデータを削除してHTTPSに一本化するなど、慎重に作業を行いましょう。

また、作業の際は念のため、データのバックアップは必ず取っておきましょう。

Googleに正しくインデックスさせるための作業

canonicalタグの変更

SEOの内部施策で、URLを正規化する「canonicalタグ」を使用している場合は、常時SSL化の際に記述を変更する必要があります。

canonicalタグは、語弊を恐れずに端的に言うと、どのページ(URL)をインデックス(登録)して欲しいかを検索エンジン(Google)に伝えるものです。

常時SSL化前からcanonicalタグのを導入していた場合、常時SSL化の作業の際に「https://～」のURLに変更しなければ、いくら常時SSL化しても検索エンジンはHTTPSのURLをインデックスしてくれません。

後述する301転送(リダイレクト)やHSTSを設定しても検索エンジン上は、HTTPが表示され続けてしまいますので、この記述を書き換える必要があります。

※ canonicalタグが実際に影響するのは、次回に検索ロボットが巡回したタイミングになります。

Webサイト単位の「robots.txt」の設定

Webサイトを巡回する検索ロボット(クローラー)を制御する方法として、ドキュメントルートに「robots.txt」を設置するのが一般的です。

ここでは記述方法などの詳細は記載しませんが、常時SSL化の際には取り扱いに注意する必要があります。

例えば、常時SSL化前からすでにWebサイトの一部でHTTPSを利用しているものの、セキュリティ面から検索結果に表示したくないページ(ログイン画面など)があるために、「robots.txt」を設置してHTTPS全般を検索ロボットの巡回からブロックしている、というケースもあると思います。

この場合、HTTPSのドキュメントルートに設置している「robots.txt」をそのままにしておくと、せっかく常時SSL化しても検索ロボットには全く認識されない状態になってしまいます。

常時SSL化に合わせて一度「robots.txt」の内容を確認し、最適な記述に修正しておきましょう。

ページ単位のmetaタグの設定

ページ単位で検索サイトへのインデックス(登録/表示)を制御する方法として、各ページ単位でmetaタグを利用する方法があります。

セキュリティ面やミラーページなどの設置の際に利用されることが多いですが、もし現在記述がある場合は念のため内容を確認しておきましょう。

<meta name="robots" content="noindex"> などになっていると、そのページはインデックスされないので注意してください。

HTTPSへのアクセスに一本化する設定(1) 301転送

「301転送」とは、Webサイトの構成変更などによりページのURLが変わった場合に、Webサイトの利用者や検索ロボット(クローラー)を変更前 → 変更後のURLへ自動的に転送(誘導)する仕組みです。

常時SSL化においては、HTTPのページにアクセスがあってもHTTPSの同等のページに転送するために、301転送を利用します。

ちなみに、昔は <meta refresh～> の記述で対応していました。
「5秒後に自動的にジャンプします」というページを見たことがある方も多いかもしれません。

この方法は、Googleなどの検索ロボットには変更後のURLが正しく伝わらない問題があり、変更前のファイルもmetaタグの記述のために残す必要があるなど、管理上も非常に煩雑でした。

301転送は、「.htaccess」ファイルによる転送を実施します。
この方法はGoogleも推奨しているため検索ロボットの問題はクリアになり、「.htaccess」ファイルを管理するだけでOKなので、管理上の問題も解決します。

なお、「.htaccess」ファイルは、サーバーのさまざま挙動を制御することが可能です。
設定を誤るとWebサイトが見られなくなったり、リダイレクトがループしたりする恐れがありますので、テストサーバー上で充分な検証を実施してから公開してください。

以下の内容を記述した「.htaccess」ファイルを、HTTP(常時SSL化前)のドキュメントルートに設置します。

1行目/2行目は、すでに「.htaccess」ファイルが存在し、かつ同じ記述があれば繰り返す必要はありません。

4行目は、(ドメイン名)の部分を適宜書き換えてください。

もし、サブディレクトリにも「.htaccess」ファイルが存在する場合は、それにも上記の記述を念のため追加しておいてください。

その場合、4行目は以下のように記述を変更します。

設定が終わったら、「http://」のURLでWebサイト内のさまざまなページにアクセスし、正常にリダイレクトされるか動作確認を行います。

動作確認は、目視と別記事で記載したSearch Consoleの「Fetch as Google」で行います。

常時SSL化の際に必要なGoogle系ツールの設定

Search ConsoleでHTTPのプロパティ(常時SSL化前の旧URL)の「Fetch as Google」にアクセスし、テキストボックスには何も入力せずに「取得」ボタンをクリックします。

リダイレクトが正常に動作すれば、リストにその旨が表示されます。
詳細を確認すると、リダイレクトされた内容が表示されます。

（図5-2-1）Fetch as Googleによるリダイレクト確認

301転送が正しく動作することが確認できたら、Webサイトの利用者の誘導は正しく行われますし、Googleも今後はhttps://のURLをインデックスするようになります。

この時点で、HTTPのディレクトリ上のデータは、この「.htaccess」ファイル以外、すべて削除しても問題ありません。

HTTPSへのアクセスに一本化する設定(2) HSTSの設定

決してHTTPSとタイピングしようとして間違ったわけではありません。
HSTS(HTTP Strict Transport Security)は、詳しく書けば別で記事が1本書けるほどややこしいものです。

端的に言うと、常時SSL化したWebサイトにWebブラウザから「http://」でアクセスしても、強制的にHTTPSでアクセスさせる仕組みです。

301転送と同じように見えるかもしれませんが、Webサイトを閲覧する際の挙動が少し違います。
301転送は、「http://」でアクセスすると、HTTPのドキュメントルートの「.htaccess」ファイルの内容から転送を判断します。

HSTSは、「http://」でアクセスすると、初回はまずHTTPのドキュメントルートの「.htaccess」ファイルの内容からHTTPSに転送されます。

転送先であるHTTPSのドキュメントルートの「.htaccess」ファイルにHSTSの設定が記述されていれば、Webブラウザに「このドメイン名のWebサイトは、次回以降必ずhttps://で接続するように!」という記録が残ります。

そして次回以降、「http://」でアクセスしようとしてもWebブラウザの判断で強制的に「https://」で接続が始まります。

HSTSの設定/記述方法

HTTPSのドキュメントルートの「.htaccess」ファイルに以下の記述を追加します。
Webサイトの状況に合わせて「max-age」以降の記述を修正します。

max-age HSTSの設定をWebブラウザに記憶させる期間です。単位は「秒」です。
自信がなければ、「max-age=86400;」(=秒=丸1日)程度に設定しておけば、何か不備があっても1日でWebブラウザのHSTSの設定がリセットされます。
最初は短めに、問題がなければ長め(31536000秒=1年)などに設定するとよいでしょう。
includeSubDomains(省略可能) 対象のWebサイトで使用するドメイン名のすべてのサブドメインにも、HSTSのルールを同様に適用します。
このパラメータを付加すると、サブドメインでHTTPSに対応していないWebサイトでもHTTPSが強制され、アクセスできなくなってしまいますので、設定には細心の注意を払いましょう。
と、これで失敗した筆者が書いておきます・・・。
preload(省略可能) プリロードHSTS(Preload HSTS)に対応させる場合、このパラメータを付加します。
詳細は次項でご説明します。

プリロードHSTS

HSTSの基本的な動きは、前述の通り2回目以降の接続にHTTPSを強制するものでした。

プリロードHSTS(Preload HSTS)は、HSTSが設定されているドメイン名/Webサイトのリストを対応Webブラウザにあらかじめ登録しておくことで、1回目からHTTPを経由せずにHTTPSを強制する仕組みです。

このリストに自社のWebサイトを掲載してもらうための登録フォームも用意されています。

HSTS Preload List Submission

上記Webサイト内に記載されていますが、実際に登録するためにはなかなかハードな条件があります。
最初の方の一部分を訳してみると、

  • 有効なSSLサーバー証明書が設定されている
  • HTTPへのアクセスがHTTPSにリダイレクトされている
  • サブドメインもすべてHTTPSになっている

というように、それだけで無理っぽいと思う人も多いと思います。

上記以外にも、max-age/includeSubDomains/preloadの記述内容に条件があったりと、なかなかハードルが高く、正直に言うと筆者の管理するWebサイトは登録できていません。

これについては、障壁になる諸問題を解決し、登録が成功したら本記事をアップデートしたいと思います。

その時は本項の冒頭の通り、HSTSだけで1本の記事になるかもしれませんね。

この記事のポイント

  • Webサイトの利用者や検索ロボットを適切にHTTPSに誘導するための設定は必須です
  • 作業には細心の注意を払い慎重に実施しましょう

関連記事

2018/08/06
Chrome 69からHTTPSの表記が変化！Chrome 70以降も要チェック！
2018/06/26
常時SSL(https)化はマストになった！Chrome 68、Chrome 70でWebサイトはどうなる？