3年前のことですが、既にライブになっている移行案件を引き継がされました。ステージング環境もない。リダイレクトマップもない。22,000ページのeコマースカタログを、誰かが新しいドメインに単に向け直して「完了」と言ってしまった状態でした。オーガニックトラフィックは6週間で74%低下しました。クライアントから慌てた電話をもらい、それから4ヶ月以上かかって対応することになりました。
重要なポイント：サイト移行でランキングを失うのはプラットフォーム変更ではなくリダイレクト監査の見落としが原因です。チェックリストはリダイレクトマップ、メタデータ転送、スキーマの継続性、本番後の検証で構成されています。Site migrations lose rankings through skipped redirect audits, not platform changes; the checklist is redirect map, metadata transport, schema continuity, and post-launch verification.
その経験──つらかったですが──基本的にこのチェックリストが存在する理由です。それ以来、800ページのパンフレット程度のサイトから地域別サブドメイン付きの31,000ページのパブリッシャーまで、様々なサイトを移行してきましたが、基本は毎回同じです。順序を間違えるか、1つのステップをスキップすると、Googleはそのことを最も不快な方法でSearch Consoleから教えてくれます。
では、ここです。Seahawk Mediaで私が実際に使っているチェックリスト。理論的なフレームワークではなく、本当のものです。Seahawk Media, not a theoretical framework.
---
1. 何かに手を入れる前に 完全なクロールから開始する
当たり前？もちろん。スキップされている？常に。
ファイルが1つ動く前に、Screaming Frog SEO Spiderでライブサイト全体をクロールします。20,000ページのサイトではこれに数時間かかります──通常、メモリが問題にならないようにクロールをデータベースモードで保存して、一晩中実行します。キャプチャしているもの：Screaming Frog SEO Spider. On a 20,000-page site this takes a couple of hours -- I usually kick it off overnight with the crawl stored to database mode so memory doesn't become an issue. What I'm capturing:
- すべてのインデックス可能なURL（ペジネーションノイズではなく、正規版）
- 全体的なレスポンスコード──200、301、302、404など、すべて
- 既存の内部リンク構造
- Canonicalタグ、該当する場合はhreflang属性
- ページタイトルとメタディスクリプション（マイグレーション後も残ることを確認するため）
クロール全体をCSVにエクスポートして保管します。これが基準です。新しいサイトがライブになった3週間後に比較するドキュメントです。
多くの人がこのステップをスキップします──「私たちは既にサイトを知っている」ということで。知りません。2021年に旅行クライアントのサイトを知っていると思っていました──実は、ブリーフで誰も言及していなかったレガシーCMSサブディレクトリから配信されていた4,000個のURLがありました。クロールで発見しました。災害になっていたでしょう。
Googleのデータを忘れずに
Google Search Consoleから全て取得してください──最低でも過去16ヶ月間のパフォーマンスデータ、インデックスカバレッジレポート、手動アクション、すべてのサイトマップ。Google Analytics（今はGA4）からも取得して、何かが変わる前に有機トラフィックのベンチマークをロックダウンしてください。スクリーンショットで大丈夫です。生CSVもエクスポートしています。Google Search Console -- performance data for the last 16 months minimum, the index coverage report, any manual actions, all sitemaps. And pull from Google Analytics (GA4 now, obviously) so you have your organic traffic benchmarks locked down before anything changes. Screenshots work fine here; I also export the raw CSVs.
---
2. リダイレクトマップを構築する。その後、もう一度確認する。
ここで移行の成否が決まります。大規模サイトでは、リダイレクトマップは実際のスプレッドシート──通常、Googleシートで、クライアント、開発チーム、夜11時に誤ってフォーミュラを上書きするかもしれない誰とでも共有されています。
構造はシンプルです：
- Column A：旧URL（末尾のスラッシュの有無を含めた完全一致）
- Column B：新URL（完全一致）
- Column C：リダイレクトタイプ（ほぼすべてのケースで301）
- Column D：ステータス（マップ済み、確認済み、ライブ）
- Column E：メモ（キャッチオールリダイレクト、カテゴリ統合、意図的な削除）
20,000ページのサイトでは当然のことながら全URLを個別にマップすることはできません。私が実施する順序はこうです：
- トップパフォーマンスURL（GSCから有機トラフィック順──上位500が通常、トラフィックの80%以上を占める）を最初にマップします。
- カテゴリーおよびタクソノミーページをマップする
- 意味のあるバックリンクがあるURLをマップします（これにはAhrefsを使用──生リンクではなく、リファリングドメイン別にフィルター）Ahrefs for this -- filter by referring domains, not just raw links)
- その他すべてに対してパターンベースのリダイレクトを処理する（例：/product/old-slug/→/shop/old-slug/）
/product/old-slug/→/shop/old-slug/) - リタイアするページの意図的な410を文書化する
パターンベースのリダイレクトは、ジュニア開発者が間違えやすい点です。ワイルドカードルールを広すぎるように書いて、リダイレクトするつもりのないURLを誤って飲み込んでしまいます。本番環境に近づける前に、ステージング環境ですべてのパターンルールをテストしてください。
---
3. ステージング環境は必須です
これを短く記しますが、説明が特に必要ではないはずです。すべてのマイグレーションはステージング環境を備えます。以上です。
Seahawkは2022年にフィンテッククライアントがいて、このことに反発しました──「サイトが小さいから本番でやっちゃおう」と言いたかった。そのサイトは6,000ページでした。ステージングでやりました。すべてのプロダクトページからカノニカルタグを削除していたプラグイン競合を発見しました。Googleが全て再クロールするまで見えなかったはずで、低権威度ドメインではそれに数週間かかる可能性があります。
ステージング環境では以下をチェックしています：
- すべてのリダイレクトが正しく動作する（Screaming Frog をステージングに向けて使用し、リダイレクトマップを一括検証）
- robots.txtがステージング環境のインデックスをブロックしている（重要――Disallow: /を使用し、さらにダブルプロテクションのためにnoindexヘッダーも追加する）
Disallow: /but also add a noindex header for double protection) - 新しいサイトマップが正確で、ステージング URL を含まない
- Canonical タグが正しい本番環境 URL を指している
- PageSpeed Insightsでページスピードのベースラインを設定する――マイグレーションはしばしばリデザインの機会として活用され、リデザインはしばしばCore Web Vitalsを破壊するPageSpeed Insights -- migrations are often used as redesign opportunities, and redesigns frequently destroy Core Web Vitals
---
4. Go-Live シーケンス（順序があなたが思っているより重要）
ここが人々が自由奔放に行動して自分たちに問題を引き起こす部分です。特定の順序があります。私はそこから外れません。
ステップ1：プリローンチ（48時間前）
- すべてのDNSレコードのTTLを300秒（5分）に短縮する。プロパゲーション速度が大幅に向上する。
- クライアントに通知：マイグレーションウィンドウ中はコンテンツ変更、新規ページ追加、プラグイン更新は禁止。
- CDN、広告プラットフォーム、モニタリングツールなどのサードパーティ統合に今回の変更を事前通知する。
ステップ2：ローンチウィンドウ
- DNSを更新する
- 新しいコンテンツが完全に伝播する前にリダイレクトをデプロイする――リダイレクトはサーバーレベルで稼働すべきであり、WordPressだけではなく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がリダイレクトマップにあった場合は、最終的な宛先を直接指すように更新します。誰も文書化していない移行からのレガシーチェーンだった場合は、追加します。
このステップだけで――2023年初頭にMagentoからWooCommerceにマイグレーションしたあるクライアントの場合――2日間を要した。彼らは8年間で3回のマイグレーションを経験していた。URLの中には正しいページに到達する前に5つのリダイレクトを通過するものもあった。すべてを統合したことで、Search Consoleのクロール予算メトリクスは1ヶ月以内に顕著に改善された。
---
6. 大規模なコンテンツ検証
20,000ページを手動でレビューすることはできません。しかし、重要な部分を体系的に検証することはできます。
ローンチ後の最初の2週間でチェックしていることは以下の通りです:
- タイトルタグとメタディスクリプション: ランダムに選んだ200ページのサンプルをマイグレーション前のScreaming Frogエクスポートと比較します。不一致はすぐにフラグを立てます。: Compare a random 200-page sample against the pre-migration Screaming Frog export. Mismatches get flagged immediately.
- 構造化データ:商品ページ、記事ページ、ホームページのサンプルをGoogle Rich Results Testに実行します。マイグレーションはスキーママークアップを壊すことが多く、特に新しいテーマが別のプラグインを使用する場合はそうです。: Run a sample of product pages, article pages, and the homepage through Google's Rich Results Test. Migrations break schema markup more often than you'd think, especially if the new theme uses a different plugin.
- 内部リンク: Screaming Frogクロール、インリンクでフィルター。高価値ページは依然として強い内部リンク数を持つべきです。以前400の内部リンクを持っていたカテゴリーページが現在12しかない場合、テンプレートで何か問題が起きています。: Screaming Frog crawl, filter for inlinks. High-value pages should still have strong internal link counts. If a category page that previously had 400 internal links now has 12, something went wrong in the template.
- 画像と代替テキスト: SEOの観点から厳密に重要ではありませんが、壊れた画像はユーザーエクスペリエンスシグナルを損ない、テンプレートサイトでは見落としやすいです。: Not strictly SEO-critical, but broken images hurt user experience signals and they're easy to miss on templated sites.
---
7. マイグレーション後90日間のモニタリング
マイグレーションはgo-liveの日に終わるわけではありません。最低でも90日間継続します。
初月は週次レポーティングのリズムをクライアントと設定し、その後は隔週にしました。監視している項目は以下の通りです：
- GSC インデックスカバレッジ：インデックスされたページ数がマイグレーション前のカウントに向かって回復しているか。3週間を超えて続く大幅な低下は調査が必要です。: Is the number of indexed pages recovering toward the pre-migration count? A significant drop that persists beyond three weeks needs investigation.
- オーガニックトラフィック対ベースライン――ランディングページタイプ（商品、カテゴリ、ブログ）でセグメント化する。トラフィック減少は往々にして不均等である――カテゴリページが急落する一方、商品ページは保ち堪えることもある。: Segmented by landing page type (product, category, blog). Traffic drops are often uneven -- sometimes category pages tank while product pages hold.
- クロールバジェット：GSC のクロール統計レポートは、1日あたりのクロール平均ページ数とサーバーレスポンスタイムを表示します。Googlebot が大量の 404 にヒットしている場合、ここに現れます。: GSC's crawl stats report shows average pages crawled per day and server response times. If Googlebot is hitting a lot of 404s, it shows here.
- ランキングポジションの追跡：Ahrefs のランク追跡と Google Search Console のパフォーマンスレポートの組み合わせを使用しています。最初の2～3週間のランキング変動は一般的であり、必ずしも問題ではありません。4週間を超えて続く低下は対応が必要です。: I use a combination of Ahrefs rank tracking and Google Search Console's performance report. Ranking volatility in the first two to three weeks is common and not necessarily a problem. Sustained drops beyond week four warrant action.
- バックリンクプロフィール：Ahrefs を使用して、旧 URL を指す高価値バックリンクが既に正しくリダイレクトされているか、または更新のためのアウトリーチ対象としてフラグを立てるかを確認します。: Using Ahrefs, verify that high-value backlinks pointing to old URLs are either already redirected correctly or flagged for outreach to update.
正直なところ、ほとんどのマイグレーション SEO の問題は、正しいメトリクスを監視していれば30日以内に検出可能です。人々に悪影響を与えるのは、監視をセットアップせず、クライアントが8カ月後に気づくというケースです。
---
8. 私が犯した間違い（あなたが同じ過ちをしないために）
2019年の話だが、UK、オーストラリア、カナダのサブフォルダを持つクライアントのマイグレーションでhreflangの実装を見落とした。canonicalタグは正しかった。リダイレクトも問題なかった。だが新しいサイトのhreflangアノテーションは間違った地域コードを持っていた――en-auではなくen-AU（大文字小文字が実装によっては重要なようだ）。Googleはオーストラリアの検索ユーザーに対してUKページを配信し始めた。オーストラリアのオーガニックトラフィックが半減した理由を解明するのに6週間かかった。その後のすべての国際マイグレーションではhreflang検証ステップを導入している。en-au instead of en-AU(case matters, apparently, in some implementations). Google started serving the UK pages to Australian searchers. Took us six weeks to figure out why Australian organic traffic had halved. We've had a hreflang validation step in every international migration since.
もう1つ：noindexされたURLを含むXMLサイトマップ。軽微な矛盾に見えるかもしれませんが、矛盾したシグナルを送信するため、クリーンアップする価値があります。Screaming Frogはサイトマップを監査して、noindexタグを返すサイトマップ内のURLをすべてフラグできます。
おそらく最も高い代償を払った教訓：ロールバック計画がないこと。マイグレーションが失敗しかけている場合、1時間以内にDNSを古いサーバーに戻す能力は何物にも代えがたい価値があります。私は常に、マイグレーション後少なくとも30日間は旧環境をライブで無傷の状態に保つよう主張します。クライアントはホスティングコストについて文句を言うことがあります。私が70%のトラフィック低下が収益にもたらすコストを説明すると、文句を言わなくなります。
---
FAQ
20,000ページのサイトマイグレーションの計画には実際のところどのくらい時間がかかりますか？
現実的には、ゴーライブ日の前に6～10週間の準備期間が必要です。そのサイズのリダイレクトマップだけでも、特にすべてのURLのバックリンクを監査する場合、適切に構築するのに2～3週間かかることがあります。準備を急ぐと、数ヶ月のリカバリーに費やすことになります。
マイグレーション後にサーチコンソール（GSC）の無視ファイルを送信する必要がありますか？
通常は不要です。ただし、旧ドメインに有害なリンクがあり、特にそれから逃れるためにマイグレーションしている場合は別です。新しいドメインにマイグレーションして、クリーンなリンクプロフィールを希望する場合は、新しいプロパティのGSCで無視を処理してください。ただし、ほとんどのプラットフォームまたは同じドメイン上のリデザインマイグレーションでは、無視は関係ありません。
大規模なマイグレーションでエージェンシーが最もよく犯す間違いは何ですか？
リダイレクトマップを開発タスクとして扱うこと。リダイレクトはSEOタスクであり、開発者がそれを実装する。検索戦略を担当するSEOチーム――またはそれを所有する者――がマップを所有し、レビューし、署名する必要がある。技術的には正しいリダイレクトルールを構築したが、誰も開発者にどのURLバリアントが正規であるべきかを伝えなかったためSEO的には間違っていた、というケースを見ている。
サイトの速度はマイグレーションのSEOに影響を与えるか？
はい、ほとんどの人が考慮するよりも多い。Core Web Vitalsはランキング要因であり、リデザイン――マイグレーションに伴うことが多い――はしばしばより重いJavaScriptまたは最適化されていない画像を導入する。ローンチ前に必ず新旧サイト間でPageSpeed Insightsの比較を実施する。新しいサイトがモバイルで大幅に低速である場合、スイッチを切り替える前に修正する。
ユーザー生成コンテンツが大量にあるサイトのマイグレーションにはどう対処しますか？
慎重に対処します。UGCページは個別には低品質なことが多いですが、集合的にはロングテールトラフィックを生み出します。クロールと分析のステップを推奨するのが通常です。つまり、オーガニックトラフィックがあるUGC URLを特定し、それらだけをリダイレクトして、残りは404ではなく410で返します。410はGoogleに対してページが意図的に削除されたことを示し、404は曖昧です。
---
マイグレーションは、良好と壊滅的の違いがほぼすべてプリローンチの準備にある分野の一つだ。技術的な実装は通常は簡単な部分だ。プリローンチの作業――クロール、リダイレクトマップ、ステージング検証――を正しく実行することが実際の作業である。そしてマイグレーションが既にライブで既に壊れた状態で渡された場合でも、チェックリストは依然として適用される。ただ逆順で実行しているだけだ。