3年前のことですが、既にライブになっている移行案件を引き継がされました。ステージング環境もない。リダイレクトマップもない。22,000ページのeコマースカタログを、誰かが新しいドメインに単に向け直して「完了」と言ってしまった状態でした。オーガニックトラフィックは6週間で74%低下しました。クライアントから慌てた電話をもらい、それから4ヶ月以上かかって対応することになりました。
重要なポイント：サイト移行でランキングを失うのはプラットフォーム変更ではなくリダイレクト監査の見落としが原因です。チェックリストはリダイレクトマップ、メタデータ転送、スキーマの継続性、本番後の検証で構成されています。
その経験は痛かったですが、基本的にこのチェックリストが存在する理由です。それ以来、800ページのパンフレットサイトから地域サブドメイン付きの31,000ページのパブリッシャーまで、様々なサイトを移行させてきました。基本原則は毎回同じです。順序を間違えたり、1ステップをスキップしたりすると、Google は Search Console で最も不快な方法で報告します。
では、ここです。Seahawk Mediaで私が実際に使っているチェックリスト。理論的なフレームワークではなく、本当のものです。
---
1. 何かに手を入れる前に 完全なクロールから開始する
当たり前？もちろん。スキップされている？常に。
ファイルが1つ動く前に、Screaming Frog SEO Spider を使ってライブサイト全体をクロールします。20,000ページのサイトでは数時間かかるため、通常はクロールをデータベースモードで保存し、メモリの問題が発生しないようにして、夜間に実行します。キャプチャしている内容:
- すべてのインデックス可能なURL（ペジネーションノイズではなく、正規版）
- 200、301、302、404など、全体的なレスポンスコード
- 既存の内部リンク構造
- Canonicalタグ、該当する場合はhreflang属性
- ページタイトルとメタディスクリプション（マイグレーション後も残ることを確認するため）
クロール全体をCSVにエクスポートして保管します。これが基準です。新しいサイトがライブになった3週間後に比較するドキュメントです。
多くの人がこのステップをスキップします。「私たちはすでにサイトを知っている」からです。あなたは知りません。2021年、旅行クライアントのサイトを知っていると思っていましたが、実は誰も簡潔に説明していなかったレガシーCMSサブディレクトリから配信されていた4,000のURLがありました。クロールで見つけました。災難になっていたでしょう。
Googleのデータを忘れずに
Google Search Console からすべてを取得します。最低でも16ヶ月分のパフォーマンスデータ、インデックスカバレッジレポート、手動対策、すべてのサイトマップです。Google Analytics (現在は GA4 です) からも取得して、何か変わる前にオーガニックトラフィックのベンチマークを固めておきます。スクリーンショットでも問題ありませんが、生CSVもエクスポートしています。
---
2. リダイレクトマップを構築する。その後、もう一度確認する。
ここで移行は成功するか失敗するか決まります。大規模サイトでは、リダイレクトマップは実際のスプレッドシートで、通常はクライアント、そのdev チーム、夜11時に誤って数式を上書きするかもしれない誰かと共有されています。
構造はシンプルです：
- Column A：旧URL（末尾のスラッシュの有無を含めた完全一致）
- Column B：新URL（完全一致）
- Column C：リダイレクトタイプ（ほぼすべてのケースで301）
- Column D：ステータス（マップ済み、確認済み、ライブ）
- Column E：メモ（キャッチオールリダイレクト、カテゴリ統合、意図的な削除）
20,000ページのサイトでは当然のことながら全URLを個別にマップすることはできません。私が実施する順序はこうです：
- トップパフォーマンスのURL を最初にマップします (GSC のオーガニックトラフィック順、トップ500は通常80%以上のトラフィックを占めます)
- カテゴリーおよびタクソノミーページをマップする
- 意味のあるバックリンクを持つURL をすべてマップします (Ahrefs を使用します。参照ドメインでフィルタリングします。生リンク数だけではなく)
- その他すべてに対してパターンベースのリダイレクトを処理する（例：/product/old-slug/→/shop/old-slug/）
- リタイアするページの意図的な410を文書化する
パターンベースのリダイレクトは、ジュニア開発者が間違えやすい点です。ワイルドカードルールを広すぎるように書いて、リダイレクトするつもりのないURLを誤って飲み込んでしまいます。本番環境に近づける前に、ステージング環境ですべてのパターンルールをテストしてください。
---
3. ステージング環境は必須です
これを短く記しますが、説明が特に必要ではないはずです。すべてのマイグレーションはステージング環境を備えます。以上です。
Seahawk の2022年のフィンテッククライアントがこれに反発しました。「サイトが小さいから本番環境でやるだけだ」と言いたかった。そのサイトは6,000ページでした。ステージング環境で実施しました。すべての商品ページから正規タグをストリップしていたプラグインの競合を見つけました。Google が再度クロールするまで目に見えなかったでしょう。低権威ドメインでは数週間かかることがあります。
ステージング環境では以下をチェックしています：
- すべてのリダイレクトが正しく動作する（Screaming Frog をステージングに向けて使用し、リダイレクトマップを一括検証）
- robots.txtがステージング環境のインデックスをブロックしている（重要：Disallow: /を使用し、さらにnoindexヘッダーも追加してダブルプロテクションを実施）
- 新しいサイトマップが正確で、ステージング URL を含まない
- Canonical タグが正しい本番環境 URL を指している
- PageSpeed Insightsでページ速度のベースラインを設定し、マイグレーションは多くの場合リデザイン機会として利用されていますが、リデザインはCore Web Vitalsを頻繁に破壊します
---
4. Go-Live シーケンス（順序があなたが思っているより重要）
ここが人々が自由奔放に行動して自分たちに問題を引き起こす部分です。特定の順序があります。私はそこから外れません。
ステップ1：プリローンチ（48時間前）
- すべてのDNSレコードのTTLを300秒（5分）に短縮する。プロパゲーション速度が大幅に向上する。
- クライアントに通知：マイグレーションウィンドウ中はコンテンツ変更、新規ページ追加、プラグイン更新は禁止。
- CDN、広告プラットフォーム、モニタリングツールなどのサードパーティ統合に今回の変更を事前通知する。
ステップ2：ローンチウィンドウ
- DNSを更新する
- 新しいコンテンツが完全に伝播する前にリダイレクトをデプロイすること、リダイレクトはWordPressではなくサーバーレベルで稼働している必要があります
- 新しいサイトマップを有効にし、古いものを無効にする
- robots.txtが正しいことを確認する（ステージング版ではなく本番ファイル）
ステップ3：ローンチ直後
- 新しいサイトを2時間以内にクロールします。Screaming Frogを本番環境に向けて実行し、リダイレクトを尊重します。予期しない404、2ホップを超えるリダイレクトチェーン、インデックス可能であるべきなのにnoindexタグを表示しているページを探しています。
- Search Consoleで新しいサイトマップを送信します。
- GSCのURL検査ツールでホームページを取得し、Googlebotの訪問を促します。
クライアントに常にフラグを立てることは１つあります：Googleは検索結果に新しいURLを即座に反映しません。クロールと再処理にはラグがあります。大規模サイトの場合、明確な状況が把握できるまでに2～6週間を予算化してください。4日目にランキングが変動したからといってパニックに陥るのは普通のことで、何か壊れているわけではありません。
---
5. リダイレクトチェーン監査（ほとんどの代理店が別途請求するステップ）
リダイレクトチェーンは遅い流出です。A → B → C → D というURLは、Googlebotに余分な作業をさせており、複数のホップ全体でリンク エクイティも希釈されています。複数回の以前の移行またはプラットフォーム切り替えを経たサイトでは、チェーンが想像外に深くなることがあります。
ローンチ後、Screaming Frogの完全なクロール結果をエクスポートしてリダイレクトチェーンをフィルタリングします。2ホップを超えるものはすべて統合します。元のURLがリダイレクトマップにあった場合は、最終的な宛先を直接指すように更新します。誰も文書化していない移行からのレガシーチェーンだった場合は、追加します。
クライアントをMagentoからWooCommerceにマイグレーションした2023年初頭のケースでは、このステップだけで2日かかりました。彼らは8年間で3回のマイグレーションを経験していたのです。一部のURLは正しいページにたどり着く前に5つのリダイレクトを経由していました。すべて削除したところ、Search Consoleのクロールバジェット指標が1ヶ月以内に顕著に改善しました。
---
6. 大規模なコンテンツ検証
20,000ページを手動でレビューすることはできません。しかし、重要な部分を体系的に検証することはできます。
ローンチ後の最初の2週間でチェックしていることは以下の通りです:
- タイトルタグとメタディスクリプション: ランダムに選んだ200ページのサンプルをマイグレーション前のScreaming Frogエクスポートと比較します。不一致はすぐにフラグを立てます。
- 構造化データ:商品ページ、記事ページ、ホームページのサンプルをGoogle Rich Results Testに実行します。マイグレーションはスキーママークアップを壊すことが多く、特に新しいテーマが別のプラグインを使用する場合はそうです。
- 内部リンク: Screaming Frogクロール、インリンクでフィルター。高価値ページは依然として強い内部リンク数を持つべきです。以前400の内部リンクを持っていたカテゴリーページが現在12しかない場合、テンプレートで何か問題が起きています。
- 画像と代替テキスト: SEOの観点から厳密に重要ではありませんが、壊れた画像はユーザーエクスペリエンスシグナルを損ない、テンプレートサイトでは見落としやすいです。
---
7. マイグレーション後90日間のモニタリング
マイグレーションはgo-liveの日に終わるわけではありません。最低でも90日間継続します。
初月は週次レポーティングのリズムをクライアントと設定し、その後は隔週にしました。監視している項目は以下の通りです：
- GSC インデックスカバレッジ：インデックスされたページ数がマイグレーション前のカウントに向かって回復しているか。3週間を超えて続く大幅な低下は調査が必要です。
- オーガニックトラフィック対ベースライン：ランディングページタイプ別（商品、カテゴリー、ブログ）にセグメント化。トラフィック低下は往々にして不均等で、カテゴリーページが急落しても商品ページが維持されることもあります。
- クロールバジェット：GSC のクロール統計レポートは、1日あたりのクロール平均ページ数とサーバーレスポンスタイムを表示します。Googlebot が大量の 404 にヒットしている場合、ここに現れます。
- ランキングポジションの追跡：Ahrefs のランク追跡と Google Search Console のパフォーマンスレポートの組み合わせを使用しています。最初の2～3週間のランキング変動は一般的であり、必ずしも問題ではありません。4週間を超えて続く低下は対応が必要です。
- バックリンクプロフィール：Ahrefs を使用して、旧 URL を指す高価値バックリンクが既に正しくリダイレクトされているか、または更新のためのアウトリーチ対象としてフラグを立てるかを確認します。
正直なところ、ほとんどのマイグレーション SEO の問題は、正しいメトリクスを監視していれば30日以内に検出可能です。人々に悪影響を与えるのは、監視をセットアップせず、クライアントが8カ月後に気づくというケースです。
---
8. 私が犯した間違い（あなたが同じ過ちをしないために）
2019年に遡ると、UK、オーストラリア、カナダのサブフォルダを持つクライアントのマイグレーションでhreflang実装を見落としました。canonicalタグは正しく、リダイレクトも問題ありませんでした。しかし新しいサイトのhreflangアノテーションに誤ったリージョンコードが指定されていました。en-auではなくen-AU（一部の実装ではケースが重要らしい）です。Googleがオーストラリアの検索者にUKページを提供し始めました。オーストラリアのオーガニックトラフィックが半減した理由を解明するのに6週間かかりました。それ以来、国際マイグレーションのたびにhreflang検証ステップを追加しています。
もう1つ：noindexされたURLを含むXMLサイトマップ。軽微な矛盾に見えるかもしれませんが、矛盾したシグナルを送信するため、クリーンアップする価値があります。Screaming Frogはサイトマップを監査して、noindexタグを返すサイトマップ内のURLをすべてフラグできます。
おそらく最も高い代償を払った教訓：ロールバック計画がないこと。マイグレーションが失敗しかけている場合、1時間以内にDNSを古いサーバーに戻す能力は何物にも代えがたい価値があります。私は常に、マイグレーション後少なくとも30日間は旧環境をライブで無傷の状態に保つよう主張します。クライアントはホスティングコストについて文句を言うことがあります。私が70%のトラフィック低下が収益にもたらすコストを説明すると、文句を言わなくなります。
---
FAQ
20,000ページのサイトマイグレーションの計画には実際のところどのくらい時間がかかりますか？
現実的には、ゴーライブ日の前に6～10週間の準備期間が必要です。そのサイズのリダイレクトマップだけでも、特にすべてのURLのバックリンクを監査する場合、適切に構築するのに2～3週間かかることがあります。準備を急ぐと、数ヶ月のリカバリーに費やすことになります。
マイグレーション後にサーチコンソール（GSC）の無視ファイルを送信する必要がありますか？
通常は不要です。ただし、旧ドメインに有害なリンクがあり、特にそれから逃れるためにマイグレーションしている場合は別です。新しいドメインにマイグレーションして、クリーンなリンクプロフィールを希望する場合は、新しいプロパティのGSCで無視を処理してください。ただし、ほとんどのプラットフォームまたは同じドメイン上のリデザインマイグレーションでは、無視は関係ありません。
大規模なマイグレーションでエージェンシーが最もよく犯す間違いは何ですか？
リダイレクトマップをdev業務として扱うこと。リダイレクトはSEO業務であり、開発者が実装するものです。SEOチーム、または検索戦略を担当する者がマップを所有し、レビューして承認すべきです。どのURLバリアントがカノニカルであるかを開発者に伝えなかったために、技術的には正しいが SEO的には間違ったリダイレクトルールを構築した例を見てきました。
サイトの速度はマイグレーションのSEOに影響を与えるか？
ほとんどの人が考慮するよりも、はるかに多くあります。Core Web Vitalsはランキング要因であり、マイグレーションに伴うリデザインは、しばしば重いJavaScriptまたは最適化されていない画像を導入します。本番環境にデプロイする前に、必ずPageSpeed Insightsで旧サイトと新サイトを比較してください。新しいサイトがモバイルで著しく遅い場合は、切り替え前に修正してください。
ユーザー生成コンテンツが大量にあるサイトのマイグレーションにはどう対処しますか？
慎重に対処します。UGCページは個別には低品質なことが多いですが、集合的にはロングテールトラフィックを生み出します。クロールと分析のステップを推奨するのが通常です。つまり、オーガニックトラフィックがあるUGC URLを特定し、それらだけをリダイレクトして、残りは404ではなく410で返します。410はGoogleに対してページが意図的に削除されたことを示し、404は曖昧です。
---
マイグレーションは、良好と壊滅的の違いがほぼ完全に準備段階にあるものの１つです。技術実装は通常簡単な部分です。本番前の作業、クロール、リダイレクトマップ、ステージング検証を正しく実施することが、実際の作業が起こる場所です。マイグレーションが既に本番環境にあり、既に壊れている状態で引き継ぐ場合でも、チェックリストは適用されます。逆順で実施するだけです。