サイト移行SEO：ドメイン・プラットフォーム・構造の移行における301マッピングとトラフィック保護
1. 3種類の移行とリスクの度合い
すべてのサイト移行が同じように傷つくわけではありません。まず自分がどのタイプかを判断し、それからどこまで手をかけるかを決めます。
| 移行の種類 | URLの変化 | 評価の引き継ぎ期間 | リスクの度合い | 核心となるアクション |
|---|---|---|---|---|
| ドメイン変更（example.com → new.com） | すべて変化 | 2〜6 週間 | 高 | Change of Address + 全件301 |
| プラットフォーム変更（Shopify → 自社開発 / WordPress → Next.js） | ほとんど変化 | 2から4週間 | 中～高 | 1件ずつマッピング + sitemapを再送信 |
| ディレクトリ構造の変更（/blog/ → /insight/） | 一部変化 | 1から2週間 | 中 | 正規表現で一括301 |
| HTTPS化またはwww追加 | プロトコル・サブドメインの変化 | 1週間以内 | 低 | 全サイトを新プロトコルへ301 |
| デザインのみ変更、URLはそのまま | 変化なし | なし | 低 | 301は不要、表示速度とコンテンツに注力 |
直感に反する点：HTTPS化やwww追加のような「小さな」移行でも、301の書き方を誤ってhttpsとhttpの両バージョンが併存すると、長期的な評価の分裂はコンテンツ改版1回よりはるかに大きな代償になります。HTTPS設定とHSTSが、この種の移行の技術的な前提です。
2. 301マッピング表の作り方：T-30日からT日まで
マッピング表は公開後に足すものではなく、公開の30日前から始めるべき主要な成果物です。
| タイミング | アクション | データソース | 検収基準 |
|---|---|---|---|
| T-30日 | 旧サイトの全URLを書き出す | XML sitemap + Screaming Frogでのクロール | インデックス済みURLを100%カバー |
| T-28日 | GSCの直近12か月のクリックデータを重ねる | Search Consoleの検索パフォーマンスレポート | クリックのあるURLをすべて優先とマーク |
| T-21日 | 被リンクデータを重ねる | Ahrefs / Google Search Consoleのリンク | 被リンクのあるURLを勝手に404にしない |
| T-14日 | 1件ずつ1:1でマッピング | コンテンツチームとSEOが共同で実施 | クリックのあるURLは100%新しい遷移先がある |
| T-7日 | マッピング表を技術レビュー | 開発 + 運用 | 301の連鎖なし、遷移先の404なし |
| T日 | 301を公開 + 変更を通知 | サーバー設定 + GSCのChange of Address | 50件を抜き取り検査し、すべて正しいページへ301 |
事例：ある工業系B2Bサイトが旧ドメインから新ブランドドメインへ移行。旧サイトには2300のURLがあった。チームは1件ずつマッピングせず、ディレクトリ単位で一括301を設定した。/products/ はすべて新サイトの /products/ へ、/blog/ はすべて新サイトの /insight/ へ。公開4週間後、新サイトのブログ流入は旧サイトの40%しかないことが判明。原因は、旧ブログ記事のURLがテーマ別ディレクトリだったのに対し、新サイトは公開年別ディレクトリで、ディレクトリ単位の301が全記事を年別アーカイブページへ飛ばしてしまい、テーマの関連性が失われたこと。正しい方法は1件ずつのマッピングで、2300件なら2人日で完了できる。
マッピングの原則は「テーマ1対1」。旧製品ページは新製品ページへ、旧ブログ記事は新サイトで最も関連する記事へ。対応する新コンテンツがない旧ページは、トップページではなくカテゴリページへ301する。旧URLをすべてトップページへ飛ばすのが最もよくあるミス。
三、公開当日に必ずやる6つのこと
| アクション | ツール | なぜ当日にやる必要があるか |
|---|---|---|
| 301マッピングを50件抽出して確認 | Screaming Frog / Redirect Path | 設定ミスは当日なら直せる。1週間延ばせば1週間分のクロール予算を無駄にする |
| Change of Addressを送信 | Search Console | Google公式の移行シグナルで、再クロールを加速させる |
| 新sitemapを送信 | Search Console | Googleに新URL構造をいち早く認識させる |
| 旧サイトのログイン状態でのクロールを停止 | robots.txt / 旧サイトをnoindex | 旧サイトがクロールされ続けるのを防ぐ |
| 重要な被リンク元へ連絡 | メール / 領英 | ディレクトリサイトやパートナーに新ドメインへのリンク更新を依頼 |
| GSCのエラーキューを監視 | Search Console | 最初の7日間は毎日確認し、404が急増したらすぐ対応 |
ドメイン変更時は、Google Analytics、Search Console、広告アカウントもすべて新ドメインで認証し直すこと。忘れるとデータがゼロから始まる。サイト監視とアラートの指標は移行前に設定しておく。移行後に比較できるベースラインが必要だから。
四、T+60日で成功をどう判断するか
| 指標 | 健全レンジ | 警告サイン | すぐ対応 |
|---|---|---|---|
| 自然クリック | T+60日で旧サイトの90%以上まで回復 | T+60日でも旧サイトの50%未満 | 301マッピングを1件ずつ再確認 |
| インデックスカバレッジ | インデックス済みページの割合が90%以上 | 「クロール済み-インデックス未登録」が大量発生 | コンテンツ品質とクロール予算を確認 |
| 301のリダイレクトチェーン | 0 件 | 2回以上のリダイレクトが発生 | 直接301に統合 |
| 404の件数 | T+30日以降は低い水準で安定 | 増え続けている | GSCの404レポートを出力して301を追加 |
| 核心网页指标 | 移行後に低下しない | LCPが0.5秒以上悪化 | 新プラットフォームのパフォーマンス回帰テスト |
事例2：あるB2BサイトがWordPressからNext.jsへ移行したところ、T+30日で自然流入が35%減少し、チームはロールバックを検討した。GSCのカバレッジレポートを確認すると、インデックス済みページが旧サイトの1800から600に減少。原因は新サイトのsitemapが製品ページしか送信しておらず、ブログ記事がすべて漏れていたこと。sitemapを追加送信して2週間後、インデックス数は1700に戻り、流入は旧サイトの92%まで回復した。この事例が示すのは、移行後に流入が落ちたらまずインデックスを確認し、慌ててロールバックしないこと。
五、よくあるミスとレッドライン
| よくあるやり方 | 結果 | 正しい方法 |
|---|---|---|
| すべての旧URLを新トップページへ301 | ソフト404のリスクと、トップページのテーマ希薄化 | テーマは1対1でマッピング、対応ページがない場合のみカテゴリページへ |
| 移行後、旧サイトの301は3か月で解除 | 被リンクの評価が失われる | 旧サイトの301は最低12か月維持 |
| ドメイン変更時にcanonicalの更新を忘れる | 新旧ドメインで内容が重複 | 新ページのcanonicalは新ドメイン自身を指す |
| プラットフォーム移行時に構造化データの移行を忘れる | リッチリザルトがすべて消える | Schemaはテンプレートと一緒に移行し、リグレッション検証も行う |
| 移行当日にrobots.txtでクロールを禁止する | Googleがクロールを完全に停止 | robotsは開放したまま、旧サイトのログイン状態のブロックだけ削除 |
移行時はSchemaも必ず一緒にリグレッション確認を行い、構造化データSchemaテンプレートが新プラットフォームに引き継がれていないと、リッチリザルトは移行後4〜8週間で消えます。多言語サイトでは次の点も併せて確認してください。Hreflangの多言語対応URL構造と一緒に移行するかどうか。
六、移行前後のデータ基準をどう残すか
移行前の基準がなければ、移行後の下落が通常の変動なのか事故なのか判断できません。T-30日には旧サイトの重要データをスナップショットとして凍結し、移行後は毎週照合します。
| 基準指標 | 凍結時点 | 照合頻度 | 異常しきい値 |
|---|---|---|---|
| GSCの自然クリックと表示回数 | T-30日の直近12週間の平均 | 毎週月曜 | 前週比20%超の下落でアラート |
| インデックス済みページ数 | T-30日 | 毎週 | 基準比15%超の下落でアラート |
| 主要キーワードの順位 | T-30日時点の上位100語 | 2週間ごと | 上位10語が20位以下に落ちたらアラート |
| 被リンク総数とアンカーテキスト | T-30日のAhrefsエクスポート | 毎月 | 被リンクが10%超減少したらアラート |
| 核心网页指标 | T-30日のCrUX平均値 | 2週間ごと | LCPが0.5秒以上悪化したらアラート |
この基準表はT日より前に用意しておき、移行後は最初の1週間は毎日、2週目以降は毎週確認します。多くのチームは移行後2週間でようやく流入減少に気づき、振り返ってみたら基準を残しておらず、感覚で判断するしかありません。基準を残しておけば、T+60日の検収も根拠を持って行え、”戻ったようだ”という当て推量にならずに済みます。
もう一点注意してください。移行期間中に大規模なリニューアル、テンプレート変更、新機能追加を同時に行わないこと。一度に動かす変数は1つだけにすれば、問題が起きたときに301のせいか新テンプレートのせいかが分かります。コンテンツのリニューアル、パフォーマンス最適化、Schemaの調整は移行後30日以降に分けて行えば、事故の切り分けがずっと楽になります。
移行期間中はサーバーログも注視してください。T日からT+14日までは、404と5xxのリクエスト数を毎日確認します。特定のURL種別で404が急増したら、マッピング表の漏れがほとんどです。5xxが急増したら、新サイトのサーバー設定に問題がある可能性が高く、SEOとは無関係ですが同じく致命的です。ログのアラートとGSCレポートは同じダッシュボードに置き、エンジニアとSEOチームが同じビューを共有してください。別々に見てはいけません。
移行が終わったからといって、すぐに旧サイトのサーバーを止めないでください。旧サイトの301は最低12か月残し、その間は毎月旧ドメインのGSCにログインして自然検索流入を確認します。流入が2か月連続でゼロになったら、運用担当と相談して停止の可否を判断しましょう。早く止めると被リンクの評価が一瞬で切れ、それまでの3か月の苦労が水の泡になりかねません。
FAQ よくある質問
ドメイン変更にはChange of Addressが必須ですか？
移行後にどのくらい流入が落ちれば正常ですか？
旧サイトの301はいつまで残すべきですか？
ディレクトリ単位の一括301ではなぜ不十分なのですか？
移行時に新しいsitemapを送信すべきですか？
移行後にリッチリザルトが消えたらどうすればいいですか？
最後に
サイト移行はSEOの中でも数少ないやり直しがきかない作業です。301の設定を一度誤ると、失った評価を取り戻すのに3〜6か月かかります。デザインの納品ではなく、エンジニアリングのリリースとして扱ってください。
実施は3ステップ。T-30日に旧サイトの全URLを書き出し、GSCと被リンクデータを重ねる。T-14日に1対1のマッピング表を完成させ、技術レビューを通す。T+60日に5項目の指標で検収し、未達分は1件ずつ修正する。
覚えておきたい一言。移行の勝敗は公開30日前に決まる。主な成果物は301マッピング表であり、公開当日は表に沿って実行するだけだ。