HTTPからHTTPSへリダイレクト：設定と確認手順

01最初に、トップと記事の確認先を決める

自分が管理するサイトのトップと、実在する記事を一つ選びます。それぞれHTTP・HTTPSとwwwの有無を変えた4つのURLを確認します。トップへの転送が正常でも、記事がトップへ飛ばされることがあるためです。先に「最終的に開いてほしいURL」をメモしてください。

URL点検ツールを使う場合も、トップを点検して対象URLと取得時刻を照合・保存し、その後に実在する記事を別に点検します。1回で調べるのは1ページの4入口です。GETの応答列を記録表へ写す場合、HEADや初回Locationの生の値は含まれないため、別途取得するまで未確認と残してください。再利用した結果は新しい取得と区別し、途中で止まった応答列から最終値を推測しません。本文の表示はブラウザで別に確認します。

確認中は転送設定を変えず、まず応答とLocationを記録します。curlの-IはHEADリクエストなので、GETと異なる挙動が疑われる場合は通常のページ取得でも確認します。CDNやリバースプロキシがある場合は、外部からの応答とオリジンサーバーの設定を分けて考えます。

02HTTPSで開けることと、HTTPが転送されることは別

evulixの8月3日以前の設定にはwwwを非wwwへ送るルールがあり、転送先はHTTPSでした。しかし非wwwのHTTPには転送ルールがなく、運用記録ではhttp://evulix.com/が200を返していました。HTTPSのページを普段使いのブラウザで開くだけでは、この入口の欠落に気づけません。

そこで公開前に「http＋非www」「http＋www」「https＋非www」「https＋www」を別々に確認します。記事URLでも同じ組み合わせを試し、トップだけでなくパスが保たれるかを見ます。今回の修正では非wwwのHTTPSを正規URLとし、ほかの入口はそこへ転送する構成にしました。

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC,OR]
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://example.com%{REQUEST_URI} [R=302,L]

03まず転送を追わず、応答とLocationを保存する

ターミナルでは下のコマンドを一つずつ実行します。最初は-Lを付けず、HTTPステータスとLocationヘッダーを確認してください。WindowsではPowerShellの別名と区別するためcurl.exe、macOSやLinuxではcurlを使います。対象ドメインは自分のサイトへ置き換えます。

301だけで合格にせず、Locationが想定したHTTPS・ホスト・パスを指しているか確かめます。次に-Lと--max-redirsで転送を追い、最終URLと転送回数を見ます。正規URL自身が転送され続けるならループの疑いがあります。HEADを扱わないサーバーでは-Iの結果だけで判断せず、GETの応答も確認します。

下の実測では、HTTPの記事入口をGETで転送を追わずに取得しても、同じ301とLocationになりました。これはこの一入口での比較で、すべてのサイトでHEADとGETが一致するという意味ではありません。macOSやLinuxではcurl.exeをcurl、-o NULを-o /dev/nullへ置き換えます。

1. まず4入口を、転送を追わずに見る

   下の最初の4行はHEADです。各URLのステータスとLocationを控えます。正規HTTPSにLocationがなく200、別入口に想定した転送先があるかを比べてください。

2. 記事のURLでも、最初の応答をGETで見る

   5行目は-Iと-Lを付けず、-D -でヘッダーだけを画面へ出します。本文はNULへ捨てます。HEADと違う場合は方法ごとに記録し、どちらが通常のページ取得に近いかを確認します。

3. 転送後の値と、期待した記事を照合する

   最後の2行はGETで追跡し、トップと記事それぞれのfinal・redirects・statusを出します。自分の確認では残る入口にも同じ追跡を行い、8入口の記録を揃えます。最後に本文をブラウザで開いてください。

curl.exe -sS -I --max-time 15 http://evulix.com/
curl.exe -sS -I --max-time 15 http://www.evulix.com/
curl.exe -sS -I --max-time 15 https://evulix.com/
curl.exe -sS -I --max-time 15 https://www.evulix.com/
curl.exe -sS -D - --max-time 15 -o NUL http://evulix.com/essays/small-site-launch-checklist
curl.exe -sS -L --max-redirs 5 --max-time 20 -o NUL -w "final=%{url_effective} redirects=%{num_redirects} status=%{http_code}" http://evulix.com/
curl.exe -sS -L --max-redirs 5 --max-time 20 -o NUL -w "final=%{url_effective} redirects=%{num_redirects} status=%{http_code}" http://evulix.com/essays/small-site-launch-checklist

04プロキシのある環境では、HTTPSの判定場所を確認する

evulixのホスティング環境では、手前のプロキシでTLSを処理し、その奥のApacheへリクエストが届きます。8月3日の調査ではHTTPSとX-Forwarded-Protoの両方の値を確認してから、HTTPの入口だけが転送される条件を追加しました。サーバーが受け取る値を調べずに一般的な転送ルールを足すと、HTTPSでもHTTPと判定される場合があります。

設定変更前のファイルを控え、変更後は正規のHTTPSページから確認します。繰り返し転送されるときは追加したルールを戻し、ホスティング事業者の推奨設定とプロキシの扱いを確認してください。外部から送れるヘッダーを無条件に信用する構成にはせず、信頼するプロキシの範囲も環境側で管理します。

05URL確認のあとに、読者が使う入口を通す

正規URLのページでは、HTMLのcanonical（正規ページとして示すURL）、内部リンク、XMLサイトマップが同じURL方針に揃っているか確認します。転送とcanonicalは別の仕組みです。canonicalを書いても、HTTPの応答そのものがHTTPSへ転送されるわけではありません。

最後に未ログインのブラウザで記事、カテゴリ、連絡先、存在しないURLを開きます。連絡先は入力エラーと送信後の表示を確認し、受信側でも届いたことを確かめて完了にします。記録には確認日、対象URL、期待値、実測値、修正内容を残してください。設定ファイルの存在だけでは、配信中の動作は証明できません。

06期待と違う応答を、三つに分けて調べる

HTTPが200のままなら、HTTPSへ送る規則がどこで適用されるかを確認します。転送を繰り返すなら、転送先と元の条件が互いに送り返していないかを確認します。記事がトップへ飛ぶなら、パスを保持する設定とLocationを確認します。観測結果だけから一律に.htaccessの同じ行を足さないでください。

curl: (47)なら追跡回数の上限に達しています。ループを含め各Locationを確認し、上限を増やすだけで解決にしません。curl: (28)は制限時間内に取得できなかった状態、curl: (60)は証明書を検証できなかった状態です。200がない取得を成功と記録せず、日時・対象・エラーを残します。証明書のエラーを消すために検証を無効にして公開確認を終えないでください。

変更前の設定を控え、原因に対応する一箇所を直したら同じ入口で再確認します。最後に本文と配信ファイルが読めること、canonicalとサイト内リンクが正規URLを使うことまで確認して記録します。転送の結果だけでフォームや本文の品質まで確認したとは扱いません。

07自動点検の結果から、変更する前に確認すること

公開URL点検の結果は「確認できた」「問題」「要確認」「未確認」に分かれます。titleとdescriptionを取得できても、文章が分かりやすいか、検索に掲載されたかまでは分かりません。ページの本文と見比べて、主題に合ったタイトルと説明になっているかを確認します。

canonicalが最終URLと異なる場合は、どちらを正規ページにする方針かを先に確認します。重複ページの統合や移転のために別URLを指定していることもあります。転送設定、canonical、内部リンクを一度に変更せず、期待するURLを決めて一つずつ照合します。指定が複数あれば、そのままにせず採用する値を整理します。 検索対象から外すnoindexは、正規URLを選ぶ指定の代わりにはなりません。重複をまとめたいのか、検索対象から外したいのかを先に分け、公開方針に沿って確認します。

正規URLの指定はhead内で確認します。本文中の説明例やtemplate内のひな形は、実際のページ指定と区別してください。相対URLなら最初のbase hrefを基準にした解決先も確認します。たとえば指定が「/」でも、baseが別のドメインならそのドメインのトップを指します。?を含む正規URLを、点検ツールへの入力制限と混同して形式不正と判断しないでください。hreflang・lang・media・type属性付きのcanonicalは、Google検索の正規URL指定として使われないため、用途と属性を確認します。

noindexやnoneが出た場合は、公開ページなのか、意図的に検索から除外したページなのかを判断します。robots・googlebotのmeta指定とX-Robots-Tagの両方が確認先です。noneにはnoindexの指定も含まれます。特定のクローラー向けのヘッダーは対象も確認してください。指定がない結果でも、robots.txtや検索への登録状況まで確認したことにはなりません。

未確認の入口が残っているなら「残りはたぶん正常」とせず、接続、証明書、応答時間、制限をブラウザや管理画面でも調べます。点検レポートを出力し、設定の変更前後を同じURLで比べてください。保存した過去の結果は最新の状態ではありません。修正後は再点検し、表示・問い合わせの到達も手動で確認します。

URL点検の各項目では「修正・再確認を記録する」を開き、期待するURL、担当・予定日、変更内容、再確認の日時と結果をその場で記入できます。ブラウザへ明示的に保存すれば続きを開けます。同じURLを再点検するとメモは引き継がれますが、以前の結果からの記録と分かるよう記入元の取得日時を表示します。新しい応答と本文を照合し、実際に確認した内容だけ追記して保存してください。Markdownと印刷にも記入内容を含められます。