migrate-site

サイト移行

検索順位を落とさずにドメイン移行、CMS の切り替え、または URL の再構成を行うためのガイドです。リダイレクトマッピング、モニタリング計画、ロールバック基準を説明します。

移行の種類

種類	リスクレベル	例
ドメイン変更	高	olddomain.com → newdomain.com
プロトコル変更	低	HTTP → HTTPS
CMS の切り替え	中〜高	WordPress → Next.js、Shopify → custom
URL の再構成	中	/blog/2024/post → /blog/post
サブドメイン移行	中	blog.example.com → example.com/blog
デザイン／テンプレートの変更	低〜中	URL は同じで、テンプレートを変更

すべての移行には SEO 上のリスクがあります。目標は、トラフィックの落ち込みを最小限に抑え、回復を早めることです。

フェーズ 1：移行前の監査

すべてを洗い出す

何かに手を加える前に、現在の状態を記録します。

ページ：

• インデックス登録されたすべての URL の一覧（サイトマップと Search Console から取得）
• 各ページの月間トラフィック（Search Console、過去 6 か月分）
• 各ページの上位キーワードと検索順位
• 各ページの被リンク数（外部リンクのあるページには特に注意が必要です）

技術面：

• 現在の robots.txt
• 現在の XML サイトマップ
• 現在のリダイレクトルール
• 現在の構造化データ
• 現在の canonical タグ
• 現在の内部リンク構造

パフォーマンス：

• オーガニックトラフィックの基準値（週次および月次）
• トラフィック上位 50 ページ
• Core Web Vitals のスコア
• Search Console のクロール統計

すべて保存してください。 移行後のデータと比較するために、このデータが必要です。

価値の高いページを特定する

すべてのページの重要度が同じではありません。特に注意すべきページに印を付けてください。

• オーガニックトラフィックが最も多いページ（上位 20%）
• 外部被リンクのあるページ
• 価値の高いキーワードで検索順位を獲得しているページ
• コンバージョンに関連付けられたランディングページ
• 強調スニペットが表示されるページ

これらのページには、正しく動作するリダイレクトを設定し、移行後に個別に検証する必要があります。

フェーズ 2：リダイレクトマッピング

リダイレクトマップは、最も重要な成果物です。すべての旧 URL を適切な新 URL に対応付ける必要があります。

マッピングのルール

旧 URL	新 URL	種類	備考
/old-page	/new-page	301	コンテンツが一致
/removed-page	/closest-relevant-page	301	関連ページに統合
/deleted-page	/	301	関連ページがない場合はホームページへ転送（最終手段）

ルール：

• 恒久的な移動には 301 リダイレクト を使用します（302 ではありません）
• 各旧 URL を 最も関連性の高い 新 URL に対応付けます（すべてをホームページに転送しないでください）
• 可能な場合は URL 構造を維持します（リダイレクトが少ないほどリスクを抑えられます）
• リダイレクトチェーン（旧 → 中間 → 新）を避けます。各リダイレクトは直接転送にしてください。
• URL のバリエーションに対応します。末尾のスラッシュの有無、www の有無、HTTP／HTTPS などです。

よくある落とし穴

• ページネーション URL（/page/2、/page/3）のリダイレクトを忘れる
• 被リンクのあるクエリパラメータ付き URL の対応漏れ
• 大文字と小文字の扱いの問題（一部のサーバーでは /Page と /page が異なるものとして扱われます）
• すべてをホームページにリダイレクトする（ページ単位の評価を損ないます）

フェーズ 3：技術的なセットアップ

切り替え前

• 新しいサイトを完全にクロールできる（ステージング用の robots.txt が残っていない）
• すべてのリダイレクトルールを実装し、テスト済み
• 新しい XML サイトマップを用意済み（新 URL を含む）
• 新しいページの canonical タグが新 URL を指している（旧 URL ではない）
• 内部リンクを新 URL に更新済み（内部リンクでリダイレクトチェーンに依存しない）
• 構造化データを新 URL に更新済み
• hreflang タグを更新済み（多言語サイトの場合）
• 新しいドメイン用の Google Search Console プロパティを作成済み（ドメイン変更の場合）
• 新しいサイトのアナリティクストラッキングを更新済み
• 新しいサイト向けに CDN／キャッシュを設定済み

切り替え時

• リダイレクトルールをデプロイ
• 新しいサイトをデプロイ
• リダイレクトが機能していることを確認（20 件以上の URL を抜き取りチェック）
• 新しいサイトマップを Search Console に送信
• ドメイン変更の場合：Search Console のアドレス変更ツールを使用
• Search Console の URL 検査を使用して、重要なページのクロールをリクエスト
• 最初の 24 時間はサーバーエラーをリアルタイムで監視

フェーズ 4：移行後のモニタリング

1 週目（日次チェック）

• Search Console でクロールエラー（404、5xx エラー）を確認する
• オーガニックトラフィックが壊滅的に減少していないことを確認する
• リダイレクトが引き続き機能していることを確認する
• リダイレクトされるべきページが 404 を返していないか確認する
• サーバーの応答時間を監視する（移行によってパフォーマンスの問題が明らかになることがあります）

2～4 週目（週次チェック）

• オーガニックトラフィックを移行前の基準値と比較する
• Search Console でインデックス登録状況（インデックス登録済みページ数）を確認する
• 重要なページが新しい URL でインデックス登録されていることを確認する
• 上位キーワードの検索順位を確認する
• クロール統計に異常がないか確認する

2～3 か月目（月次チェック）

• トラフィックが移行前の水準に回復しているはずです
• すべての旧 URL が Search Console でリダイレクト済みと表示されているはずです
• 新しい URL がインデックス登録され、検索順位が付いているはずです
• Core Web Vitals が安定しているはずです

予想されるタイムライン

• トラフィックの減少： 通常の現象です。最初の 2～4 週間で 10～30％の減少が見込まれます。
• 回復： リダイレクトが正しく設定されていれば、ほとんどのサイトは 2～3 か月以内に回復します。
• 完全な安定化： 大規模なサイトでは 3～6 か月かかります。
• 危険信号： 4 週間経ってもトラフィックの回復が始まらない場合は、調査してください。

フェーズ 5：ロールバック計画

移行前に、ロールバックの基準を定めます。

次の場合はロールバックします：

• オーガニックトラフィックが 7 日を超えて 50％以上減少した
• リダイレクトの 20％超が機能していない
• コンバージョンに不可欠なページにアクセスできない
• サーバーエラーが許容範囲を超えている

ロールバックの手順：

1. DNS を元に戻す（ドメインを変更した場合）、または旧サイトを再デプロイする
2. リダイレクトを削除するか、元に戻す
3. 旧サイトマップを再送信する
4. 再度移行を試みる前に、問題の原因を調査する

出力形式

移行計画：[old] → [new]

移行の種類： [ドメイン変更 / CMS の切り替え / URL の再構成 / など] リスクレベル： [低 / 中 / 高] 推定タイムライン： [準備 + 実行 + モニタリング]

移行前のインベントリ

• インデックス登録済みページの合計： [count]
• 被リンクのあるページ： [count]
• トラフィック上位のページ： [上位 10 件のリスト]
• 現在の月間オーガニックトラフィック： [baseline]

リダイレクトマップ [表 — 旧 URL から新 URL への完全な対応表]

技術チェックリスト [フェーズ 3 のチェックリスト]

モニタリングスケジュール [フェーズ 4 のチェックポイント]

ロールバック基準 [定義済みのしきい値と手順]

リスク領域

• 特に注意が必要な価値の高いページ
• この移行の種類における既知の技術的課題
• 維持する必要がある外部からの被リンク

---

プロのヒント： 無料の リンク切れチェッカー を使用して移行後のリダイレクトを確認し、Htaccess Generator でリダイレクトルールを作成できます。SEOJuice MCP ユーザーは /seojuice:site-health を実行してリンクデータ付きの 全ページのインベントリを取得し、/seojuice:keyword-analysis で価値の高いページを特定し、 list_changes で移行後のコンテンツの違いを検出できます。