HTTPSへの移行は順位シグナルだけで決めず、安全な通信とURL変更を一緒に設計する

Googleは、HTTPSを検索順位を決めるシグナルの一つとして使い始めました。しかし、HTTPSへ移す第一の目的は、ブラウザとserverの間で送受信する内容を暗号化し、利用者を守ることです。順位への影響だけを理由に急いでURLを変えてはいけません。

HTTPからHTTPSへの移行では、証明書の導入だけでなく、すべての旧URLから対応する新URLへの301転送、内部リンク、canonical、XMLサイトマップ、robots.txt、Googleウェブマスターツールまで一組で変更します。

HTTPSの順位シグナルは内容より強くない

GoogleによるHTTPSの公式発表では、安全に暗号化された接続を検索順位のシグナルとして使い始めたと説明されています。ただし、このシグナルが影響するのは世界の検索queryの1%未満で、良質なcontentなどのシグナルより重みが小さいとされています。

したがって、HTTPSへ変えれば、内容が不足したページや利用しにくいページの順位問題まで解決するとは考えません。

順位は導入理由の一部にとどめます。問い合わせform、login、管理画面だけでなく、利用者が読むページを含めて、どの範囲を安全な接続へ移すかを先に決めます。

証明書とHTTPS応答を先に確認する

URLを転送する前に、HTTPSで各ページを正常に表示できる状態を作ります。Googleは、single domain、multi-domain、wildcardのどの証明書が必要かを決め、2048-bit keyの証明書を使うよう案内しています。

確認対象は、鍵の長さだけではありません。

• 証明書の対象hostと公開するhostが一致するか
• https://で代表ページが200を返すか
• CSS、JavaScript、画像をHTTPSで取得できるか
• formの送信先がHTTPSになっているか
• 証明書の期限と更新担当が決まっているか

証明書の購入とserver設定を制作会社へ依頼しても、契約名義、更新連絡の受取先、期限切れを確認する担当は事業者側でも把握します。導入作業を外へ任せることと、更新できる状態を所有することは別です。

旧URLごとに対応するHTTPS URLへ301転送する

HTTPSで表示できることを確認したら、HTTPの各URLを、同じ内容を持つHTTPSのURLへ301転送します。

http://example.jp/service/a/
  -> 301
https://example.jp/service/a/

すべての旧URLをHTTPSのtop pageへ送るのではありません。商品説明は対応する商品説明へ、会社案内は対応する会社案内へ移します。URLの対応表を作り、次の三つを記録します。

1. 旧HTTP URL
2. 新HTTPS URL
3. HTTP statusと最終到達URL

redirectが二回以上続く場合や、HTTPとHTTPSの間を往復する場合は、設定を直します。転送後の確認では、最初の応答だけでなく、最後に200を返すURLまで追います。

canonical、内部リンク、サイトマップをHTTPSへそろえる

301転送を入れても、サイト内のlinkがHTTPのままなら、browserとcrawlerは毎回redirectを通ります。template、navigation、本文、画像、CSS、JavaScript、formに残るHTTP URLを確認します。

代表URLを示すcanonicalもHTTPSへ変えます。XMLサイトマップには、redirectするHTTP URLではなく、最終的に200を返すHTTPS URLだけを含めます。

Googleは、同じsecure domainのresourceにはrelative URLを使い、HTTPSサイトをrobots.txtで遮断せず、可能なページにはnoindexを付けないよう案内しています。移行のために新しいHTTPS側をまとめて遮断すると、確認とindex移行を進められません。

HTTPとHTTPSを別の確認済みサイトとして管理する

Googleウェブマスターツールでは、HTTPとHTTPSを別のsiteとして確認します。HTTPSへの移行前に両方を登録し、Index Status、Crawl Errors、サイトマップを分けて追います。

確認する順は次のとおりです。

1. HTTPとHTTPSの両方を所有者確認する
2. HTTPSの代表URLをFetch as Googleで取得する
3. HTTPS用のXMLサイトマップを送る
4. HTTPからHTTPSへの301転送を確認する
5. HTTP側とHTTPS側のIndex Statusを継続して見る
6. Crawl Errorsに誤った転送先や取得失敗がないか調べる

HTTP側のindex数が減り、HTTPS側が増える途中では、合計と内訳を分けて読みます。HTTPの数字だけを見て減少を障害と決めず、HTTPS側で対応するURLがindexされているかを確認します。

一度に確認できる範囲から移す

小規模なsiteでも、URL、resource、form、external serviceを同時に変えると、問題の原因を分けにくくなります。最初は代表ページと問い合わせの流れをHTTPSで確認し、URL対応表、証明書、外部resource、301転送、canonicalを点検します。

ただし、同じsiteを長期間HTTPとHTTPSへ無計画に分けて運用しません。試験範囲と全体移行日を決め、移行後はHTTPSを正規URLとしてそろえます。

HTTPSは、順位を上げるための飾りではありません。安全な通信を提供し、その変更によって生じるURL移行を壊さず完了させるための運用です。

最初の一手は、現在公開しているURLを一覧にし、各URLに対応するHTTPS URL、証明書の対象host、更新担当を記入することです。転送設定は、HTTPS側で同じ内容を200で返せることを確認してから行います。