HTTPS移行前に、証明書・経路・依存関係・戻し方を揃える
HTTPからHTTPSへの変更はURL変更を伴うサイト移転です。Googleは準備とテスト、URLマッピング、リダイレクト、移転後の監視を案内しています。デザイン刷新やCMS移行を同時にせず、変更を切り分けます。
全ホストを証明書の対象にする
ルートドメイン、www、静的配信、API、管理画面を列挙します。証明書のSAN、チェーン、期限、自動更新、失敗通知を確認します。
TLS終端と転送責任を一つにする
CDN、ロードバランサー、プロキシ、WebサーバーのどこでTLSを終端し、転送とwww統一を担当するか構成図にします。
依存URLと外部連携を棚卸しする
テンプレート、CMS、CSS、JavaScript、画像、API、iframe、フォーム、Webhook、OAuth・決済コールバック、CSPを検索し、HTTP固定値の修正先を決めます。
基準値と復旧手段を保存する
主要URL、状態コード、証明書、5xx、フォーム、決済・ログイン、検索流入を記録し、設定バックアップと操作権限を確認します。
HTTPS側の主要操作が成功する前にHTTPを全面転送しないでください。証明書、外部コールバック、プロキシのスキーム判定、Secure Cookieを確認し、HSTSは最後に扱います。
すべての入口を、対応する最終HTTPS URLへ一度で到達させる
URL正解表は「旧URL→最終URL」をページ単位で対応させます。トップへ一括転送せず、パスと必要なクエリを維持し、wwwや末尾スラッシュの多段転送を避けます。
表は横にスクロールして、入口・応答・到達先・確認を比較できます。
| 入口 | 応答 | 最終到達先 | 確認 |
|---|---|---|---|
| http://example.com/path?a=1 | 301または308の永続転送 | https://example.com/path?a=1 | パスと必要なクエリを保ち、一段で到達する |
| http://www.example.com/path | 301または308の永続転送 | https://example.com/path | HTTP化とホスト統一を別々の二段転送にしない |
| https://www.example.com/path | 301または308の永続転送 | https://example.com/path | www側にも有効な証明書を配置してから転送する |
| https://example.com/path | 200 | 同じURL | 自己転送、ループ、HTTP canonicalがない |
| 廃止した旧URL | 対応先があれば永続転送、なければ404または410 | 内容が実質的に対応するページのみ | 無関係なトップページへ転送しない |
301と308は永続転送、302と307は一時転送として使い分ける
通常のGET・HEADでは301または308を永続移行に使えます。フォームやAPIなどメソッドと本文を保持すべきリクエストでは、クライアント・CDN・アプリの挙動を受け入れ試験し、308を含めて設計します。ブラウザ表示だけで決めず、レスポンスのLocation、状態コード、メソッド、Cookie、キャッシュを確認してください。
リダイレクトはサーバー側で一段にし、ループと取りこぼしを検査する
JavaScriptやmeta refreshではなくサーバー側で転送します。外部HTTPS・内部HTTPの構成ではスキーム誤判定でループするため、信頼するプロキシと判定方法を固定します。
- 1
代表URLではなくURL一覧を作る
サイトマップ、ログ、解析、Search Console、被リンク、CMSから旧URL一覧を作り、下層、パラメーター、www、画像、PDF、存在しないURLを含めます。
- 2
最終URLへの規則を一か所に実装する
HTTP→HTTPS、www統一、パス正規化を一つの規則へまとめます。CDNとアプリで責任を分け、除外URLとヘルスチェックを明記します。
- 3
状態・Location・回数を自動検査する
旧URLが1回で対応するHTTPS URLへ着き、最終応答が200でクエリを維持するか検査します。ループ、5xx、404、誤転送も記録します。
- 4
POST・API・Webhookを別に試す
ログイン、フォーム、決済、Webhook、APIの送信先をHTTPSへ更新し、メソッド、本文、認証、署名、Cookie、CORSを検証環境で確認します。
- 5
キャッシュと監視を移行設計へ含める
301・308のキャッシュを考慮し、検証用と本番設定を分けて消去手順を用意します。転送先、ループ、5xx、HTTPへの逆戻りを監視します。
リダイレクトループ、主要URLの5xx、ログイン・決済・フォーム失敗、別ドメインへの誤転送、POSTの消失、証明書エラーが1件でも再現する場合は全面切替を止めます。追加の転送規則を重ねず、入口、各応答、Location、プロキシヘッダー、アプリが認識するスキームを一段ずつ記録してください。
混在コンテンツは、HTTP資源をHTTPSで提供できるか確認して直す
HTTPSページがHTTPの画像、CSS、JavaScript、iframe、fetchなどを読むと混在コンテンツになります。ブラウザの自動更新に依存せず、所有URLをHTTPSへ直し、外部資源の対応を確認します。
静的検索とDB検索を両方行う
ソース、CSS、JavaScript、環境変数、CMS本文、JSON、メールをhttp://で検索します。プロトコル相対URLもHTTPSへ明示します。
実ブラウザで全種類のページを巡回する
記事、検索、ログイン、フォーム、埋め込み、決済、管理画面を巡回し、ConsoleとNetworkでHTTP要求、ブロック、CSP違反を見ます。
外部資源を安易に文字置換しない
外部URLはHTTPS提供、内容、CORS、ライセンス、SRIを確認し、非対応なら自己配信、代替、削除を選びます。
CSPは発見と防御の補助にする
Content-Security-Policy-Report-Onlyで違反を観測してから強制します。upgrade-insecure-requestsは保存済みHTTP URLの修正を代替しません。
切替は、HTTPS先行確認からSEO信号更新まで順番に行う
変更、監視、業務確認、停止判断の担当を決めます。低トラフィック時間帯や限定セクションで試し、新旧URLを監視します。検索反映には時間がかかります。
- 切替 01
HTTPSを転送なしで先行確認する
証明書、全ホスト、主要ページ、画像・CSS・JS、ログイン、フォーム、決済、API、管理画面を確認し、robots.txtとnoindexも点検します。
- 切替 02
内部URLとセキュリティ属性を更新する
内部リンク、canonical、hreflang、構造化データ、サイトマップをHTTPSへ更新します。Cookie、CORS、CSP、OAuth・決済コールバックも更新します。
- 切替 03
限定範囲から永続転送を有効にする
限定セクションでURL正解表、主要操作、ログ、外部連携を確認します。HTTP側をrobots.txtで塞がず、クローラーが転送を取得できるようにします。
- 切替 04
検索・広告・外部設定を更新する
HTTPSサイトマップを送信し、Search Consoleの各プロパティを確認します。広告、メール、重要な被リンク、解析、フィードも更新します。
- 切替 05
直後・翌日・継続の監視を分ける
直後は証明書、ループ、5xx、主要操作を監視します。翌日以降はHTTPアクセス、404、クロール、canonical、インデックス、検索流入を比較します。
- 切替 06
安定後にHSTSを段階導入する
HTTPSを維持して復旧できることを確認し、短いmax-ageで試します。includeSubDomainsとpreloadは別々に判断します。
障害時は、証明書・転送・アプリ・資源を分けて復旧する
HTTPへ戻すだけではCookie、OAuth、HSTS、検索信号の不整合が残ります。影響を限定して原因層を特定し、HTTPSのまま直すことを第一候補にします。
- 1
追加変更を止めて症状を固定する
発生時刻、URL、状態コード、Location、証明書エラー、Console、Network、各層のログと直前変更を保存し、再現手順を固定します。
- 2
利用者影響を限定する
壊れた決済・ログイン・フォームを一時停止または案内し、影響のないHTTPSページを維持します。安全警告を無視させません。
- 3
層ごとに原因を切り分ける
証明書とSNI、DNS、CDN、TLS終端、転送、アプリのスキーム認識、Cookie、CORS・CSP、外部連携、混在資源を順に確認します。
- 4
最小の変更を戻す
問題の転送、CSP、アプリ、CDN設定を既知状態へ戻します。HTTPSが正常なら、HTTPへ全面復帰せず転送だけを止めて修正します。
- 5
同じ受け入れ試験で再開する
URL正解表、主要操作、混在コンテンツ、canonical、サイトマップを再確認し、原因、影響、復旧、再発防止を記録します。
HSTSが有効なサイトは、HTTPへの切り戻しを復旧策にできない
ブラウザがHSTSを記憶すると、HTTP URLもHTTPSへ変換され、証明書エラーを回避できません。includeSubDomainsやpreloadはさらに範囲が広がります。証明書更新、代替TLS終端、DNS・CDN切替など、HTTPSを維持した復旧経路をHSTS導入前に用意してください。
HTTPS移行の完了条件を、証拠と担当で確認する
ページが開くことだけを完了条件にしません。安全性、利用者操作、検索信号、運用、復旧を同じチェックシートに残します。HTTPアクセスと旧URLの監視は、移行直後に削除しないでください。
切替前
- 対象ホスト、証明書SAN、チェーン、期限、自動更新、通知
- TLS終端、転送担当、信頼するプロキシ、ヘルスチェック除外
- 旧URL一覧、最終HTTPS URL、状態コード、クエリ維持
- 主要操作、外部連携、Cookie、CORS、CSP、コールバック
- 設定バックアップ、操作権限、連絡網、停止・復旧条件
切替直後
- 証明書エラー、ループ、転送チェーン、5xx、404
- ログイン、フォーム、決済、検索、API、Webhook、メール
- 画像、CSS、JS、フォント、iframe、fetchの混在コンテンツ
- canonical、hreflang、構造化データ、robots、サイトマップ
- 監視通知、解析、広告、Search Console、主要外部リンク
継続監視
- HTTPアクセスと転送先、旧URLクロール、転送漏れ
- インデックス、canonical選択、サイトマップ、検索流入
- 証明書更新テスト、期限通知、TLS構成変更
- 新規コンテンツと外部タグのHTTP混入
- 復旧訓練、担当者、権限、手順、連絡先の更新
HSTS導入前
- 全対象ホストと必要な全サブドメインのHTTPS安定
- HTTPへ戻さない証明書・TLS終端の代替経路
- 短いmax-ageからの段階導入と監視
- includeSubDomainsの影響範囲と非公開サブドメイン
- preload申請条件、長期影響、解除手順の確認
根拠にした一次資料・標準資料
仕様と推奨は更新されます。実装時は、利用するCDN、Webサーバー、CMS、認証・決済サービスの現行公式資料も照合してください。
HTTPS移行でよくある質問
証明書を設定したら、すぐHTTPをHTTPSへ転送してよいですか？
先にHTTPSへ直接アクセスし、全対象ホスト、証明書、主要ページ、ログイン、フォーム、決済、API、外部連携、混在コンテンツを確認します。転送はその後、限定範囲から有効にします。
301と308はどちらを使えばよいですか？
どちらも永続転送です。通常のページ閲覧では301が広く使われます。POSTやAPIでメソッドと本文を保持する必要がある場合は308を検討し、クライアントからアプリまで実際に試します。
混在コンテンツはブラウザが自動修正するので放置できますか？
放置しません。自動更新されない資源やブロックされる種類があり、将来の挙動も保証されません。所有URLをHTTPSへ更新し、外部資源はHTTPS対応を確認します。
HTTPS移行で検索順位は下がりますか？
再クロール中は変動があり得ます。一段の永続転送、HTTPS canonical、サイトマップ、Search Consoleとログで確認します。
移行後すぐHSTS preloadを申請すべきですか？
勧めません。全サブドメインを含むHTTPS運用と、HTTPへ戻さず復旧する経路が安定してから、短いmax-age、includeSubDomains、preloadを別々に判断します。
HTTPS運用の関連ガイド
HTTPS移行の成否は、転送より前の準備と転送後の監視で決まる
旧URLから最終HTTPS URLへ一段で転送します。主要操作、混在コンテンツ、canonical、5xxを確認し、HSTSは復旧経路の完成後に導入します。
この記事の編集・検証方針
Finite Field 編集部
検索移転、HTTP転送、混在コンテンツ、HSTS、TLSの一次資料を照合し、停止条件と復旧順序を含む手順として編集しています。
複数のCDN・サーバー・外部連携を移行する方へ
HTTPS移行計画と障害復旧を相談する
転送が複数層にある、決済・APIを止められない、混在URLやHSTS後の復旧に不安がある場合は、構成図、URL一覧、外部連携、証明書を準備してください。
HTTPS移行と復旧を相談する構成と運用条件を確認したうえで対応可否をご案内します。無停止、検索順位、クロール完了時期、外部サービスの継続、事故の完全防止を保証するものではありません。