Chrome 68を前にHTTPのsiteはformだけでなく全pageのHTTPS移行を確認する

HTTPで公開しているsiteは、問い合わせformだけをHTTPSへ替えて終えません。Chrome 68では、入力欄の有無にかかわらず、HTTP pageをnot secureと表示する予定です。移行するときは、最初に公開URL、certificateの名義と期限、HTTPからHTTPSへのredirect、画像やscriptの読み込み先、formと計測を分けて確認します。HTTPSへ替えることは見た目の警告を消す作業ではなく、読者が開くpageと送る情報を一つの安全な接続へそろえる作業です。

Chromium Blogは2月8日、2018年7月のChrome 68から全てのHTTP siteをnot secureと表示すると案内しました。Chromeは既に、HTTP page上でpasswordやcredit card informationを入力する画面を対象に警告を広げてきました。Chrome 68では対象がHTTP page全体になります。Lighthouseには、HTTPで読み込むresourceとHTTPSへ替えられるresourceを調べるmixed content auditがあることも案内されています。

formだけを直しても公開URLがHTTPなら警告は残る

HTTPのformをHTTPSの送信先へ替えることは、送信時の接続を考える一歩です。しかし、読者が最初に開くpageがHTTPなら、address barにはnot secureの表示が出ます。会社案内、サービス説明、article、問い合わせ前の案内、form完了pageまで、読者がHTTPで開けるURLを残したままにしない方がよい。

ここでいう全pageは、管理画面のURLだけを数える意味ではありません。検索結果、広告、mail、SNS、社内資料、名刺のQR codeから開かれる公開URLを含みます。top pageをHTTPSにしても、広告のlanding pageや過去のarticleがHTTPのままなら、読者は別の接続へ入ります。まずアクセス解析や広告の設定でよく使うURLを選び、そのURLがHTTPとHTTPSのどちらで開くかを表にします。

URLを集める目的は、HTTP URLを全部手で書き換えることではありません。どのURLをHTTPからHTTPSへ移すか、HTTPへ来た読者をどこへ送るかを決めることです。HTTPとHTTPSに同じ内容を残すと、読者にも検索engineにも代表URLが分かりにくくなります。公開先をHTTPSに決めたら、HTTPの同じpathを対応するHTTPS URLへ移す設定を確認します。

certificate、domain、redirectの担当を同じ表へ置く

HTTPS化には、certificateを発行する人、serverへ設定する人、domainを管理する人、公開後の画面を確認する人が関わります。作業を頼む場合も、「SSLを入れてほしい」だけでは不足します。certificateがどのdomain名を対象にするか、更新時の通知が誰へ届くか、server設定を誰が変更できるか、HTTP URLをHTTPSへ送る設定を誰が確認するかを分けます。

たとえばwww付きとwwwなしの両方でsiteを開ける場合、どちらを公開URLにするかを先に決めます。certificateが一方の名前だけに対応していて、もう一方から直接開くと接続errorになるなら、redirectより前に接続を直す必要があります。HTTPからHTTPSへの移動と、wwwの有無をそろえる移動を別々に追加すると、読者が何度もredirectされることがあります。最終的にどのURLを表示したいかを一つ決め、そこへ届く経路を確認します。

certificateを設定した日だけで、運用が終わるわけではありません。有効期限が近づいたときに誰が更新するか、server会社からのmailが誰へ届くか、外注先が変わってもaccountへ入れるかを確認します。domain、server、certificateのaccountを制作側だけの名義にすると、更新時にsiteを直せないことがあります。作業を頼んでも、domainとserverの管理権限、更新通知の受信先はsiteを運用する側が把握しておきます。

mixed contentは画面が見えても残さない

HTTPSのpageを開けても、画像、stylesheet、JavaScript、font、iframeなどをHTTPで読み込んでいれば、接続が混ざります。画面上で画像が表示されているから問題がないとは決めません。browserが読み込みを止めるresourceもあれば、表示だけを許すresourceもあります。公開画面を一度見るだけでなく、browserのDeveloper ToolsやLighthouseで読み込み先を確かめます。

直す順序は、resourceのURLを見つけ、HTTPS版があるかを確認し、対象pageで表示と操作を見る順です。外部の地図、動画、form、広告tag、access analyticsのscriptは、URLをHTTPSへ替えても別の設定が必要なことがあります。外部serviceを使っている場合は、何のためのscriptか、誰が管理しているか、HTTPSで使えるかを一覧にします。遅いresourceや古いtagを見つけても、役割を確認せずに消さないようにします。

たとえばcompany profileのpageで、古いロゴ画像だけをHTTPで読んでいる場合は、画像のURLをHTTPSへ替えた後にPCとmobileで見ます。一方、問い合わせformを動かす外部scriptなら、URLを替えた後に送信まで試します。pageを安全に開けることと、読者が用件を進められることを同じ確認で済ませない。画像、form、計測、外部linkごとに、必要な操作を決めます。

変更後は読者の入口と計測を同じURLで確かめる

HTTPSへの移行後は、管理画面で設定値を見るだけでは足りません。HTTP URLをaddress barへ入れ、対応するHTTPS URLへ移るかを確認します。次に検索や広告で使うlanding pageを開き、本文、画像、menu、form、電話linkを操作します。最後にformを送信し、完了page、受信mail、アクセス解析や広告計測に必要なtagが動くかを確認します。

変更を一度に入れると、表示が崩れた原因と計測が消えた原因を分けにくくなります。URLのredirect、resource URL、formの送信先、tagの設定を変えるなら、対象URLと変更内容を記録して順に確認します。HTTPからHTTPSへ移した後の数字を、移行前の数字と比べるときも、URL、期間、広告の設定、計測tagが同じ条件かを見ます。protocolを替えたことだけを理由に、問い合わせや順位がどう変わるかは断定できません。

Chrome 68へ備える最初の作業は、HTTPで開く公開URLを三つ探すことです。次に、そのURLをHTTPSへ移し、certificateとredirectを確認します。その後にmixed content、form、計測を一つずつ確かめます。この順序なら、警告表示だけを追わず、読者が安全に読み、必要な情報を送れるsiteへ移せます。