HTTP→HTTPS移行

要点 — HTTPからHTTPSへの移行とは、サイト内の全ページを安全でない http:// アドレスから、安全な https:// アドレスへ移すことです。証明書を導入し、古いURLをそれぞれ新しい安全なURLへリダイレクトして、サイトの破損やランキング低下を防ぎます。慎重に実施すれば安全で、損失を招くのは不注意な実装です。

実際に行うこと

HTTP URLをHTTPSへ移すと正規URLが変わるため、恒久的なサーバー側リダイレクトと一貫したcanonicalシグナルを使う必要があります。 Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: Site moves with URL changes HTTPSの設定では、有効なTLS証明書を提示し、混在コンテンツも避けなければなりません。 Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: HTTPS

現在のページURLは http:// で始まっています。これを、安全に暗号化され、南京錠が表示され、Chromeの「保護されていない通信」警告が出ない https:// へ移します。コンテンツ、ホスト名、パス、クエリ文字列はすべて同じままで、CMSやホスティング基盤も同時には変更しません。変わるのは各URLの先頭数文字だけです。

ページ自体は移動しないため、これはサイト移行の中で 最も穏やかな 種類です。ただし、それ以外を変えない場合に限ります。サブドメインの統合、URL再構成、コンテンツの書き換え、プラットフォーム変更も同時に行うなら、別の高リスクな移行です。下の短い説明も参照してください。それ以外の場合でも移行であることに変わりはなく、慎重な対応が必要です。

最も重要な1つのルール

古いすべての http:// URLを、対応する正確な https:// URLへ301リダイレクトします。 301は「恒久的」なリダイレクトで、検索エンジンに「このページは今後ずっとここにあるので、すべてを移してください」と伝えます。Googleは301によってランキングの強さが失われないと確認しているため、正しく切り替えればトラフィックを維持できます。

問題はリダイレクトが欠けている場合や、ページが古い http:// アドレスから画像やスクリプトを読み込もうとする場合に起きます。この「混在コンテンツ」によって、ブラウザ内でページの一部が壊れることがあります。作業の本質は切り替え操作ではなく、古いアドレスへの参照を残さないことです。

手順の概要

1. 現状のスナップショットを取得 します。全ページの一覧と現在のランキングを保存し、移行後に比較できるようにします。
2. 証明書を取得して導入 します。Let’s Encryptのような無料証明書でもSEOには十分です。
3. 可能なら 複製環境で先にテスト し、公開日に想定外の問題が起きないようにします。
4. 切り替えます。 古いURLを安全なURLへリダイレクトし、内部リンクとサイトマップを更新し、http:// で読み込まれるものをすべて修正します。
5. Search Consoleを再確認します。 最も簡単なのは、すべての http / https / www の組み合わせを自動的に包含する ドメインプロパティ です。個別に確認する必要はありません。
6. リダイレクトを維持 し（最低1年、理想は恒久的）、数週間トラフィックを監視します。小さな変動は正常です。

URL名、サブドメインの統合、CMS、ページ内容も 同時に 変えるなら、単純なプロトコル切り替えより大規模で危険な移行です。完全版の サイト移行 手順を使い、その中にHTTPS切り替えを組み込んでください。

証明書の選び方、数千URLのリダイレクト対応、4種類のSearch Consoleプロパティ、監視期間、ロールバック計画まで含む技術者向けの完全版は、上級者向け タブで解説します。HTTPSがランキングシグナルとしてどこに位置するかは、HTTPSハブから確認してください。

要点 — HTTPからHTTPSへの移行は プロトコルだけ を変えるサイト移行です。ホスト、パス、クエリ文字列、コンテンツ、プラットフォームは同じで、スキームだけを変更します。すべてが同じなら最も低リスクですが、ほかのサイト移行と同じ規律が必要です。稼働中のHTTPサイトを記録し、TLS証明書を選んで導入します。無料のDV証明書も有料証明書と同じ軽微なランキングシグナルを得ます。Googleが確認するのは発行元ではなくスキームです。ステージングで予行し、切り替え時には 全URLを1対1でサーバー側301リダイレクト します（301でPageRankは失われません）。各ページのcanonicalをHTTPSの自己参照にし、内部リンク、サイトマップ、hreflangを更新し、サイトを壊す前にブロック可能な混在コンテンツを解消します。Search Consoleでは、全スキームとホストの組み合わせを一括で扱う ドメインプロパティ を追加します。データを分けたい場合だけHTTPSプロパティを個別に確認します。HTTPSサイトマップを送信し、ドメイン移転用のChange of Addressツールは 使いません。リダイレクトは 最低1年 維持しますが、これは期限ではなく下限です。Crawl Statsとインデックス登録を監視し、回復する下落は移行途中、続く下落は障害と判断します。ロールバック計画は用意しますが、まずHTTPSを修復してください。キャッシュ、HSTS、Cookie、Service WorkerによりHTTPへの完全な復帰が危険になる場合があります。HSTS preloadは文字どおり不可逆ではありませんが、解除が遅く運用リスクが高いものとして扱います。

HTTPSハブでは、HTTPSを使う理由と移行の概要を説明しています。ここではその補足として、実際の移行を成功または失敗に分ける詳細な手順を解説します。

まずリスクを正しく見積もる：プロトコルだけの移行

Googleはプロトコル変更をURL変更を伴うサイト移行として扱います。一時的なランキングやレポートの変動は起こり得ますが、完了時期は保証されません。 Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: Site moves with URL changes 通信の安全性と検索処理は関連しますが、別の問題です。 Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: HTTPS

サイト移行の危険度には幅があります。ドメイン、URL構造、CMSやプラットフォーム の変更はURLの識別情報を書き換えるため、実質的なリスクがあります。プロトコルだけの切り替えが低リスクなのは、ほかのすべてを維持する場合だけ です。1つのルールでリダイレクトできると判断する前に、次の項目を確認します。

• ホスト名 — www と非 www の統合や、サブドメイン変更を同時に行わない。
• パスとクエリ文字列 — URL再構成、スラッグ変更、パラメータ整理を同じリリースに含めない。
• コンテンツ — ページの書き換え、統合、削除を同時に行わない。
• プラットフォームとレンダリング挙動 — CMS、フレームワーク、ホスティングの移行を並行して行わない。

4項目をすべて維持すれば、ドメイン、パス、コンテンツは同一で、各URLの先頭にあるスキームだけが変わります。そのためGoogleは、“don’t need to use the Change of Address tool” (翻訳) 「Change of Addressツールを使う必要はない」と明記しています。届け出るべきアドレス変更がないからです。

最も重要な結果は、URLが 1対1かつ決定論的に 対応することです（http://example.com/x → https://example.com/x）。通常は1つのサーバールールで処理でき、リダイレクトマップも自動的に決まります。各旧URLの移転先を手作業で確認する必要があるドメイン移行やプラットフォーム移行とは異なります。この前提を保つと、証明書、混在コンテンツ、Search Consoleには労力をかけ、移転先の検討には時間を費やさないという優先順位が明確になります。

ドメインやプラットフォームも 同時に 変更するなら中止してください。複数変更を重ねた移行ではリスクが増幅し、プロトコル切り替えは最も小さな問題になります。難しい移行には完全版の サイト移行 手順を使い、その中にHTTPSを組み込みます。

ステップ1 — 変更前に稼働中のHTTPサイトを記録する

移行前の状態がなければ、成功したか比較できません。サイトがHTTPで稼働している間に、次の情報を取得します。

• 稼働中サイトの完全クロール — すべての 200 URLに加え、特に 既存リダイレクトのすべて と移転先を保存します。公開後に再クロールして差分を取り、以前 200 だったURLが 404 になれば不具合と判断します。
• ランキングのスナップショット — 追跡キーワードの公開後の下落を比較する基準にします。
• Search Consoleのエクスポート — 検索パフォーマンス（クエリ、ページ、クリック、表示回数）、ページのインデックス登録、Crawl Statsを保存します。GSCのデータはHTTPプロパティからHTTPSプロパティへ 移行されない ため、これが移行前の唯一の記録です。
• 被リンクプロファイル — 外部評価が大きく、単一ホップの正確なリダイレクトを特に必要とするURLを把握します。
• 現在の robots.txt と noindex ディレクティブ — HTTPSサイトまで意図せずブロックしていないことを後で確認します。

ステップ2 — TLS証明書を選んで導入する

費用を抑えるうえで重要なSEO上の事実は、ランキングシグナルが証明書ではなくURLスキームを確認する ことです。Gary Illyesは、“basically looking at the first five characters in front of the URL, and if it’s HTTPS … it will get a minimal boost.” (翻訳) 「基本的にURL先頭の5文字を見て、HTTPSならごくわずかな加点を得る」と説明しています。したがってSEOでは、標準的なLet’s Encryptなど無料の ドメイン認証（DV） 証明書も、有料のOVやEV証明書とまったく同じシグナルを得ます。OVやEVが提供するのは 組織の身元情報 であり、ランキングではありません。ランキング上昇や特定の証明書種別、鍵アルゴリズムによる特典を約束してはいけません。Google自身が、これは費用をかけるほどの強力な施策ではなく、ごく軽微なシグナルだと説明しています。

技術面では、次の項目を正しく設定する必要があります。

• 対象範囲。 単一ドメイン証明書は1つのホスト名を対象とします。ワイルドカード（*.example.com）が対象にする階層は1つだけで、foo.example.com には使えますが、次は対象外です： foo.bar.example.com。深いサブドメインには、マルチドメイン（SAN）または追加の証明書を用意します。
• 鍵の強度。 Googleは “generate a 2,048-bit RSA key pair” (翻訳) 「2 048ビットのRSA鍵ペアを生成する」よう案内しています。短い鍵は総当たり攻撃に弱く、長すぎる鍵はリソースを浪費します。
• 自動更新。 移行後に最も起こりやすい障害は証明書の期限切れです。更新を自動化し（Let’s Encryptはその用途に適しています）、有効期限を監視します。Googleは一般にHTTPSを正規URLとして 優先 しますが、その優先は無条件でも自動でもありません。無効な証明書、安全でない依存関係、HTTPSからHTTPへのリダイレクト、HTTPを指すcanonicalタグにより、Googleが選ぶ正規URLがHTTPへ戻る場合があり、HSTSでもこの優先判断は上書きできません。 Evidence for this claim Google generally prefers HTTPS as the canonical version of a page, but that preference is conditional: an invalid certificate, insecure dependencies, an HTTPS-to-HTTP redirect, or an HTTP canonical tag can flip Google's choice back to the HTTP URL. HSTS is a browser-only mechanism and cannot override Google's canonical selection. Scope: Describes Google's conditional HTTPS canonical preference, not a guarantee that certificate problems are search-invisible. Confidence: high · Verified: 2026-07-17 Google: Consolidate duplicate URLs したがって証明書切れは、ユーザーの信頼を失う全画面警告を出すUX／セキュリティ上の緊急事態であると同時に、長引けばHTTPSの正規URL優先を失う検索上のリスクでもあります。いずれにせよ迅速に修正します。期限切れ、自己署名、ホスト名不一致、不完全なチェーンなどの詳細は TLS／SSL証明書 を参照してください。

ステップ3 — ステージングで予行する

ステージングまたは本番前環境で、切り替え全体を先に実施します。検証項目は次のとおりです。

• クエリ文字列、末尾スラッシュ、www と非 www を含む すべてのパス形式 でリダイレクトルールが動く。
• リダイレクトループ がない。HTTPSからHTTPへ戻って繰り返す誤設定は、管理者を含む全員を締め出します。
• 開発者ツールのコンソールで ブロック可能な混在コンテンツがなく、ページが正常に描画される。
• ステージング上で canonicalタグ がすでに https:// を出力する。

ステージング環境はインデックス登録から保護します。認証、または本番公開前に 必ず削除する noindex を使います。移行専用の noindex を本番に残すのは典型的な自損事故です。Googleの案内も、移行時だけ必要だった noindex や robots.txt のブロックを削除し忘れないよう明記しています。

ステップ4 — 大規模なリダイレクト対応

プロトコル切り替えでは対応関係が決定論的なので、大きな対応表ではなく 1つのルール を使います。

• サーバー側、1対1、恒久的（301）。 すべての http:// URLを、同じパスの https:// へ送ります。アプリケーションコードやクライアント側JavaScriptではなく、サーバーまたはエッジ設定（Apache、Nginx、CDN）で処理し、Botに明確なサーバー301を返します。
• リダイレクトチェーンを作らない。 既存のHTTPリダイレクト（例：http://a → http://b）がある場合、HTTPSへの切り替えで http://a → http://b → https://b と延長しないでください。元の ルールを更新し、旧URLを 最終的なHTTPS移転先へ1ホップで 送ります。Googleは最大 “10 hops” (翻訳) 「10ホップ」をたどりますが、“advise[s] redirecting to the final destination directly.” (翻訳) 「最終的な移転先へ直接リダイレクトする」よう勧めています。ホップが増えるたびにクロール予算と速度を浪費します。
• ホームページへ一括リダイレクトしない。 対応表にないURLも、それぞれのHTTPS版へ送ります。すべてを / へ送るのは、実際にランキングを失う移行ミスです。
• クロールで対応を検証する。 公開後にHTTP URL一覧を再クロールし、それぞれが正しいHTTPS URLへ単一の 301 を返すことを確認します。302、チェーン、404 は不可です。

ステップ5 — canonical、サイトマップ、hreflangのシグナルを更新する

リダイレクトが主要な役割を担いますが、不適切な内部設定をGoogleに修正させてはいけません。実際のシグナルも更新します。

• Canonical。 各ページに 自己参照 rel="canonical" を設定し、自己の https:// URLを指すようにします。Googleのサイト移行ガイドは、“Each new URL should have a self-referencing rel=“canonical” <link> tag.” (翻訳) 「各新URLには自己参照のrel=canonicalリンクタグが必要」と明記しています。http:// を指したままのcanonicalは移行と衝突します。正規化で問題になる典型的な競合シグナルなので、すべてをHTTPS URLにそろえます。
• 内部リンク。 テンプレートとコンテンツ内のリンクを https://（またはプロトコル相対／ルート相対）へ変更します。数千件の内部リンクを http:// のままにし、リダイレクトへ依存しないでください。すべての内部 http:// リンクが、ユーザーとBotに不要なリダイレクトを1つ増やします。
• XMLサイトマップ。 canonicalかつインデックス可能なHTTPS URLだけで再生成し、lastmod を更新します。公開後に新しいサイトマップをGSCへ送信します。
• Hreflang。 国際サイトでは、すべてのhreflang注釈が各代替ページの HTTPS 版を参照する必要があります。一部が http、一部が https の状態は、発見しにくい国際SEOの不具合です。
• 構造化データとOpen Graph URL。 og:url、JSON-LD内のcanonical参照、ハードコードした絶対URLをすべてHTTPSへ変更します。

ステップ6 — 公開後ではなく公開前に混在コンテンツをなくす

混在コンテンツ とは、HTTPSページがHTTP経由でサブリソースを読み込む状態です。公開日に最も起こりやすい不具合です。現在の用語では、ブラウザの処理に応じて次のように分類します。以前の「アクティブ／パッシブ」という区分は古いものですが、旧文書やツールでは今も使われます。

• ブロック可能な混在コンテンツ — スクリプト、スタイルシート、iframe、XMLHttpRequest / fetch（以前の「アクティブ」）。改ざんされたスクリプトがページ全体を書き換えられるため、ブラウザは 完全にブロック します。切り替え後に実際にサイトを 壊す のがこの種類です。スタイルシートやJSバンドルがブロックされると、ページの表示や機能が失われます。最初に修正してください。
• アップグレード可能な（任意ブロック可能な）混在コンテンツ — 画像、音声、動画（以前の「パッシブ」）。現代のブラウザは、警告を出してHTTPのまま表示するのではなく、透過的にHTTPSへ 自動アップグレード し、失敗すればブロックする傾向があります。「まだ読み込める」という挙動はブラウザのバージョン次第で、保証ではありません。これも次に修正します。
• 例外もあります。 一部のブラウザや埋め込み環境（プラグイン経由のリソース、一部の旧式 <applet> / <embed> など）は、どちらの規則にも完全には従いません。一般則を前提にせず、利用者が使うブラウザで挙動を確認する理由の1つです。

HTTPSサイトのクロール（Ahrefs Site Audit、Screaming Frog）、Chrome開発者ツールのコンソール、CSPレポートで検出します。一時的な予防策として、Content-Security-Policy: upgrade-insecure-requests ヘッダーは、http:// のサブリソース要求を送信前に https:// へ暗黙的にアップグレードするようブラウザへ指示します。ただし、CSPヘッダーはすべてのHTTPSエンドポイントが存在し、HTTP版と同じ挙動をすることを証明しません。参照元URLの修正や実際のブラウザでのテストに代わるものでもありません。混同しやすい点として、HTTPページへの通常のアンカーリンクは混在コンテンツではなく、単にページを移動するリンクです。

ステップ7 — Search Consoleの対象範囲を正しく設定する

見落とされがちな手順ですが、普遍的なチェックリストではなく選択の問題です。Search Consoleの URLプレフィックスプロパティ は、http://example.com、http://www.example.com、https://example.com、https://www.example.com を、データを共有しない4つの別プロパティとして扱います。4つすべてを確認する 必要はありません。

• ドメインプロパティ はすべてのプロトコルとサブドメインの組み合わせを自動的に集約します。1つ追加すれば、ほかを触らずに切り替えを包含できます。ほとんどのサイトにとって最も簡単な既定値です。
• URLプレフィックスプロパティ は、正確なプロトコルとホストごとにデータを分けます。意図的に分割データが必要な場合だけ維持または追加します。たとえば、残存するHTTPトラフィックと稼働中HTTPSサイトを比較する場合です。これはレポート上の選択であり、必須ではありません。

どちらを選ぶ場合も、次を実施します。

• サイトを追跡するプロパティ（ドメインプロパティまたはHTTPS URLプレフィックスプロパティ）で 新しいHTTPSサイトマップを送信 します。
• Change of Addressツールを使わないでください。 Googleは、“If you’re moving your site from HTTP to HTTPS, you don’t need to use the Change of Address tool.” (翻訳) 「サイトをHTTPからHTTPSへ移す場合、Change of Addressツールを使う必要はない」と明記しています。このツールはドメイン単位の移転専用で、ここで使うのは善意による間違いです。
• 既存のHTTPプロパティは確認済みのまま維持 します。リダイレクトの処理と旧URLがインデックスから外れる状況を確認でき、有用な監視シグナルになります。
• disavowファイルがある場合は 再確認 します。エントリはHTTP URLを参照し、プロパティ単位で保存されています。

サイト全体ではなく個別URLを診断する場合、GSCの HTTPSレポート は、証明書、リダイレクト、canonical、robots、サイトマップ評価など、URLがHTTPSへ移らなかった理由を示します。ただし 完全な一覧ではなくサンプル診断ツール として扱ってください。サンプリングされ、URL照合時にクエリパラメータを無視するため、自社クロールで見つかる問題をすべて検出できません。読み方は GSC HTTPSレポートの詳細 を参照してください。

ステップ8 — 監視期間：移行途中か、障害か

“temporary fluctuation in site ranking during the move” (翻訳) 「移行中はサイトランキングが一時的に変動する」と想定してください。これは正常で、慌てて元に戻す理由ではありません。重要なのは、移行途中の下落と障害による下落を見分けることです。

• 数日から数週間で 回復する下落 は、インデックス内のHTTP URLをHTTPSへ置き換えている状態です。Googleによると、小規模から中規模サイトでは大半のページの移行に数週間かかり、大規模サイトはさらに長くかかります。
• 続く下落 は問題発生を示します。残存する robots.txt ブロック、ステージングから残った noindex、http:// を指すcanonical、大量のHTTP内部リンク、評価を損なうリダイレクトチェーンなどを確認します。

回復期間に固定値はありません。1つの数字で「完了」と判断せず、次の項目を個別に追跡します。

• TLSとブラウザの挙動 — 証明書の有効性とチェーン、および代表ページの開発者ツールコンソールを確認します。混在コンテンツエラーや証明書警告がない状態が必要です。検索指標では分からない領域です。
• 追跡中プロパティのGSC Crawl Stats — GooglebotがHTTPS URLを取得し、応答コードの構成が健全（主に 200 と旧URLの 301）であることを確認します。5xx の急増は新しい負荷でサーバーが苦しんでいることを示します。
• ページのインデックス登録レポート — HTTPS URLが「インデックス登録済み」へ、HTTP URLが「リダイレクトのあるページ」へ移ることを確認します。この交差が望ましい状態です。
• 主要ページのURL検査 — レポート上のcanonicalがHTTPS URLで、混在コンテンツなしで描画されることを確認します。
• サーバーログ — Botが実際にアクセスしたURLと受け取ったステータスを示す根拠です。Botが短期間HTTP URLへアクセスし続けるのは正常ですが、チェーンやループは問題です。
• 分析と事業成果 — HTTPSからHTTPへの参照元データは削除されるため、「direct」トラフィックが増えることがあります。自社の外部リンクがHTTPSの移転先を指すことを確認します。また、ランキングが回復しても事業指標が回復したとは限らないため、コンバージョンと売上を別に追跡します。

目安として 2〜4週間 は積極的に監視し、その後もインデックスの切り替えが完了するまで軽く監視を続けます。大規模サイトやクロール頻度の低いサイトは長くかかり、完了日は保証されません。

ステップ9 — リダイレクトを維持し、HSTSを慎重に追加する

• 301を長期間維持します。 Googleの案内は “as long as possible, generally at least 1 year” (翻訳) 「可能な限り長く、通常は最低1年」です。これはGoogleが推奨する 下限であり、削除してよい期限ではありません。実務ではサイトが存続する限り維持します。古い http:// URLへの外部リンクやブックマークは完全には消えません。
• HSTSは代替ではなく第2の層です。 Strict-Transport-Security ヘッダーはドメインで常にHTTPSを使うようブラウザへ指示し、「最初のリクエスト問題」を解消します。新規訪問者の最初の要求は301が発動する前にHTTPで送られ、SSL stripping攻撃者が狙う隙になります。ただしブラウザがHSTSを適用すると、クローラーには見えない ブラウザ内だけの307リダイレクト を行います。検索エンジンにはサーバー側の 301 が引き続き必要で、両方を使います。
• HSTS preloadは、文字どおり不可逆ではないものの、解除が遅く危険だと考えます。 ブラウザ内蔵のpreload一覧への申請には、1年以上の max-age、includeSubDomains、preload が必要です。includeSubDomainsは申請したホストだけでなく 全サブドメイン に適用されるため、HTTPS未対応のサブドメインは壊れます。hstspreload.orgから削除することは可能ですが、ブラウザのリリース周期を通じて反映されるため遅く、古い一覧を持つブラウザは更新までHTTPS限定を強制します。運用上は危険ですが、文字どおり不可逆ではありません。Googleは、“Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (翻訳) 「証明書検証エラーのあるHTTPSを決して配信しないほど運用が堅牢だと確信するまで、HSTSを有効にしないでください」と強く警告しています。

ステップ10 — 限界を理解したロールバック計画を用意する

低リスクな移行にも出口は必要ですが、問題発生時の既定対応はHTTPへ戻すことではなく、HTTPSを修復することです。 「ロールバック」は限定的な安全網であり、確実な巻き戻しではありません。ブラウザやCDNにキャッシュされた301、Secure 属性付きCookie、HTTPSオリジンに登録されたService Worker、HSTSやpreloadのポリシーにより、公開時の実装が正しくても、一部の訪問者にはHTTPの再配信が安全でない、または機能しない場合があります。

切り替え前に、次の準備をします。

• トラフィックが少ない時間に公開 します。Googleも “time your move to coincide with lower traffic, if possible.” (翻訳) 「可能ならトラフィックが少ない時期に移行する」よう提案しています。静かな時間帯なら公開日の不具合に遭遇する利用者を減らし、対応の余裕を持てます。
• リダイレクトの背後で HTTP配信を維持 します。HTTPリスナーを停止せず、301の送信元を残します。HTTPSサイトに重大な問題がある場合、リダイレクトルールを戻す選択肢も維持できます。
• 初日にHSTSを有効化しないでください。 HSTS、特にpreloadはHTTPへの復帰を大幅に難しくします。ブラウザがポリシーをキャッシュすると、サーバーの動作にかかわらずドメインへHTTP接続しません。HTTPSサイトがしばらく安定してから追加します。
• 中止条件を事前に定義 します。サイト全体の 5xx、リダイレクトループ、大規模な混在コンテンツのブロックなどです。該当したら、(1) 不正な証明書、欠落リソース、壊れたcanonicalなどHTTPS側の問題を直接修正できるか確認します。通常は可能で、復帰より速く安全です。(2) HTTPS自体が利用不能な場合に限り、応急措置としてリダイレクトルールを戻します。ただしキャッシュ済みリダイレクト、Cookie、Service Workerはサーバー側の変更だけでは元に戻らず、不完全な復帰になると想定します。

本番環境で慌ててデバッグせず、落ち着いて診断してください。「HTTPへ戻す」は日常的で完全な取り消しではなく、使わずに済ませたい最終手段です。

AIによる要約

上級者向け解説を短くまとめると、次のとおりです。

• 条件を満たす場合に限り、プロトコルだけの移行です。 ホスト、パス、クエリ文字列、コンテンツ、プラットフォームを維持し、スキームだけを変えます。5項目をすべて維持すれば最も低リスクで、URLは1対1に対応し、通常は1つのリダイレクトルールで済みます。ドメイン移転用の Change of Addressツールは使いません。ほかも変更するなら複合移行として扱います。
• 最初に基準を記録： 完全クロール（すべての200と既存リダイレクト）、ランキング、GSCエクスポート（HTTPSプロパティへデータは移行しない）、被リンク、現在のrobotsとnoindexを保存します。
• 証明書： ランキングシグナルはスキームに基づくため、無料のDV証明書（Let’s Encrypt）も有料証明書と同じ軽微なシグナル を得ます。OV／EVが提供するのは身元情報で、ランキングではありません。証明書種別や鍵アルゴリズムによる順位上昇を約束しないでください。2 048ビット鍵を使い、ワイルドカードの対象が1階層だけであることを確認し、更新を自動化 します。GoogleによるHTTPSの正規URL優先は条件付きで、不正な証明書、安全でない依存関係、HTTPSからHTTPへのリダイレクト、HTTPを指すcanonicalによりHTTPへ戻る場合があります。HSTSでも上書きできません。
• ステージングで予行： すべてのパス形式がリダイレクトされ、ループ、ブロック可能な混在コンテンツがなく、canonicalがHTTPSを出力することを確認します。移行専用の noindex は本番前に削除します。
• 切り替え： 全URLを 1対1かつサーバー側で301 にします。301でPageRankは失われません。チェーンを作らず、最終HTTPS移転先へ1ホップで送り、ホームページへの一括転送は避けます。canonical（HTTPS自己参照）、内部リンク、サイトマップ、hreflang、OG／JSON-LD URLも更新します。
• 混在コンテンツ： 現在の用語は ブロック可能（スクリプト、スタイル、iframe、XHR。ブラウザが完全にブロックするため最優先）と アップグレード可能（画像、音声、動画。現代のブラウザがHTTPSへ自動変更し、失敗時はブロック）です。以前のアクティブ／パッシブ区分は古いものです。upgrade-insecure-requests CSPは一時的な安全網で、HTTPSエンドポイントの存在を証明しません。HTTPページへのアンカーリンクは混在コンテンツではありません。
• Search Consoleは一律の数ではなく選択です。 すべてのスキームとホストを自動集約する ドメインプロパティ を1つ追加します。URLプレフィックスプロパティ（http、https、http-www、https-www）は任意のデータ分割であり、必須ではありません。HTTPSサイトマップを送信し、disavowファイルを確認します。GSCの HTTPSレポート はクエリパラメータを無視するサンプル診断で、完全な一覧ではありません。
• 固定期間を決めず、項目ごとに監視： TLSとブラウザ挙動、Crawl Stats、ページのインデックス登録、URL検査、ログ、分析と事業成果は、それぞれ別の状況を示します。数日から数週間で 回復する 下落は移行途中、続く 下落は残存ブロック、canonical欠落、HTTP内部リンク、チェーンなどの障害です。
• リダイレクトは最低1年を下限として維持 します。多くのサイトでは恒久的に残します。HSTS はクローラーに見えないブラウザ内の 307 であり、301の代わりではなく追加の層です。Preloadは解除が遅く危険 です。hstspreload.orgから削除できますが、急いで導入すべきではありません。
• 限界のあるロールバック計画： 復帰より先にHTTPSを修復します。その方が通常は速く安全です。トラフィックが少ない時間に公開し、HTTP配信を維持し、初日にHSTSを有効化せず、中止条件を決めます。ただしキャッシュ済みリダイレクト、Cookie、Service Workerにより、HTTPへの完全な復帰は不可能な場合があります。

公式ドキュメント

移行の計画と実行に使う一次資料です。

Google

• URL変更を伴うサイト移行 — サーバー側301、1ホップのリダイレクト、自己参照canonical、「最低1年リダイレクトを維持」「HTTPからHTTPSではChange of Addressツール不要」「トラフィックが少ない時期に移行」を扱う手順です。
• 重複URLを統合する — Googleによる条件付きのHTTPS正規URL優先。不正な証明書、安全でない依存関係、HTTPSからHTTPへのリダイレクト、HTTP canonicalによりHTTPへ戻る場合があります。
• サーバーでHTTPSを有効にする（web.dev） — 証明書、2 048ビット鍵、HTTPS canonicalへの301、HSTS、Cookieを解説します。
• HTTPSが重要な理由（web.dev） — HTTPSへ切り替えるセキュリティとブラウザ機能上の理由です。
• 混在コンテンツの修正（web.dev） — ブロック可能とアップグレード可能（任意ブロック可能）という現在の用語、旧称のアクティブ／パッシブ、upgrade-insecure-requests を解説します。
• ランキングシグナルとしてのHTTPS（2014年） — 「ごく軽微なシグナル」とした最初の投稿と、証明書種別、相対URL、robots.txtでHTTPSをブロックしないことなどの実装上の注意です。
• ページエクスペリエンスを理解する — HTTPSとGSC HTTPSレポートの位置付けを説明します。

証明書と設定

• Let’s Encrypt — 自動更新を備えた無料のDV証明書です。
• SSL Labs Server Test — 導入後のTLS設定を評価します。
• hstspreload.org — HSTS preloadの要件と削除時の警告です。

Chrome / Chromium

• 安全なWebの定着（2018年） — Chrome 68がすべてのHTTPを「保護されていない通信」と表示し、多くのサイトの移行を促した期限について説明します。

出典からの引用

移行方法を定める公の発言です。各リンクから出典ページ内の引用箇所へ移動できます。

Google — リダイレクトとPageRank

• “301 and other permanent redirects don’t cause a loss in PageRank.” (翻訳) 「301などの恒久的リダイレクトによってPageRankが失われることはありません」。— Google Search Central。 引用箇所へ
• “Keep the redirects for as long as possible, generally at least 1 year.” (翻訳) 「可能な限り長く、通常は最低1年リダイレクトを維持してください」。— Google Search Central。 引用箇所へ
• “Each new URL should have a self-referencing rel=“canonical” <link> tag.” (翻訳) 「各新URLには自己参照のrel=canonicalリンクタグが必要です」。— Google Search Central。 引用箇所へ

Google — HTTPからHTTPSへの移行固有の事項

• “If you’re moving your site from HTTP to HTTPS, you don’t need to use the Change of Address tool.” (翻訳) 「サイトをHTTPからHTTPSへ移す場合、Change of Addressツールを使う必要はありません」。— Google Search Central。 引用箇所へ
• “Expect temporary fluctuation in site ranking during the move.” (翻訳) 「移行中はサイトランキングが一時的に変動すると想定してください」。— Google Search Central。 引用箇所へ

Google — HSTSと証明書（web.dev）

• “Use HTTP Strict Transport Security (HSTS) to avoid the cost of the 301 redirect.” (翻訳) 「301リダイレクトのコストを避けるため、HTTP Strict Transport Security（HSTS）を使用してください」。— web.dev（Google）。 引用箇所へ
• “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (翻訳) 「証明書検証エラーのあるHTTPSを決して配信しないほど運用が堅牢だと確信するまで、HSTSを有効にしないでください」。— web.dev（Google）。 引用箇所へ

Gary Illyes — スキームに基づくシグナル

• “Basically looking at the first five characters in front of the URL, and if it’s HTTPS … it will get a minimal boost.” (翻訳) 「基本的にURL先頭の5文字を見て、HTTPSならごくわずかな加点を得ます」。— Gary Illyes（Google、2016年。Search Engine Landによる紹介）。 記事を読む

どの手順を選ぶべきか

「スキーム以外も変更するか」

• http:// から https:// だけを変更し、ホスト、パス、クエリ文字列、コンテンツ、プラットフォームは同じ → この記事のプロトコル専用手順を使います。リダイレクトルールは1つで、Change of Addressツールは不要です。
• ドメイン、ホスト名やサブドメイン、URL構造、コンテンツ、CMSやプラットフォームも変更 → 中止してください。 高リスクの複合移行です。完全版の サイト移行 手順を使い、その中にHTTPSを組み込みます。

「どの証明書が必要か」

• HTTPSスキームとランキングシグナルだけが必要 → 無料の DV証明書（Let’s Encrypt）。有料証明書と同じ軽微なシグナルで、順位上昇を期待して高額なものを選ぶ必要はありません。
• 目に見える組織名が必要、または規制業界 → OV／EV。ただし得られるのは身元情報で、SEOではありません。
• 複数のサブドメイン → ワイルドカードが対象にするのは 1階層だけ です。深いサブドメインにはSAN／マルチドメイン証明書が必要です。

「公開後にランキングが下落した。慌てるべきか、待つべきか」

• 最初の数週間で徐々に回復している → 待ちます。 インデックスがHTTPからHTTPSへ切り替わっている正常な状態です。
• 数週間後も回復しない → 問題が起きています。 robots.txt の残存ブロック → 残った noindex → http:// を指すcanonical → http:// の内部リンク → リダイレクトチェーン → ページを壊す混在コンテンツ、の順で確認します。

「今すぐHSTSを有効にすべきか」

• 公開日、または移行が安定していない → いいえ。 必要時のHTTP復帰を大幅に難しくします。
• HTTPSがしばらく安定し、更新も自動化済み → ヘッダーを追加します。
• preload一覧を検討中 → 復帰しないと 確信 できる場合だけにします。削除は可能ですが遅く、運用リスクが高いもので、文字どおり一方通行ではありません。

「Search Consoleの4プロパティをすべて確認する必要があるか」

• 継続性だけが必要で、データ分割に関心がない → ありません。 すべてのスキームとホストを自動的に含む ドメインプロパティ を1つ追加します。
• 残存HTTPトラフィックとHTTPSサイトを比較したい → その区分用にURLプレフィックスプロパティを維持または追加します。任意であり必須ではありません。

「Change of Addressツールは必要か」

• 同一ドメインでHTTPからHTTPSへ変更 → 不要です。 Googleが明記しています。
• 実際のドメインを変更 → 必要ですが、別の移行です。

「旧URLに明確なHTTPS版がない場合、どこへリダイレクトするか」

• プロトコル切り替えなら必ず対応するURLがある → 同じパスの https:// へ1ホップで送ります。
• ページが実際になくなった → コンテンツ上の判断です（404 / 410、または最も関連するページへのリダイレクト）。ホームページへ一括転送しないでください。

HTTPからHTTPSへの移行チェックリスト

事前準備（基準記録と準備）

• 稼働中HTTPサイトの完全クロールを保存（すべての 200、既存リダイレクト、移転先）。
• ランキング、GSCエクスポート（検索パフォーマンス、ページのインデックス登録、Crawl Stats）、被リンクを保存。
• 現在の robots.txt と noindex ディレクティブを記録。
• TLS証明書を取得（無料DVでよい）し、2 048ビット鍵と自動更新を設定。
• ワイルドカードの対象範囲とサブドメインの深さを照合。
• ステージングで切り替え全体を予行。すべてのパス形式、ループなし、ブロック可能な混在コンテンツなし、HTTPS canonicalを確認。
• トラフィックが少ない時間帯に公開を設定。
• ホスト、パス、クエリ文字列、コンテンツ、プラットフォームがすべて不変で、本当にプロトコルだけの移行だと確認。

切り替え

• すべてのHTTP URLを、対応するHTTPS URLへ サーバー側で1対1に301リダイレクト。
• チェーンを作らず、旧URLを最終HTTPS移転先へ1ホップで送る。
• 対応表にないURLをホームページへ一括転送しない。
• 各ページの rel="canonical" をHTTPS URLの自己参照にする。
• 内部リンク、XMLサイトマップ、hreflangをHTTPSへ更新し、リダイレクト任せにしない。
• og:url、JSON-LD、ハードコードした絶対URLをHTTPSへ更新。
• ブロック可能な混在コンテンツ（スクリプト、スタイル、iframe、XHR）を修正。これらは完全に ブロック される。
• アップグレード可能な混在コンテンツ（画像、メディア）を修正。ブラウザの自動変更だけに頼らず、upgrade-insecure-requests CSPは修正ではなく一時的な安全網として設定。
• 移行専用の noindex または robots.txt ブロックを削除。

Search Consoleと公開後

• GSCにドメインプロパティを追加（推奨の既定値）。分割データが必要な場合だけHTTPS URLプレフィックスプロパティを個別に確認。
• 新しいHTTPSサイトマップを送信。既存のHTTPプロパティは監視のため確認済みのまま維持。
• Change of Addressツールを 使わない（ドメイン移転専用）。
• disavowファイルがあればHTTP URLを確認。
• リダイレクトを削除日ではなく下限として最低1年、理想はサイト存続中維持。
• リダイレクト背後のHTTPリスナーを維持。限定的な安全網であり、確実な取り消しではない。
• 公開日にHSTSを 有効化せず、HTTPSが安定してから追加。
• TLSとブラウザ挙動、Crawl Stats、ページのインデックス登録、URL検査、ログ、分析と事業成果を2〜4週間監視。固定の終了日はなく、回復しない下落は障害と判断。

標準作業手順：移行を実行する

繰り返し使える手順です。各段階の担当者を決め、ステージングでの予行を省略しないでください。

Tマイナス（1週間前）— 記録と構築

1. 稼働中HTTPサイトをクロールし、ステータスコードと既存リダイレクトを含む全URL一覧を出力。
2. GSC（検索パフォーマンス、ページのインデックス登録、Crawl Stats）を出力し、ランキングと被リンクを記録。
3. ステージングにDV証明書を取得して導入し、チェーンの有効性をSSL Labsで確認。
4. パスとクエリを維持する単一のサーバー側301ルール（http → https）を構築。
5. テンプレートを更新し、canonical、内部リンク、サイトマップ、hreflang、OG／JSON-LDがHTTPSを出力するよう変更。
6. ステージングで混在コンテンツを調査し、ブロック可能、次にアップグレード可能の順で修正。

Tゼロ（トラフィックが少ない時間に公開） 7. 証明書を本番へ配備し、有効なチェーンでHTTPSが配信されることを確認。 8. 301ルールを有効化。すぐに複数URLを確認し、それぞれが正しいHTTPS URLへ単一の 301 を返すことを検証。 9. ホームページと主要テンプレートが、コンソールの混在コンテンツエラー なし で描画されることを確認。 10. 移行専用の noindex / robots.txt ブロックを削除。

Tプラス（最初の1時間〜1日） 11. 旧HTTP URL一覧を再クロールし、1ホップの301、チェーンなし、404 なし、ループなしを確認。 12. GSCにドメインプロパティを追加（推奨の既定値）。分割データが必要な場合だけHTTPS URLプレフィックスプロパティを個別に確認し、HTTPSサイトマップを送信。 13. 新しい負荷による 5xx の急増をサーバーログとエラー率で監視。

Tプラス（最初の2〜4週間） 14. GSCのCrawl Statsとページのインデックス登録を毎日監視。HTTPS URL →「インデックス登録済み」、HTTP URL →「リダイレクトのあるページ」を確認。 15. 主要ページをURL検査。レポート上のcanonicalがHTTPSで、正常に描画されることを確認。 16. 移行前の基準と比較し、回復中の下落と続く下落を区別して、後者を修正。 17. disavowファイルにHTTP URLがないか確認。

Tプラス（安定後〜継続） 18. HTTPSが安定し、更新が自動化されたらHSTSヘッダーを追加。 19. 復帰しないと確信できる場合だけpreloadを検討。削除は可能だが遅く、運用リスクが高い。 20. 301とHTTPリスナーを、削除日ではなく下限として最低1年、理想は恒久的に維持。障害時はHTTP復帰より先にHTTPSを修復します。キャッシュ、Cookie、Service Workerにより復帰が不完全になる場合があります。

状況別の手順

共有ホスティング上の小規模サイト（数百URL） 無料のLet’s Encrypt証明書（多くのホストではワンクリック）を取得し、1つの301ルールを追加し、内部リンクとサイトマップを更新します。開発者ツールで混在コンテンツを確認し、GSCのHTTPSドメインプロパティを確認します。午後だけでも完了できます。主なリスクは、ハードコードされた http:// のアセットを見落とすことです。必ず調査してください。

CDN配下の大規模サイト（10万URL以上） 301を エッジ（CDNまたはリバースプロキシ）に置き、アプリごとの処理ではなく1つのルールで大規模に適用します。事前記録を徹底してください。移行前のクロールとGSCエクスポートが唯一の安全網です。インデックスの切り替えには小規模サイトより長くかかると想定し、負荷時の 5xx をCrawl Statsで監視し、既存HTTPリダイレクトが積み重なったチェーンを確認します。単一ホップの301を確かめるため、分割して再クロールします。

既存のリダイレクト層があるサイト（過去の移行、短縮URL） 落とし穴は http://old → http://new → https://new のような積み重ねです。元の ルールを書き換え、すべての旧URLを 最終HTTPS移転先へ1ホップで 送ります。公開後はチェーンを明示的に監査します。ここで評価が失われます。

hreflangを使う国際サイト すべてのhreflang注釈と相互リンクが HTTPS の代替ページを参照する必要があります。一部が http、一部が https のクラスターは、対象設定を気付かないうちに壊します。HTTPS上の単一情報源から全注釈を再生成します。

切り替え済みで、ランキングが下がったまま回復しない 次の順で診断します。(1) robots.txt でブロックされている、または noindex が残っていないか。(2) canonicalが https:// を指すか。(3) 内部リンクがHTTPのままではないか。(4) リダイレクトチェーンやループがないか。(5) ブロック可能な混在コンテンツがページを壊していないか、また不正な証明書によってGoogleの正規URL優先がHTTPへ戻っていないか。「HTTPSでランキングが下がった」という事例の大半は、この5つのいずれかであり、プロトコル切り替え自体ではありません。HTTPへ戻す前に、HTTPS側の根本問題を直接修正します。

避けるべきこと

• すべてをホームページへリダイレクトする。 最も損害の大きい移行ミスです。各旧URLを対応する 固有の HTTPS版へ送る必要があります。Googleも、多数の旧URLをホームページのような無関係な1ページへ送らないよう警告しています。
• 301ではなく302を使う。 302は「一時的」で、移転が恒久的でないと伝えます。エンジンがURLと評価を完全に移せるよう 301 を使います。
• リダイレクトチェーンを作る。 http://a → http://b → https://b はクロール予算と速度を浪費します。最終HTTPS移転先へ直接 送ります。
• 内部リンクを http:// のままにする。 内部リンクの整理を301任せにすると、クリックとクロールのたびにリダイレクトが発生します。リンクを修正します。
• Canonicalが http:// を指したままにする。 旧スキームへの自己参照canonicalは移行と衝突し、正規URLの選択を混乱させます。
• 公開後までブロック可能な混在コンテンツを無視する。 ブロックされたスタイルシートやJSバンドルにより、初日から実利用者のページが壊れます。切り替え 前 に修正します。
• プロトコル切り替えにChange of Addressツールを使う。 ドメイン 移転用です。ここでは不要だとGoogleが明記しています。
• GSCの4プロパティをすべて確認する必要があると思い込む。 必要ありません。1つのドメインプロパティがすべてのスキームとホストを自動集約します。ただし旧HTTPプロパティだけを確認し、HTTPSを含むものを何も用意しないのは避けるべきです。
• 公開日にHSTSまたはpreloadを有効化する。 HTTPSサイトに問題があった場合、HTTP復帰を大幅に難しくします。HTTPSが安定してから追加します。
• 移行専用の noindex を本番に残す。 ステージング保護用の noindex や robots.txt ブロックを削除せず公開すると、新サイトが静かにインデックスから外れます。
• HTTPリスナーをすぐ停止する。 301の送信元と、最低限リダイレクトルールを戻す選択肢を残すため、稼働を維持します。
• 「HTTPを維持すれば確実に戻せる」と考える。 キャッシュ済みリダイレクト、Cookie、Service Workerにより、HTTPの再配信は安全でない、または不完全になる場合があります。最初にHTTPSを修復し、復帰は日常的な取り消しではなく最終手段として扱います。

HTTPからHTTPSへの移行チートシート

リダイレクトと対応関係の要点

証明書の要点

更新するシグナル

混在コンテンツとHSTS

GSCプロパティ ドメインプロパティ はすべてのスキームとホストの組み合わせを自動的に集約するため、推奨の既定値です。URLプレフィックスプロパティ（http://example.com、http://www.example.com、https://example.com、https://www.example.com）は任意のデータ分割であり、普遍的な要件ではありません。

301を強制する（サーバー側）

プロトコルのリダイレクトはアプリケーションコードではなく、サーバーまたはエッジ設定で行います。最初にステージングでテストしてください。誤ったルールは全員を締め出すリダイレクトループを作る可能性があります。

Apache（.htaccess）

# 301 every HTTP request to the same path on HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Nginx

# Dedicated port-80 server block that 301s to HTTPS, preserving host + path
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

URLが単一ホップの301を返すことを確認する

各旧URLが、302 やチェーンではなく、対応するHTTPS版へ直接301を返すことを確認します。

macOS / Linux

# Show every hop and status code for one URL
curl -sIL http://example.com/some/page \
  | grep -Ei '^(HTTP/|location):'
# Want a single 301 -> https://example.com/some/page -> 200, no extra hops

Windows（PowerShell）

# Follow redirects and print each status + Location
$r = Invoke-WebRequest -Uri "http://example.com/some/page" -MaximumRedirection 10
$r.BaseResponse.ResponseUri.AbsoluteUri   # final URL should be https://

HTMLに残る混在コンテンツを見つける

描画済みページから、安全でないサブリソース（スクリプト、スタイル、画像、iframe）を検索します。

macOS / Linux

curl -s https://example.com/ \
  | grep -Eo '(src|href)="http://[^"]+"' \
  | sort -u

Chrome開発者ツールのConsole — 稼働中ページの安全でないサブリソースを抽出する

任意のHTTPSページでConsoleに貼り付けると、http:// を参照している要素をすべて一覧表示できます。混在コンテンツではない通常のアンカーリンクは除外します。

[...document.querySelectorAll('[src],link[href],iframe[src]')]
  .map(el => el.src || el.href)
  .filter(u => u && u.startsWith('http://'))
  .forEach(u => console.warn('Insecure sub-resource:', u));

公開後にURL一覧を一括確認する（単一ホップ301）

保存済みのHTTP URL一覧を入力し、単一ホップの正しい301でないものを抽出します。

macOS / Linux

# urls.txt = one http:// URL per line (from your pre-migration crawl)
while read -r u; do
  code=$(curl -s -o /dev/null -w '%{http_code}' -I "$u")
  loc=$(curl -sI "$u" | awk -F': ' 'tolower($1)=="location"{print $2}' | tr -d '\r')
  echo "$code  $u  ->  $loc"
done < urls.txt

サイト全体の確認には、URLごとのスクリプトよりクローラー（Ahrefs Site Audit、Screaming Frog）の方が高速です。一方、これらのスニペットは抜き取り確認やCIに便利です。

公開前に移行の対応関係を監査する

Act as a technical SEO reviewing an HTTP-to-HTTPS migration. I will provide a crawl
of live HTTP URLs, the current redirect export, the proposed HTTPS URL list, and a
staging crawl.

For every old URL, determine whether it maps one-to-one to the same host, path, and
query on HTTPS. Flag redirect chains, loops, 302s, homepage dumps, missing targets,
HTTP canonicals, HTTP internal links, HTTP sitemap or hreflang entries, blockable
mixed content, and staging noindex/robots blocks.

Return a table with old URL, observed status, first target, final target, expected
target, issue, severity, owner, and retest. Separate launch blockers from normal
post-launch index settling. Do not recommend the Change of Address tool for this
protocol-only move.

公開後の下落を診断する

Compare the pre-launch crawl and Search Console exports with the post-launch crawl,
logs, Page Indexing, Crawl Stats, and URL Inspection samples. Test for blocked
crawling, surviving noindex, HTTP canonicals or internal links, redirect chains or
loops, 5xx responses, and mixed-content rendering failures. Explain which evidence
shows normal HTTP-to-HTTPS canonical crossover and which evidence shows a broken
migration. Give the smallest reversible fix and a validation query for each finding.

プロトコルだけの移行フレームワーク

HTTPからHTTPSへの移行を、証明書導入ではなく連動する4つのシステムとして扱います。

1. 通信： 必要なすべてのホスト名で、有効な証明書と完全なチェーンをHTTPSが配信する。
2. 経路： 各HTTP URLが、対応する正確なHTTPS版へ、恒久的なサーバー側リダイレクトを1つ返す。301はURLの意味を維持する橋であり、Googleによると恒久的リダイレクトでPageRankは失われない。
3. シグナル： Canonical、内部リンク、サイトマップ、hreflang、構造化URL参照をHTTPSに統一し、クローラーにリダイレクトから移行を再発見させない。
4. 観測： 保存済みの基準、公開後のクロール、ログ、Search Consoleによって、想定内のインデックス切り替えと技術障害を区別する。

プロトコルだけという範囲でリスクが低くなるのは、ホスト、パス、クエリ挙動、コンテンツ、レンダリングが同等な場合だけです。同時に変更するなら作業を別々の移行へ分け、各障害の原因を診断できるようにします。

移行検証ツール

• リダイレクトチェッカー — 個別HTTP URLの経路全体を調べ、対応するHTTPS URLへ1ホップで到達することを確認します。
• HTTPステータスコード一括チェッカー — 公開前に保存したURL一覧を再確認し、恒久的リダイレクト、壊れた移転先、ループ、想定外のステータスを検出します。
• Canonicalチェッカー — 最終HTTPSページが、HTTPへ戻らず意図したHTTPS canonicalを宣言していることを確認します。

公開前後の結果を出力します。ツール結果は単独で判断するより、承認済みURL対応表と比較すると最も役立ちます。

移行リリーステスト

テスト1：ステージングでの予行

• 目的： リダイレクトが利用者やクローラーへ影響する前に、コンテンツとシグナルがHTTPS対応済みだと証明する。
• 方法： ステージング上の代表的なパスとテンプレートをクロールし、canonical、内部リンク、hreflang、サイトマップ、robotsディレクティブ、描画後のリソースURLを確認する。
• 期待結果： ページが同等に描画され、HTTPSシグナルを出力し、ブロック可能な混在コンテンツと移行専用のクロール／インデックスブロックがない。
• 失敗条件： HTTPシグナル、ブロックされたリソース、証明書エラー、残存する noindex / robots制限。
• 次の対応： 公開を保留し、参照元テンプレートまたは設定を修正する。

テスト2：1対1リダイレクトの再実行

• 目的： 本番の経路設定がすべての旧URLの移転先を維持することを確認する。
• 方法： 保存済みのHTTP URLクロールを一括ステータスチェッカーで再実行し、最初と最終の移転先を承認済み対応表と比較する。
• 期待結果： 各旧URLが対応する正確なHTTPS版へ恒久的リダイレクトを1つ返し、最終応答が正常である。
• 失敗条件： チェーン、ループ、302、ホームページへの一括転送、変更されたパスやクエリ、4xxまたは5xxの移転先。
• 次の対応： 元のリダイレクトルールを修正し、再実行が合格するまでロールバック用にHTTPリスナーを維持する。

テスト3：公開後の検索シグナル確認

• 目的： クローラーが一貫した移行シグナルを受け取ることを確認する。
• 方法： 主要なHTTPS URLを検査し、保存済み基準と比較してログ、Crawl Stats、ページのインデックス登録を監視する。
• 期待結果： HTTPS URLがクロールされ正規URLとして選ばれ、HTTP URLは次第にリダイレクト済みとして表示される。応答エラーはサイトの既存基準内に収まる。
• 失敗条件： HTTP canonicalの継続、広範なクロールブロック、リダイレクトループ、実質的な5xx増加。
• 次の対応： 事前定義した可逆的修正を適用する。HTTPSリリースが安定するまでHSTSを有効化しない。

読む価値のあるリソース

私の講演

• HTTPSで安全を優先する — SMX East 2016 （SlideShare）— TLS、HTTPS実装でよくある障害、301ではなく302を使うミス、HTTPS canonicalの欠落、BingやBaiduでインデックス削除につながり得るTLS SNI誤設定、HTTPSからHTTPへのリンクで参照元データが失われる「dark traffic」を解説した講演です。これらの仕組みに関する私の理解であり、導入率の統計は2016年時点です。

関連記事

• テクニカルSEO初心者ガイド — 移行とHTTPSをテクニカルSEO全体の中で位置付けます。

業界のリソース

• Googleの URL変更を伴うサイト移行 — サーバー側301、1ホップのリダイレクト、1年以上の維持、HTTPからHTTPSでChange of Addressツール不要を扱う正式な移行手順です。
• Googleの サーバーでHTTPSを有効にする と 混在コンテンツを修正する — 集約された実装資料として特に有用です。
• Let’s Encrypt — 自動更新付きの無料DV証明書で、ランキングシグナルにはこれで十分です。
• SSL Labs Server Test — 証明書導入後のTLS設定を評価します。
• hstspreload.org — preloadを申請する前に、要件と削除時の警告を確認します。
• HSTSの概要と使用方法 （Kinsta）— preloadの固定化リスクを扱う実践的なHSTSガイドです。
• HTTPSは簡単 （Troy Hunt）— TLS設定を基礎から説明する短い動画シリーズです。

引用できる統計

• 301リダイレクトでPageRankは失われません。 「HTTPSへの切り替えでリンク評価を失う」という誤解を否定し、移行方法全体を定めるGoogleの明確な記述です。 出典
• リダイレクトを最低1年維持。 Googleが推奨する 最低期間 で、削除して安全になる期限ではありません。多くのサイトは恒久的に維持します。 出典
• Chrome 68（2018年7月）以降、すべてのHTTPページに「保護されていない通信」と表示。 HTTPS移行を任意対応から前提条件へ変えた期限です。 出典
• 現在、約89%のWebサイトがHTTPSを使用。 移行の目的は順位上昇ではなく、少数の未対応サイトにならないことです（W3Techs、2026年。最新値を要確認）。
• Googlebotがたどるリダイレクトチェーンは最大 “10 hops” (翻訳) 「10ホップ」 ですが、Googleは最終移転先への直接リダイレクトを推奨します。「チェーンを作らない」ルールの上限値です。 出典

理解度チェック：HTTPからHTTPSへの移行

HTTPからHTTPSへの移行手順を問う5問です。各問で答えを選び、結果を確認してください。

変更履歴