Webサイトのホスティング移行SEO

TL;DR — ホスティング移行では、訪問者が同じURLを使い続ける一方で、Webサイトの背後にある仕組みを移します。まず新しいホストを構築してテストし、ローンチ前にDNSのTime to Live（TTL）を下げ、切り替え中も旧ホストを稼働させ、両方のシステムが返す内容を比較します。DNS、証明書、ステータスコード、コンテンツ、速度、クローラーのアクセスを監視し、旧ホストのログでトラフィックがゼロになったことを確認してから停止します。

ホスティング移行とは

ホスティング移行とは、利用者に見えるURLを変えずに、Webサイトが配信される場所や方法を変更することです。別のホスティング会社への移転が代表例です。CDNの追加・交換、オリジンサーバーの変更、DNSプロバイダーの切り替えも、同じプロジェクトに含まれる場合があります。

URLが変わらないことが定義上の条件です。https://example.com/page/は、移行前後ともhttps://example.com/page/のままでなければなりません。

GoogleはこれをURL変更を伴わないサイト移転 として扱います。ドメイン、プロトコル、ホスト名、パスのいずれかも変わる場合は、代わりに完全なサイト移行 プロセスを使います。2種類の移行を同時に行っている可能性があります。

URLが同じでも移行がSEOへ影響する理由

ホスティング移行は、安定したアドレスの背後にあるすべてを変え得ます。検索エンジンには、異なるレスポンスコード、遅いサーバー、期限切れの証明書、ファイアウォールのチャレンジ、古いキャッシュページ、壊れた画像、欠落したヘッダー、または異なるレンダリング結果が返る可能性があります。

最も安全な移行は、観測できるレスポンスを維持したままインフラを置き換えます。利用者とクローラーには、旧システムで受け取っていたものと同じ正常なページが、新システムから返されるべきです。

基本的な手順

1. サイトを新しいインフラへコピーまたは接続する。
2. 公開DNSを変更せず、新しいオリジンとCDNをテストする。
3. 後の変更が早く伝播するよう、事前にDNS TTLを下げる。
4. 証明書、キャッシュ、セキュリティルール、クローラーアクセスを確認する。
5. DNSを変更し、トラフィックを新しいインフラへ送る。
6. DNSキャッシュが期限切れになるまで、両方の環境を稼働させる。
7. ログ、エラー、速度、クロール、検索パフォーマンスを監視する。
8. 旧ホストのログで残存トラフィックがないことを確認してから停止する。

Googleもホスティング変更のドキュメント で、同じ準備、切り替え、監視、停止の手順を推奨しています。

DNS TTLは何をするものか

DNS TTLは、リゾルバーがDNS応答をキャッシュできる時間を制御します。移行前にTTLを短くすると、変更されたレコードがキャッシュから早く期限切れになります。ただし、すべてのリゾルバーが即座に切り替わるわけではありません。旧値を保持しているキャッシュに対しては、ローンチ時にTTLを下げても遅すぎます。

Googleは、移行の少なくとも1週間前に、TTLを数時間などの控えめな短い値へ下げることを提案しています。これは普遍的な数値ではなく一例です。正確な値は、DNSプロバイダーと運用要件に基づいて決めます。

リダイレクトは必要か

真のホスティング移行では公開URLが変わらないため、SEO目的のリダイレクトは不要です。ホストだけを移す際に一律のリダイレクトを追加すると、インフラ問題を解決しないまま、新しい障害要因を作ります。

既存のリダイレクトは、以前とまったく同じように動作させる必要があります。現在のWebサーバー、CMS、ロードバランサー、CDNに残る古いルールも含め、新しいスタックでテストしてください。

移行が完了するのはいつか

新しいインフラが意図したレスポンスを一貫して配信し、旧インフラへ実際の利用者やクローラーのトラフィックが届かなくなった時点で、ホスティング移行は完了です。Googleは、旧プロバイダーのログを確認し、トラフィックがゼロになってから停止するよう明確に推奨しています。

TL;DR — 同一URLのホスティング、CDN、DNS移行は、レスポンスパリティとトラフィックルーティングのプロジェクトとして扱います。すべてのホスト名と依存関係を棚卸しし、ローンチ前にDNS TTLを下げ、新しいオリジンとエッジを設定し、証明書とセキュリティ制御を検証します。現実的なクローラー需要と利用者需要で負荷テストを行い、生レスポンスとレンダリング済みレスポンスを比較します。DNS伝播中は旧新インフラを二重稼働させ、両方のログ、DNS応答、エラー、レイテンシ、キャッシュ動作、クロール活動、Search Consoleを監視します。事前に合意したインフラ障害が起きた場合だけ、以前のルーティングを復元してロールバックします。

本当に同一URLの移行かを判断する

同一URLのホスティング移行では、正確な公開URL文字列を変えずにインフラを変更します。スキーム、ホスト名、ポート、パス、クエリ処理、末尾スラッシュの動作は変えません。

計画を立てる前に、プロジェクトを分類します。

URL変更をプロジェクト管理者に「単なるホスティング」と呼ばせてはいけません。デプロイ計画には、実際に伴う移行の種類をすべて含める必要があります。

インフラの棚卸しを作る

インフラの棚卸しは、目立たない依存関係がローンチ当日の想定外になるのを防ぎます。次を記録します。

• アセット、画像、API、国際向けホスト、旧エイリアスを含む、すべての公開ホスト名
• A、AAAA、CNAME、NS、SOA、CAA、MX、TXT、関連するSRVレコード
• 証明書の発行者、検証方法、Subject Alternative Names、有効期限
• オリジンのアドレス、ポート、ヘルスチェック、ロードバランサー、フェイルオーバー動作
• CDNのキャッシュキー、キャッシュルール、リダイレクト、変換、Worker、パージ方法
• WAF、ボット、レート制限、地域、認証、IP許可・拒否ルール
• レスポンスヘッダー、圧縮、Cookie動作、セキュリティヘッダー
• ログの送信先、保持期間、サンプリング、フィールド、タイムゾーン
• Search Consoleとアナリティクスの確認方法
• 第三者コールバック、Webhook、決済フロー、フィード、許可リストIP

DNSレビューにはWeb以外のレコードも含める必要があります。MX、SPF、DKIM、DMARC、サービスレコードの破損は、ランキングを直接変えなくても、守ろうとしていた事業そのものを止める可能性があります。

レスポンスパリティの基準を確立する

レスポンスパリティとは、同じリクエストURLについて旧システムと新システムを比較することであり、両方が200を返すことだけを確認するものではありません。

テンプレートと動作を横断する代表的なサンプルを取得します。

• ステータスとリダイレクトチェーン
• 最終URLとプロトコルネゴシエーション
• title、canonical、robotsディレクティブ、hreflang、構造化データ
• 生HTMLとブラウザーでレンダリングされたメインコンテンツ
• Content-Type、Cache-Control、Vary、圧縮、セキュリティヘッダー
• 画像、フォント、JavaScript、CSS、PDF、メディアアセット
• Cookieとログイン済みまたはパーソナライズされた派生レスポンス
• モバイルとデスクトップの動作
• レイテンシ、Time to First Byte、エラー率

対応するページの確認にはStaging vs. Production SEO Diffを使います。より大きな対象範囲は、完全なクローラーとスクリプト化したリクエスト群で確認します。

新しいオリジンを準備する

オリジンの準備は、コンテンツと設定のパリティから始まります。現在のコンテンツ、テンプレート、メディア、robotsルール、リダイレクト、エラー処理、確認用ファイルをコピーします。新しいデータベースが古い状態でローンチしないよう、書き込みを凍結または同期します。

制御されたホスト名、ローカルのhostsファイル上書き、またはプロバイダー固有のプレビュー機構を使い、オリジンを直接テストします。仮想ホスト、アプリケーションルーティング、証明書、canonical、絶対リンクは本番Hostヘッダーに依存することが多いため、テストでもそれを維持します。

新しいオリジンは切り替え後の負荷にも耐える必要があります。アプリケーションとデータベースをウォームアップし、接続プールとオートスケーリングを確認し、キャッシュされていない需要で負荷テストします。ローンチ直後のCDNキャッシュミスは、トラフィックをオリジンへ集中させる可能性があります。

CDNを独立したシステムとして設定する

CDN移行で変わるのは配信地域だけではありません。旧エッジと新エッジの動作を明示的に比較します。

• クエリ文字列、Cookie、ヘッダー、デバイス別派生を含むキャッシュキーの構成
• キャッシュ可能なステータスコードとファイル種類
• ブラウザーTTL、エッジTTL、古い応答の配信、再検証、オリジンシールド
• リダイレクト、リライト、ヘッダー変換、エッジ関数
• アカウント、カート、検索、パーソナライズページのキャッシュ除外ルール
• 圧縮と画像最適化
• パージの範囲と伝播
• WAF、ボット管理、レート制限、オリジン保護

たとえば、Cloudflareの現行ドキュメントでは、デフォルトのキャッシュがオリジンのCache-Controlヘッダーに従う場合がある一方、エッジルールで上書きできると説明しています。また、新しいオリジン取得を強制する対象指定または全体パージも提供しています。正確な動作はベンダーごとに異なるため、似たラベルが同じ結果を意味すると仮定せず、設定をエクスポートして比較してください。Cloudflareのキャッシュドキュメント も参照してください。

キャッシュパリティをコンテンツパリティとして扱う

キャッシュ設定は、誤ったページを正しく高速に配信してしまうことがあります。匿名、認証済み、ローカライズ、モバイル、クエリ文字列付きの各派生をテストします。意味のあるCookieやヘッダーを省いたキャッシュキーは、個人向けコンテンツを漏えいさせる可能性があります。すべてのトラッキングパラメーターを含むキーはキャッシュを細分化し、オリジンを過負荷にする可能性があります。

ローンチ計画に従って、重要なアセットとページをパージまたは事前ウォームアップします。キャッシュミスの集中にオリジンが耐えられると確認していない限り、ピークトラフィック時に無条件で全パージしてはいけません。

利用者からエッジ、エッジからオリジンまでTLSを検証する

CDNがHTTPSを終端する場合、TLS検証にはブラウザーからCDN、CDNからオリジンという2区間があります。ホスト名の対象範囲、完全な証明書チェーン、最新プロトコルの対応、更新、厳格なオリジン検証を確認します。

オリジン専用証明書は、一般に信頼されていない場合があります。Cloudflareは、プロキシを無効化または一時停止すると、Origin CA証明書によってブラウザーの信頼エラーが発生し得ると警告しています。これはロールバック時に重要です。エッジ専用の信頼モデルを使うオリジンへDNSだけで戻すと、利用者には失敗する可能性があります。Cloudflare Origin CAのガイダンス を参照してください。

ワイルドカードの想定や、ほとんど使われないアセット・地域向けホストを含め、すべての公開ホスト名をテストします。apexの証明書が有効でも、全サブドメインを対象にしている証明にはなりません。

移行前にDNS TTLを下げる

TTLの計画は切り替え前に始めます。Googleは、移行の少なくとも1週間前に、関連するTTLを数時間などの控えめな短い値へ下げるよう推奨しています。DNSプロバイダーによって最小値が異なる場合があり、プロキシされたレコードは固定値の場合もあります。

CloudflareのTTLドキュメント は基本的なトレードオフを説明しています。長い値はキャッシュの再利用を増やし、短い値はレコード変更を早く反映させます。元のTTLを記録し、新しいインフラの安定後にだけ復元する予定を立てます。

分散システム全体では、DNS変更が同時に反映されない場合があります。切り替え時の変更を最小限にし、複数の公開リゾルバーから応答を確認し、キャッシュされた応答が有効な間は旧宛先を利用可能に保ちます。

クローラーアクセスとセキュリティ制御を検証する

セキュリティのパリティはルール数のパリティではありません。別プロバイダーからコピーしたWAFは、クローラーへのチャレンジやブロック、クエリパラメーターの除去、レスポンスの書き換え、大量クロールへの異なるレート制限を行う可能性があります。

Googleのホスティングガイドは、ファイアウォールやサービス拒否攻撃対策によって、DNSサーバーまたはホスティングサーバーへのGooglebotアクセスを妨げないよう求めています。ユーザーエージェント文字列だけではなく、Googleの文書化された確認方法 でGooglebotを検証してください。

通常のクローラー動作と正当なアクセス急増の両方をテストします。偽装ユーザーエージェントへの保護まで無効にする広範な許可リストは避けます。ブロックされたリクエストとオリジン障害を区別できるよう、セキュリティログを保持します。

二重稼働を計画する

二重稼働とは、DNS伝播中に旧新両方のインフラが正しい本番レスポンスを配信できる状態です。旧環境にも、サイトへ影響するコンテンツやデータの変更を反映し続ける必要があります。そうしなければ、キャッシュされたDNS応答で旧環境へ送られた利用者に、古い在庫、壊れたセッション、更新前のページが表示される可能性があります。

同期戦略を選びます。

• 両スタックで共有する1つの読み書き用データベース
• 遅延と競合ポリシーを把握したデータレプリケーション
• 切り替え中の制御されたコンテンツ凍結
• 注文、フォーム、利用者の書き込みを対象とする一方向イベントレプリケーション

セッション状態、アップロード、キャッシュ無効化、バックグラウンドジョブについても同じ判断が必要です。状態が分岐するなら、“Both servers are on” (翻訳)「両方のサーバーが稼働している」だけでは二重稼働計画になりません。

切り替えを実行する

ホスティングの切り替えは、意図的に平穏な作業にします。

1. 無関係なデプロイを止め、変更時間帯を確認する。
2. 最終のパリティ、証明書、容量、バックアップの確認を行う。
3. 新しい本番経路から一時的なクロール・アクセス制限を外す。
4. 計画したDNSまたはCDNのルーティングレコードだけを変更する。
5. 複数のリゾルバーから想定どおりの応答を確認する。
6. 利用者とクローラーとして、公開経路から保護対象ページをリクエストする。
7. エッジ、新オリジン、旧オリジンのログが届いていることを確認する。
8. エラー、レイテンシ、キャッシュミス、オリジン負荷、コンバージョンを監視する。

ホストだけを移す場合、GoogleのChange of Addressツールは使いません。公開URLは変わっていないため、報告するアドレス変更がありません。

移行を証明する証拠を監視する

インフラ監視では旧トラフィックと新トラフィックを分けます。デプロイマーカーを使い、季節性が重要な場合は同じ曜日・時間帯の基準と比較します。

監視項目：

• DNS応答とリゾルバーへの伝播
• 利用者と検証済みクローラーによる旧ホスト・新ホストへのリクエスト
• エッジとオリジンのステータスコード分布
• TLS、接続、タイムアウト、アプリケーションのエラー
• レイテンシのパーセンタイルと、キャッシュされていないオリジン応答時間
• キャッシュヒット率とオリジンへのリクエスト量
• Googlebotリクエスト、Crawl Stats、Page Indexing、代表URLのURL Inspection
• 複数の地域・ネットワークからの合成監視
• アナリティクス、コンバージョン、重要な事業取引

Googleによると、ホスティング変更直後にGooglebotのクロール率が一時的に低下し、その後数日で増加するのは正常な場合があります。その想定パターンだけではなく、アクセス可能性とエラーの証拠に基づいて判断してください。

ローンチ前にロールバック手順を定める

ロールバックは、ルーティングを既知の正常なインフラ状態へ戻すことです。“switch DNS back.” (翻訳)「DNSを元へ戻す」という曖昧な約束ではありません。次を文書化します。

• 復元する正確なレコード、経路、設定
• 反転を承認し実行できる担当者
• 変更されたコンテンツ、セッション、フォーム、注文、アップロードの整合方法
• 旧証明書と依存関係がまだ有効か
• 両経路のキャッシュパージ手順
• ロールバックを起動する障害しきい値
• 安全に判断できる最長時間

ロールバックの条件は観測可能でなければなりません。継続的な可用性障害、重大なコンバージョン障害、広範囲への誤ったコンテンツ配信、証明書障害、クローラーのブロック、または所定の時間内に解消できない深刻な処理能力不足が該当します。一時的なクロール率の変動だけでは、ロールバック条件になりません。

暦ではなくログに基づいて旧インフラを廃止する

旧ホストの廃止は、利用者とクローラーが届かなくなり、依存サービスがすべて移行したとログで確認してから行います。Googleは、旧ホストのトラフィックがゼロになってから停止するよう推奨しています。

設定のエクスポート、ログ、ロールバック用成果物は、事業要件に従って保持します。安定を確認してから、DNS TTLを定常時の値へ戻します。一時的なファイアウォール例外と重複した定期ジョブを削除し、移行後に恒久的な保守上の混乱を残さないようにします。

AI要約

• ホスティング移行では、公開URLを同一に保ったまま、サーバー、CDN、オリジン、DNSを変更します。
• URLも変わる場合は、より広いサイト移転プロセスが必要です。ホストだけを移す場合、新しいリダイレクトマップやChange of Addressの申請は不要です。
• ローンチ前に、DNS、TLS、オリジン、CDN、WAF、キャッシュ、ログ、確認方法、アセット、事業上の依存関係を棚卸しします。
• 切り替え前にDNS TTLを下げ、元の値を保持し、新しい経路が安定してから復元します。
• 旧新の生レスポンス、レンダリング済みページ、ヘッダー、アセット、リダイレクト、ステータスコード、レイテンシ、事業上の動作を比較します。
• ブラウザーからエッジ、エッジからオリジンのTLSと、ロールバック経路上の証明書を検証します。
• キャッシュされたDNS応答が旧スタックへトラフィックを送らなくなるまで、両環境を二重稼働し、書き込みを同期します。
• 両方のログ、DNS応答、エラー、オリジン負荷、キャッシュ動作、検証済みクローラーのアクセス、Search Console、コンバージョンを監視します。
• 旧ホストのログでトラフィックがゼロになったことを確認してから廃止します。

公式ドキュメント

Google

• Webホスティングの変更とSEO — 同一URLでの準備、DNS切り替え、監視、停止の手順を説明。
• URL変更を伴うサイト移転 — スキーム、ホスト名、パスも変わる場合に適用。
• Googlebotの確認 — 逆引き・正引きDNSと公開IPによる検証を説明。
• Crawl Statsレポート — Googlebotのリクエストとホスト可用性の監視に使用。

インフラ関連資料

• Cloudflare DNS TTL — TTLと伝播のトレードオフを説明。
• Cloudflare Cache — エッジキャッシュ、キャッシュルール、パージを説明。
• Cloudflare Origin CA — エッジからオリジンへの証明書と、ブラウザー信頼に関する制約を説明。

出典からの引用

• “This guide is only for migrations that don’t affect the user-visible URL.” (翻訳)「このガイドは、利用者に見えるURLへ影響しない移行だけを対象とします」— Google Search Central。ホスティングガイドの該当箇所
• 要約： Googleは、“Consider lowering the TTL to a conservative low value” (翻訳)「TTLを控えめな短い値へ下げることを検討する」、“Make sure it does not block Googlebot’s ability to reach the DNS” (翻訳)「GooglebotがDNSへ到達するのを妨げないよう確認する」、“normal to see a temporary drop in Googlebot’s crawl rate” (翻訳)「Googlebotのクロール率が一時的に下がるのは正常である」、“once the traffic to the old provider reaches zero” (翻訳)「旧プロバイダーへのトラフィックがゼロになった時点」と説明しています。TTLのガイダンス 、ファイアウォールのガイダンス 、クロール率のガイダンス 、停止のガイダンス を参照してください。

ホスティング移行チェックリスト

対象範囲と基準値

• 公開URLが変わらないことを確認した。
• Web、アセット、API、地域向けのすべてのホスト名を棚卸しした。
• DNS、CDN、WAF、キャッシュ、リダイレクト、TLS、オリジンの設定をエクスポートした。
• 代表的な生レスポンスとレンダリング済みレスポンスの基準を保存した。
• トラフィック、エラー、レイテンシ、クロール、インデックス、コンバージョンの基準を記録した。

新しいインフラ

• 現在のコンテンツ、メディア、リダイレクト、robotsルール、確認用ファイルを同期した。
• Hostヘッダーのルーティングと、すべての公開ホスト名をテストした。
• ブラウザーからエッジ、エッジからオリジンの証明書を検証した。
• キャッシュキー、除外条件、TTL、Cookie、変換、パージ動作を一致させた。
• WAF、ボット、レート制限、オリジンアクセスの動作を一致させた。
• キャッシュミス、アプリケーション依存関係、データベース容量を負荷テストした。
• エッジ、オリジン、アプリケーション、セキュリティのログが保持され、検索できることを確認した。

DNSとローンチ

• 移行前に関連するTTLを下げ、元の値を記録した。
• Web以外のレコード、DNSSEC、確認情報、サービス依存関係を維持した。
• 正確なルーティング変更とロールバックコマンドを文書化した。
• データ同期計画とともに、旧新インフラを稼働させた。
• 新しい本番経路から、一時的なクロール・アクセス制限をすべて外した。
• 独立した複数のリゾルバーからDNS応答を検証した。

ローンチ後

• 本番でステータス、コンテンツ、ヘッダー、レンダリング、アセット、リダイレクトを比較した。
• 利用者と検証済みクローラーがチャレンジやブロックを受けないことを確認した。
• 旧新ログ、エラー、レイテンシ、キャッシュミス、オリジン負荷、コンバージョンを監視した。
• Crawl Stats、Page Indexing、代表URLのURL Inspection結果を確認した。
• 安定を証明してから定常時のTTLを復元した。
• 旧ホストのトラフィックがゼロになってから廃止した。

5層パリティの枠組み

移行の状態モデル

準備済みとは、新スタックがパリティと負荷テストに合格した状態です。切り替え中は、DNS応答とリクエストが旧新へ分かれています。安定化中は、新スタックがほぼすべてのトラフィックを配信し、旧スタックも利用可能な状態です。完了とは、旧ホストのトラフィックがゼロになり、すべての依存関係を廃止または移管した状態です。

“DNS changed.” (翻訳)「DNSを変更した」時点でプロジェクト完了としてはいけません。それは切り替えの開始であり、移行の終了ではありません。

どの移行計画が適用されるか

ホスティング移行でよくある障害

一部の地域から旧ホストへ到達してしまう

考えられる原因： キャッシュされたDNS応答、リゾルバーの動作、または一貫して変更されていないレコード。修正： 権威応答を複数の公開リゾルバーと比較し、旧ホストでも現在のコンテンツを配信し続け、変更を繰り返すのではなくTTLを確認します。

ローンチ後にGooglebotのリクエストが減少する

考えられる原因： 通常の短期的なクロール率調整、ファイアウォールのチャレンジ、DNS障害、レイテンシ、サーバーエラー。修正： Crawl Statsと検証済みボットのアクセスログを確認します。Googleが文書化した短期的な低下は、実際のアクセス障害を無視する理由にはなりません。

ページは速いが、古いコンテンツが表示される

考えられる原因： エッジTTL、キャッシュキー、パージ失敗、または分岐したデータソース。修正： Age、Cache-Control、Vary、プロバイダーのキャッシュステータスヘッダーを確認し、意味のある派生をテストします。対象を絞ってパージし、オリジンとエッジを別々に検証します。

CDN経由では動作するが、バイパスすると失敗する

考えられる原因： オリジン証明書の信頼、Hostヘッダーのルーティング、ファイアウォールの許可リスト、または直接オリジン経路の依存関係不足。修正： 意図したエッジからオリジンへの経路と、文書化したロールバック経路を検証します。計画外のバイパステストを通すために、非公開オリジンを公開してはいけません。

HTMLは動くがアセットが失敗する

考えられる原因： 抜けているアセット用ホスト名、CORS、証明書、絶対URL、キャッシュルール、ホットリンク保護、オリジン権限。修正： フォント、画像、CSS、JavaScript、PDF、メディアを含むアセット一覧を、クローラーとブラウザーでテストします。

オリジン負荷が直後に急増する

考えられる原因： コールドキャッシュ、変更されたキャッシュキー、キャッシュのバイパス、シールド不足、またはオリジンへ直接届くボットトラフィック。修正： 意図したキャッシュルールを復元し、高価値オブジェクトを慎重にウォームアップし、容量を追加します。継続的な障害が合意したしきい値を超える場合はロールバックします。

同一URLのインフラ移行に使うツール

• DNS Checkerは、複数の公開リゾルバーで一般的なレコード種類を比較します。伝播中に使い、権威ゾーンの結果とも比較してください。
• HTTP Header Checkerは、CDNの痕跡、圧縮、セキュリティ、キャッシュ制御を含む、リダイレクト全体のヘッダーを表示します。
• Staging vs. Production SEO Diffは、対応URLのステータス、canonical、ディレクティブ、選択したヘッダー、schema、コンテンツを比較します。
• Bulk HTTP Status Code Checkerは、代表URL群のステータス、リダイレクト、宛先、レイテンシを確認します。
• Google Index Checkerは、観測可能なクロール・インデックス阻害要因を確認し、Google自身の見解を調べるためSearch Consoleへ案内します。
• サーバーとエッジのログは、トラフィックの行き先、受けたレスポンス、旧インフラが本当に使われなくなった時点を証明します。
• 合成監視は、複数のネットワークと地域から、公開可用性と重要なトランザクションをテストします。

ホスティング移行の成功を検証する

DNS伝播と旧ホストのドレインテスト

• 実行するテスト： 権威DNSと複数の公開リゾルバーへ問い合わせ、旧新インフラのリクエスト量をグラフ化する。
• 期待結果： 公開応答が意図した経路へ収束し、旧ホストのトラフィックがゼロまで減少する。
• 失敗の解釈： 一貫しないレコード、キャッシュ応答、または未追跡のホスト名が、別の場所へトラフィックを送り続けている。
• 監視期間： 切り替え開始から、切り替え前に設定されていた関連TTLのうち最も長い時間が経過し、さらに旧ホストのログがゼロのまま安定するまで。
• ロールバック条件： 重要な地域で名前解決または新サービスへの到達ができず、復旧時間内に修正できない。

レスポンスパリティテスト

• 実行するテスト： Staging vs. Production SEO Diff、クローラー、ブラウザーのレンダリングテストを使い、基準と本番を比較する。
• 期待結果： 意図したステータス、canonical、robotsルール、コンテンツ、構造化データ、内部リンク、アセット、ヘッダーが維持される。
• 失敗の解釈： URLは安定しているのに、新しいオリジン、エッジ、アプリケーション設定が検索から見えるレスポンスを変えている。
• 監視期間： 切り替え直前と直後、その後はローンチ修正のたび。
• ロールバック条件： サイト全体のインデックス可否、canonical、コンテンツ、アセットの障害が保護対象テンプレートへ影響し、安全に即時修正できない。

クローラーアクセスと容量のテスト

• 実行するテスト： 検証済みクローラーのログ、Search ConsoleのCrawl Stats、オリジンレイテンシ、エラー率、キャッシュなしの負荷テスト結果を確認する。
• 期待結果： 検証済みクローラーがチャレンジなしに正常なレスポンスを受け、オリジンは確立した容量範囲内に留まる。
• 失敗の解釈： WAF、DNS、TLS、レート制限、またはオリジン容量によって、安定したクロールが妨げられている。
• 監視期間： ローンチ中と、クロール率が安定する最初の数日間を通して継続。
• ロールバック条件： クローラーと利用者の継続的な障害が、承認済みのエラーまたは可用性しきい値を超える。

キャッシュ安全性テスト

• 実行するテスト： キャッシュキーとレスポンスヘッダーを確認しながら、匿名、認証済み、ローカライズ、モバイル、クエリ付きの派生をリクエストする。
• 期待結果： 公開コンテンツは設計どおりキャッシュされ、非公開またはパーソナライズされたレスポンスは共有されず、意味のある派生が区別される。
• 失敗の解釈： キャッシュキーまたは除外ルールによって、誤ったコンテンツが配信される、またはオリジンが過負荷になる可能性がある。
• 監視期間： ローンチ前、切り替え直後、キャッシュルールまたはパージの変更後。
• ロールバック条件： 個人向けデータが露出する、古いコンテンツが広範に配信される、またはオリジンがキャッシュミス率に耐えられない。

時間を使う価値のあるリソース

私の関連記事

• Webサイト移行の成功にはチェックリスト以上のものが必要 — 基準、ステージング、監視を含む、より広い移行プロセスを説明。
• SEOのためのリダイレクト — インフラ移行後も維持すべき旧リダイレクトの動作を説明。

このサイトの関連ガイド

• サイト移行 — 移行の分類と共通プロセスを説明。
• Webサイト移行チェックリスト — フェーズ別のプロジェクトチェックリスト。
• HTTPステータスコード — 維持し監視すべきレスポンス層を説明。

業界の関連資料

• Google：ホスティングの変更
• Google：Googlebotの確認
• Cloudflare：DNS TTL
• Cloudflare：DNSレコードの管理
• Cloudflare：キャッシュドキュメント
• Cloudflare：Origin CA
• Bing：IndexNow

理解度テスト：Webサイトのホスティング移行SEO

同一URLのインフラ移行の分類、ローンチ、検証に関する5問です。各問の答えを選び、結果を確認してください。

変更履歴