サイト移行時のベストプラクティス

サイト移行は、SEOにおいて最もリスクの高い施策の一つです。リダイレクトを1つ間違える、URLを1つ見落とす、連鎖（チェーン）を1つ見落とすだけで、順位・トラフィック・売上がするりと失われてしまうことがあります。朗報は？リスクは予測可能であり、適切なプロセスがあれば未然に防げるということです。

本ガイドでは、移行の前・最中・移行後にサイトを守るための実証済みのベストプラクティスを解説します。URLマッピングや301リダイレクトから、リリース後の監視、トラフィック分析までカバーします。

移行する前にURLマッピングを計画する#

完全なURLマップなしでサイト移行を行うことは、最も早く順位を失う方法です。DNSに触れる前、またはリダイレクトを1つもデプロイする前に、現在のサイト上のすべてのURLを記録し、新しいサイトのどこに着地させるべきかを決めてください。

まず、一般的なSEOクローラーを使って既存サイトを完全にクロールします。インデックスされているURLをすべてエクスポートしてください。各URLについて、最も関連性の高い新しい行き先にマッピングします。料金に関するページは、ホームページではなく新しい料金ページへリダイレクトすべきです。こうした不一致は、コンテンツが移転されたのではなく削除されたことを検索エンジンに示すサインになります。

URLマップには、構造化された形式を使ってください。ソースURL、デスティネーションURL、リダイレクト種別です。これによりマッピングが整理され、デプロイのタイミングで一括インポートが可能になります。RedirHub のようなプラットフォームでは、CSVのインポートを直接受け付けるため、移行マップをスプレッドシートから1ステップで実際のリダイレクトへ移行できます。

以下は、適切に構成されたURLマッピングの例です：

301リダイレクトを使用する——すべてのURLを、毎回#

301は恒久的な移動（パーマネントリダイレクト）に使うステータスコードの唯一のものです。コンテンツが移転したことを検索エンジンに伝え、新しいURLへリンクエクイティの大部分を引き渡します。302、メタリフレッシュ、JavaScriptリダイレクトなど、他のステータスコードは、古いURLが構築してきた順位シグナルを弱めるか、失わせます。

移行マップ内の各URLには、それぞれ独自の301リダイレクトが必要です。URLごとに1つのリダイレクト。チェーンは不可。すべてをホームページに投げてしまうワイルドカードのショートカットも不可です。olddomain.com/blog/ultimate-seo-guide が newdomain.com/blog/seo-guide にリダイレクトするなら、それで正解です。すべてが新しいドメインのトップに行ってしまうと、個々のページの文脈と順位価値が失われます。

公開後、リダイレクトの一部をテストしてください。リダイレクトチェッカーを使って、各リダイレクトが301を返し、正しい遷移先に着地し、1ホップで完了することを確認します。

初日から404を監視#

移行後は404が必ず発生しますが、早期に見つければ被害を最小限に抑えられます。移行済みURLで404に遭遇した検索エンジンは、コンテンツがなくなったと解釈します。404に到達したトラフィックは戻ってきません。

公開前に自動404監視を設定してください。新しいサイトで発生するすべての4xxレスポンスを追跡します。404が表示されたら、参照元URLを特定し、不足しているリダイレクトを追加してください。Search Consoleが数週間後に教えてくれるのを待たないでください。そうなる頃には、クロールデータと順位シグナルの影響がすでに出ています。

RedirHub のようなツールには、壊れたリダイレクトや404をリアルタイムで検知する「遷移先の健全性チェック」が含まれています。リダイレクト先がエラーを返した場合、次のレポートサイクルで見つけるのではなく、すぐに通知されます。

公開後は毎週トラフィックと順位を追跡#

移行後最初の4週間は、最もリスクが高い期間です。この間、検索エンジンはサイトを再クロールし、再インデックスし、評価し直しています。週次の監視により、問題が拡大する前に発見できます。

週次でオーガニックトラフィックを比較してください。サイトの一部が急激に落ちた場合、そのページに流れているリダイレクトを確認します。Google Search Consoleで、主要なランディングページの表示回数とクリック数を監視してください。以前は順位が良かったページで突然表示回数が下がった場合、検索エンジンがリダイレクトを追従できなかったか、404を見つけたことを意味することがよくあります。

クローラー比較を実行します。旧サイトと新サイトの両方をクロールし、旧URLが200レスポンスを返している（つまり旧サーバーがまだ稼働中）場合と、正しくリダイレクトしている場合を確認します。リダイレクトすべきなのにできていない旧URLは、早急に修正が必要です。

公開前にリダイレクトを検証する#

壊れたリダイレクトを発見する最悪のタイミングは、公開後です。公開前の検証なら、検索エンジンより先に、マッピングの誤り、チェーン、壊れた遷移先を見つけられます。

デプロイ前に、完全なURLマップを検証ツールに通してください。すべてのソースURLが301を返し、正しい遷移先を指し、1ホップで完了していることを確認します。複数ホップはリンクエクイティを薄め、クロール効率も低下させます。検索エンジンは直接的な経路を好みます。

RedirHubの検証は、インポート時に遷移先をチェックし、どのリダイレクトも公開される前に、壊れている／到達不能なURLをフラグします。これにより、検証を手作業のQAステップから自動の安全策へと変えます。

移行前のパフォーマンス基準値を維持する#

どこから始めたのかを知らなければ、何が変わったのかを測れません。移行当日より前に、基準となる指標を記録してください：

• セクション別のオーガニックトラフィック（ブログ、商品ページ、サポートなど）
• トラフィック上位20のランディングページ
• コンバージョン上位20のランディングページ
• 主要ページの平均ページ読み込み時間
• 現在の404件数

これらの数値をどこか参照できる場所に保存してください。移行後は、同じ指標で比較します。特定のセクションでトラフィックが落ちた場合、基準値が「リダイレクトの問題」「コンテンツ不足」「インデックス遅延」のどれに当たるかを判断する手がかりになります。

リダイレクトチェーンを直ちに修正#

リダイレクトチェーンとは、URL AがBへリダイレクトし、さらにBがCへリダイレクトし、最終的にDに着地する状態のことです。各ホップごとにユーザーの待ち時間が増え、検索エンジンのクロール予算を無駄にします。Googleは可能な限り、リダイレクトを1ホップに保つことを推奨しています。

移行用リダイレクトをデプロイしたら、チェーンがないか監査してください。Screaming Frogのようなツールや、組み込みのプラットフォームバリデーターで、複数の宛先を経由しているURLを特定できます。各チェーンをフラット化し、ソースURLが最終的な宛先を直接指すようにします。

これは特に、複数のドメイン変更やCMS移行など、複雑な移行で重要になります。ステージングURLへのドメインリダイレクトが、その後ライブURLへリダイレクトする場合、2ホップのチェーンが発生し、これは単一の301にすべきです。

ここで専用のプラットフォームが違いを生みます。RedirHubはリダイレクトチェーンをバックグラウンドで継続監視し、チームが新しいWebサイトを更新している最中でも、新しいチェーンが形成されると自動的にフラグを立てます。手動のクロールを実行したり、コンテンツ変更のたびにログを確認したりする必要はありません。監視は継続的に行われ、チェーンが発生したら通知するため、ランキングに影響が出る前にフラット化できます。

このバックグラウンド監視により、チームは壊れたリダイレクト経路を心配することなく、新しいサイトの更新、公開、再構築を続けられます。何かが壊れたらすぐに分かるので、すべての変更を事前に監査する必要はありません。

移行管理のために設計されたプラットフォームを利用する#

スプレッドシートは計画に最適です。サーバー設定ファイルは実行にはあまり向きません。集中型のリダイレクト基盤なら、1か所で制御・検証・監視を行えます。

RedirHubはまさにこのワークフローのために作られました。URLマップの一括CSVインポート、すべてのリダイレクトに対する公開前検証、そしてリアルタイムの到達先ヘルスチェックによる公開後の監視です。単一のダッシュボードで移行ライフサイクル全体を管理できるため、.htaccessファイル、サーバールール、手動テストを行ったり来たりする必要がありません。手順を追って確認するには、Webサイト移行ガイドをご覧ください。

基本機能には2,500件の管理リンクが含まれており、多くの小規模〜中規模の移行をカバーします。14日間の無料トライアルで、まずリダイレクトマップをテストできます。ProおよびEnterpriseでは、より多くの容量、詳細な分析、チーム管理など、大規模な移行に対応する機能が追加されます。

古いリダイレクトを少なくとも12か月間有効に保つ#

検索エンジンは、移行後すぐに古いURLのクロールを止めるわけではありません。外部被リンク、キャッシュされたページ、ブックマークは、移行の数か月〜数年後も古いURLを指し続けます。リダイレクトを早すぎるタイミングで削除すると、保存できたはずのトラフィックに対して404を返すことになります。

リダイレクトルールは最低12か月間そのまま維持してください。多くのSEO担当者は、無期限で維持することを推奨しています。リダイレクトを維持することによるデメリットはありません。唯一のリスクは、早すぎるタイミングで削除してしまうことです。

時間の経過とともにリダイレクトの利用状況を監視します。特定のリダイレクトへのトラフィックが、数か月にわたってほぼゼロまで落ちているのを確認したら、クリーンアップしてよいという合理的なサインになります。それまでは有効のままにしておきましょう。

移行後のトラフィック分析を30日目と90日目に実施する#

移行後1週間のデータはノイズです。30日目まで待てば、何がうまくいったか、何を調整する必要があるかを評価するのに十分なシグナルが得られます。90日目では、インデックス状況の全体像は概ね安定しています。

30日目に、移行後のトラフィックをベースラインと比較します。移行前に追跡していたのと同じセクションやランディングページを見てください。あるセクションが完全に回復している一方で別のセクションがベースラインを下回っている場合、そのセクションに流入しているリダイレクトを調査します。

90日経過後も同じ比較を行いましょう。この時点では、多くの検索エンジンが再クロールを完了しています。なお、トラフィックのギャップが継続している場合は、構造的な問題（リダイレクトの欠落、コンテンツの不足、技術的なエラーなど）が原因である可能性が高く、対応が必要です。

RedirHubのようなプラットフォームには、リダイレクトのパフォーマンスを時系列で確認できる分析機能があります。どのリダイレクトがトラフィックを配信しているか、どれがエラーを発生させているか、移行後にボリュームがどう推移しているかまで把握できます。月次レポートを待つのではなく、リアルタイムの状況が見えるのです。

結論#

サイト移行は、順位やトラフィックを失うことにつながる必要はありません。適切なURLマッピング、検証済みの301リダイレクト、そして継続的な監視があれば、これまでに築いたものを失わずにサイトを移行できます。成功する移行と失敗する移行の違いは、たいてい準備と、実行に使うツールにあります。

マップを設計します。301でデプロイします。404を監視します。チェーンを修正します。リダイレクトを稼働させ続けます。そして、ライフサイクルを管理してくれるプラットフォームを使い、仕組みではなく結果に集中できるようにしましょう。