HTTPS設定に関する地に足のついたガイド

2014年からずっと世間から離れて引きこもっていない限り、GoogleがHTTPSを順位表示に軽微な影響をもたらす基準として利用し始めたと聞いたことがあるでしょう。そして今後HTTPSの順位表示へのウェイトが高まってくるともGoogleは言及しています。

基本的にはHTTPS (セキュアで暗号化された接続）を使っているサイトが、HTTPサイトよりもわずかに高い順位で表示されるかもしれないということです。

現状ではこれは軽微なシグナルに過ぎず、影響のあるサイトはグローバルクエリの１％にも満たないとGoogleは説明しているものの、この発表により十分人々がパニックを起こし、HTTPSへの移行が加速化するということをGoogleは知っていることでしょう。

この方針転換は、今後のサイトの構築・運用方法に大きな変化をもたらすきっかけとなると思われます。これまでは、HTTPSはクレジットカードの詳細やEmailアドレスといったユーザーの個人情報を取得するサイトにのみ有効であったのですが、今やHTTPSはコンテンツを表示するのみのサイトやブログを含むあらゆるサイトにとって有効となっているのです。

Step 1：パニックを起こさないこと

まず第一に、この時点でHTTPSは主要な順位表示のシグナルではなく、今後もその重要性が変わらない可能性もあります。Googleは長期的にはこのシグナルのウェイトを再考するとしていますが、コンテンツの質など他のシグナルに比べて重要性は低く、ごく少数のクエリのみに影響を与えるに留まると思われます。

加えて、サイト移行やドメインへの変更に伴うコスト、開発リソース、UXなどへの影響を考えると、今すぐ焦って対応すべき点ではないでしょう。そのため、落ち着いて簡単な確認から対策を考えていくようにしましょう。

Step 2：現在の設定を確認すること

サーチコンソールでHTTPとHTTPSの両方が許可されているか。これはHTTPSへの設定とサイト移行において必須となります。
Fetch as DeepCrawlやFetch as Googlebot、 Web SnifferなどのHTTPチェックツールを使って、HTTPとHTTPSのドメインが互いにリダイレクトしているかどうか、またどのHTTPステータスコードが利用されているか。
ドメインがリダイレクトしない場合は、canonicalタグがあるか。canonicalタグはURLに常にHTTPSを含んでいなければならず、これはHTTP URLを利用している場合に関しても同様です。
サイトにGoogleでインデックスされているHTTPSのページがあるかどうか（HTTPとHTTPSそれぞれのページの数を確認する）。HTTPの確認を行うにあたり、‘site:example.com -inurl:https’ と入力する必要があります。
SSL証明書が有効かどうか。SSL Shopper社のSSL checkerがおすすめです。
HTTPとHTTPSが混在していないか。
HTTPSサイトで広告が表示されるか。
無料のRobotto アカウントに登録し、HTTP/HTTPS設定の変更があった際にアラートを出すようにしておく。

Step 3：希望するホスティング方法を選択すること

現在の設定を把握できたら、今後は次のステップとしてどの設定を行うか、以下のような選択肢の中から決めてください。

選択肢１：両方ホスティングしてHTTPSへ正規化する

この方法では、HTTPのURLは他の用途のために維持される一方、GoogleはHTTPSページのみインデックスを行ないトラフィックを生み出します。基本的に２つのドメイン（HTTPとHTTPSを利用）を管理することになりますが、GoogleはHTTPSバージョンのみをインデックスします。

HTTPのURLを維持しておける点でこれが最もシンプルで良いように見えるかもしれませんが、以下のように問題を複雑化してしまうリスクもあります。

２つのドメインを管理することになるため、重複コンテンツ問題を避けるためにcanonicalタグを適切に機能させておく必要がある。
依然としてGoogleのインデックスにある全てのURLをHTTPSバージョンに移行する必要がある。この移行の最初のステップは、常にHTTPSのURLを利用するためにcanonicalタグをアップデートすること。
検索エンジン以外のソースから訪問したユーザーはHTTPSサイトの恩恵を受けられない。コンテンツしか存在しないサイトのユーザーであっても、HTTPサイトに比べてHTTPSサイトでの方がより保護されていることになり、これはセキュリティが高いほどユーザーに届けられる間にコンテンツが変更されたり、エラーを起こしたりすることが少ないことを意味します。詳しくは、Google I/O 2014のHTTPSに関する講演の動画をご覧ください。

HTTPSサイトのために正規化URLを利用することに関して、詳しくはこのGoogleのサポート概要をご覧ください。

選択肢２：HTTPSをホストし、HTTPをリダイレクトする

これはGoogleが推奨する選択肢です。 301リダイレクトを利用するということは、検索エンジンからのユーザーであろうとそれ以外のソースからのユーザーであろうと、全て暗号化され、データ完全性が確保され、保護されたHTTPSサイトの認証によるメリットを享受できるということです。HTTPかHTTPSかという点がURLにおける唯一の変更点であり、http://example.com/url を https://example.com/url にリダイレクトすることにおいてトラフィックへの影響はありません。

サーチコンソールにはHTTP/HTTPSを管理する方法がないため、この選択肢を用いる場合には、サイトは別のドメインを利用し、そのドメインがインデックスされるということになります。

しかし、異なるドメインへの移行には、膨大な開発リソースに加え、問題が発生しないように徹底的な調査、管理、検証が必要になります。HTTPSへ移行して適切に機能するようにサイトを改修する必要も出てきますし、場合によっては改修ができずサイトを最初から再構築しなければならない可能性もあります。

HTTPSへのサイト移行は以下のような基本的なステップに従って行なわれます。

HTTPSで運用するサイトを準備する（大量の開発が発生する可能性がある）
HTTPとHTTPSの両方をサーチコンソールで認証する。異なるドメイン間での移動に過ぎないので、アドレスツールの変更は不要。
トラフィックと検索エンジンをHTTPからHTTPSへ移すために301リダイレクトを利用。

HTTPSへのサイト移行を強く推進しているGoogleのエキスパートは何人かいますが、John Mueller氏はサイト移行が引き起こしてきた予期せぬ問題について議論（英語）しており、Googleとしても発生しうる問題のリストを示すサポート文書を公表しています。こうした対応は、潜在的な問題が全て解決されてHTTPSにおける設定が安全に行えるようになるまで、サイト移行を実行すべきではないということを示唆しています。

サイト移行計画については、以下のような点に加え、自社サイト特有の問題も考慮に入れた上で検討してください。

HTTPSへサイトが移行したことに対する明確なシグナルにはならないので、302リダイレクトを使用しない。Googleは、301リダイレクトを利用すべきであると明示している。
JS、CSS、画像など全てのリソースはHTTPS上に存在する必要がある。詳しくは、Maile Ohye氏のSMX Advanced 2014でのプレゼン資料（英語）へ。
内部リンク、サイトマップ、canonicalタグ、robots.txtファイル、アナリティクスのトラッキングコードなどは、HTTPSを参照するように更新する。
広告やRSSサービスなどのサードパーティリソースはHTTPSに準拠するような設定にできない可能性があり、移行するかどうかを決定する前に確認しておく必要がある。
同様に、サードパーティへウィジェットやその他リソースを提供しており、それらが異なるHTTP/HTTPSのバージョンにある場合、自社と他社のセキュリティ設定において何らかの不一致があり、これが原因となり問題が発生する可能性がある
アナリティクスやバックリンクのデータも影響を受ける可能性があり、これは特に同業種内の多くのサイトがHTTPSに移行した場合には顕著である。HTTPSのURLを利用できるようにバックリンクを更新することもできるが、これは大量のリソースが必要な上に、おそらく徒労に終わる。バックリンクは未だに301やcanonicalタグの追加と同様のウェイトを、検索エンジンにおいて持っていると指摘されている（英語）。
SSNSでの共有も、社会的な証明を維持できるように移行・管理される必要がある（FacebookやGoogle +、LinkedInのみが自動的に共有機能を移行できますが、これには数週間/数ヶ月必要）。

移行に関する補足

サイトを完全に移行して、すべてを新しいバージョンに301リダイレクトした後は、新しいバーションにdisavow (リンク否認) ファイルをアップロードすることをJohn Mueller氏は提案（英語）している。こうすることで、古いサイトからdisavowファイルのない新しいサイトへとページランクが移動することによって起こる問題を避けることができる。
不正なプロトコルにあるURLの問題を解決するためにURL削除ツールを使用しない。これは１つのバージョンを削除することで、URLの全てのwww/非wwwや http/httpsのバージョンを削除してしまうからである。
HSTS（HTTP Strict Transport Security）をサポートするウェブサーバーを使用することをGoogleは推奨している。これにより自動的にHTTPSページをブラウザがリクエストするようにでき、Googleが検索結果にセキュアなURLを表示するようになる。
サーチコンソールもBingウェブマスターツールも正確な設定の下で利用されなければならない。HTTPとHTTPSの両バーションを認証した上で、片方（HTTPS）のみを利用するような設定にする。

HTTPSに関して注意すべき問題

HTTPに比べてHTTPSの方が読み込みが遅い

HTTPSページはHTTPページに比べてわずかに遅いため、エンゲージメントに関するデータに影響がある場合があります。しかし、SEOの観点だけで言えば、HTTPSの順位表示に関するシグナルがこの点を補完するはずです。この問題に関するインパクトを制限するためにSEOベストプラクティスを活用し、HSTSをサポートしているウェブサーバーを利用することを検討してください。こうしたサーバーでスピードが向上する可能性もあります。

サイト間トラフィック移動のトラッキングが困難に

保護された検索へのGoogleのシフトがオーガニックキーワードデータにもたらした影響と類似していますが、多数のサイトがHTTPSドメインに移行した際のビジビリティへの長期的な影響は深刻なものになる可能性があり、バックリンクのトラフィックを増やす潜在力を正確に測ることはできません。

GoogleアナリティクスやサーチコンソールでのHTTP/HTTPS URLへのサポートが不十分

GoogleアナリティクスにおいてHTTPSのトラフィックをネイティブで見分けることは不可能であり、サーチコンソールはHTTPSを別のドメインとして認識します。

サーチコンソールにおいて www/非wwwのドメインの違いに関してできるような設定をHTTP/HTTPSに関しては行うことができません。GoogleはHTTPとHTTPSを共にサーチコンソールで認証した上で、HTTPをHTTPSに301リダイレクトする方法を推奨しているに過ぎません。

サーチコンソールのいくつかの機能にあるユニークデータはサイト移行をモニタリングするために活用できます。例えば、HTTPSへ切り替える際に、インデックスステータスや検索クエリのような機能を使って、HTTPバージョンでは減少しているがHTTPSでは増加しているようなデータを取得できます。 John Mueller氏はこれについて最近のウェブマスターハングアウト（英語）で言及しています。

HTTPSとHTTP/2

HTTP/2とは

HTTP 1は外部アセットがほとんどないサイト向けにデザインされていました。そのため一般的にはブラウザがアセットをダウンロードしていましたが、これは容量の軽いページでは問題ありませんでした。現在ではほとんどのページには50以上のリソースがあり、HTTP 1では対処できなくなってきています。

HTTP/2は同時に多くのリソースをダウンロードでき、それらに優先順位をつけ、圧縮したHTTPヘッダーをサポートするなど機能の幅が広がっています。

HTTP/2とGoogle

Chromeは2016年までにHTTP/2に移行するため、サイトがこの便益を得るためにはサーバーをアップデートしなければなりません。

我々の知る限り、こうした切り替えに関してSEO上のメリットはありませんが、Googleがこれを推奨している（そしてそれがサイト表示速度やユーザーのエンゲージメントに関係している）という事実を考えれば、将来的にSEOにも有効となるはずです。いずれにせよ、サイト表示速度の向上はエンゲージメントに寄与し、間接的にSEO上のメリットをもたらすと言えるでしょう。

HTTP/2とHTTPS

FirefoxはTLSではなく、HTTP/2のみをサポートするということを発表しており、必然的にHTTPSが必要になってきます。他のブラウザも同様に従う可能性があり、HTTPSへの移行のメリットが増加していくと思われます。

DeepCrawlを使ってHTTPSを検証するために役立つ設定とレポート

プロジェクト設定時にHTTP/HTTPSを選択すること

DeepCrawlは指定されたバージョンからクロールを始めますが、相互にリンクされている場合には両方クロールし、リダイレクトやcanonicalタグの設定に関するレポートを行ないます。

エイリアスとして設定する

DeepCrawlにHTTPとHTTPSの両方をクロールさせるためにドメインエイリアス（詳細設定）として設定を行ってください。これにより自分の設定を見ることができるようになります。

Robottoのような他のツールを使うことで、設定の変更をモニタリングすることができます。

canonicalタグが正しく機能しているか確認する（前述の選択肢１）

DeepCrawlの孤立した正規化ページレポートでHTTP/HTTPSのcanonicalタグがうまく機能しているかどうか確認することができます。

リダイレクト設定されている全リンクをリストで把握する

[設定 > すべてのリダイレクト]のレポートで301/302のリダイレクトステータスコードを戻すページ、またはmeta refreshリダイレクトを含むページへのリンクを全て見ることができます。

このレポートを使って、HTTPSバージョンへとアップデートの必要な内部リンクのリストをダウンロードしてください。

ドメインの重複を検出する

DeepCrawlはドメイン重複の全バリエーションを示すレポートを提供しており、サイト規模の重複問題を検出することができます。

壊れた内部リンクを見つける

[検証 > 壊れた内部リンク]レポートを使って、サイト移行時に発生したエラーのせいで壊れているリンクを更新してください。

302リダイレクトを見つける

[インデックス > 301以外のリダイレクト] レポートを使って302リダイレクトを見つけ、それらを301リダイレクトへとアップデートしてください。