content-migration

コンテンツの移行

SEO、ユーザーのブックマーク、下流の連携を損なわずに、あるプラットフォーム、ドメイン、URL 構造から別のものへコンテンツを移行します。特定のスタックに依存しません。

---

使用する場面

• ある CMS から別の CMS に移行する場合（例：WordPress からヘッドレス構成へ）
• 複数のサイトを 1 つに統合する場合
• 1 つのサイトを複数に分割する場合
• URL 構造を変更する場合
• ドメインを移行する場合（ブランド変更、合併、リブランド）
• 独自開発のサイトからプラットフォームへ（またはその逆に）移行する場合
• 大規模な移行の一環として、コンテンツ監査に基づく整理を行う場合

使用しない場面

• 既存のコンテンツがない新規サイト（移行は不要です）
• 既存サイト内の単一ページの編集やコンテンツの更新（content-and-copy を使用してください）
• URL を変更しないパフォーマンスやテクニカル SEO の改善（seo-technical を使用してください）
• 定期的なコンテンツ監査（seo-content-audit を使用してください）

---

必要な入力

• 移行元：現在のプラットフォーム、現在の URL 構造、現在のコンテンツ一覧
• 移行先：対象のプラットフォーム、対象の URL 構造、対象の機能
• 移行の理由（何を優先して維持するかを決めます）
• 制約（スケジュール、予算、許容できるダウンタイム）
• 関係者（SEO、コンテンツ、開発、広報、サポート）

---

フレームワーク：6 つのフェーズ

コンテンツの移行はすべて、同じ流れに沿って進めます。フェーズを省略すると、移行は失敗しやすくなります。

フェーズ 1：一覧の作成

把握していないものは移行できません。既存のコンテンツをすべて網羅した一覧を作成します。

コンテンツごとに、以下を記録します。

• URL
• タイトル
• コンテンツの種類（記事、ランディングページ、製品、ドキュメントなど）
• ステータス（公開中、下書き、アーカイブ済み、公開予約済み）
• 最終更新日
• 作成者または所有者
• トラフィック（直近 12 か月分）、またはデータ可用性ルールに基づいて不足を明記
• 被リンク（主要な外部参照元）
• そのコンテンツへの内部リンク
• 埋め込みアセット（画像、動画、ダウンロード）

データは、CMS のエクスポート、XML サイトマップ、サーバーログ、アナリティクス、検索コンソール、被リンクツールから取得します。

一覧はスプレッドシートで作成します。移行の後続作業で参照する正式な情報源となります。

フェーズ 2：監査と判断

コンテンツごとに、以下を判断します。

• 維持： そのまま移行
• 更新： 編集して移行（内容の更新、拡充、修正）
• 統合： 別のコンテンツとまとめ、古い両方の URL を新しい URL にリダイレクト
• リダイレクト： 移行せず、関連ページにリダイレクト
• 削除： 移行せず、リダイレクトもしない（慎重に行い、明らかに価値の低いページに限ります）

これは seo-content-audit の作業です。移行時に実施しましょう。省略するタイミングではありません。

「更新」または「統合」と判断した各コンテンツについて、具体的な変更内容を記録します。

フェーズ 3：URL のマッピング

URL マップは、移行で最も重要な成果物です。

古い URL	新しい URL	ステータスコード	理由
/old/path	/new/path	301	直接の置き換え
/old/page-1, /old/page-2	/new/merged	301	コンテンツの統合
/old/deprecated	/related/replacement	301	最も近い置き換え先
/old/junk	(none)	410	意図的に削除

ルール：

• 新しい移行先があるコンテンツには 301（恒久的なリダイレクト）を使用します
• 意図的に削除したコンテンツには 410（消失）を使用します
• 410 のほうが正確な場合は、404（未検出）を避けます
• すべてをホームページにリダイレクトしないでください。常に個別の移行先を指定するほうが適切です
• トラフィックまたは被リンクがある URL はすべてマッピングします。優先度の低い URL にはパターンを適用できます

ドメインを移行する場合は、構造が変わる箇所に個別の例外を設定し、デフォルトでは 1 対 1 のパスマッピング（old.com/page → new.com/page）を使用します。

フェーズ 4：構築とステージング

移行先を構築します。ステージング環境を省略しないでください。

• 新しいプラットフォームに新しいコンテンツを設定します
• URL マップを実装します（ほとんどのプラットフォームはリダイレクトファイルまたはルールに対応しています）
• 代表的なサンプルでリダイレクトが機能することを確認します
• 重要なユーザーフロー（登録、購入、お問い合わせ）をテストします
• アナリティクス、監視、連携を検証します
• 検索エンジンの視点でテストします：robots.txt、サイトマップ、canonical

可能であれば、切り替え前に Google に移行先をクロールしてもらい、リダイレクトの切り替え時点ですでにインデックスされている状態にします。

フェーズ 5：切り替え

実際の切り替えです。ローンチとして計画し（このスキルと併せて launch-runbook を使用してください）。

切り替え前：

• 関係者への連絡（日程、想定される影響）
• ダウンタイムが予想される場合はユーザーに連絡
• 想定される質問に備えてサポートチームを準備
• 前日に DNS TTL を短縮（安全のため 1～3 日前）
• 移行元プラットフォームをバックアップ（ロールバックが必要になった場合に備えて）

切り替え：

• リダイレクトルールを有効化
• DNS の変更を適用
• 新しいサイトマップを検索エンジンに送信
• 古いサイトマップを削除または更新
• 内部リンクを監査し、可能な場合は新しい URL を参照するよう更新
• ユーザーに見える影響がある場合はステータスページまたはバナーを表示

切り替え直後：

• インベントリの上位 50 ページをスモークテスト
• リダイレクトが 301 であることを確認（302 ではないこと）
• Search Console にエラーがないか確認
• リアルタイムのトラフィックを監視し、予期しない減少がないか確認
• エラーログを監視し、アセットの欠落やインテグレーションの不具合がないか確認

フェーズ 6：監視と復旧

移行は切り替え時点では完了しません。その後 30～90 日間で問題が明らかになります。

監視項目：

• トラフィック： 一時的な減少が予想されます（10～30％はよくあります）。4～8 週間で回復するはずです。それ以降も減少が続く場合は問題です。
• インデックス登録： 新しい URL がクロールされ、インデックスに登録されているはずです。Search Console でカバレッジを確認してください。
• ランキング： 上位キーワードを追跡します。順位の低下は通常ですが、急落はリダイレクトまたは canonical の問題を示しています。
• バックリンク： 外部サイトからリンクされているページが、正しい移行先に引き続き解決されることを確認します。
• 404： リダイレクトされるべき URL で 404 が発生していませんか？リダイレクトマップに追加してください。
• ユーザーからの報告： サポートチケットやソーシャルメディアを確認します。ユーザーは以前のリンクを見つけられていますか？

30 日以内によく行う修正：

• 404 のパターンから、見落としたリダイレクトを追加
• 見落とした内部リンクを更新
• インデックス登録が停滞した場合はサイトマップを再送信
• クロールエラーを調査して修正

---

ワークフロー

ステップ 1：範囲を設定する

何を対象にし、何を対象外にしますか？書き留めてください。範囲を定めないと、移行の対象は広がっていきます。

ステップ 2：インベントリを作成する

すべての URL、トラフィック、バックリンク、内部リンクを抽出します。成果物はスプレッドシートです。

ステップ 3：項目ごとに判断する

維持、更新、統合、リダイレクト、削除を決めます。判断内容を記録してください。

ステップ 4：URL をマッピングする

完全なリダイレクトマップを作成します。SEO 担当者とコンテンツの関係者がレビューします。

ステップ 5：移行先を構築する

ステージング環境で構築します。実際のコンテンツ（または代表的なコンテンツ）と実際のリダイレクトを用意します。

ステップ 6：テストする

• リダイレクトのサンプル（トラフィック上位 20 件、バックリンク上位 20 件、例外ケース）
• 重要なフロー（サインアップ、チェックアウト、問い合わせ）
• アナリティクスと監視
• 検索エンジンの視点（robots.txt、サイトマップ、canonical）

ステップ 7：切り替える

切り替えチェックリストに従って実施します。ロールバックの準備を整えてください。

ステップ 8：監視する

最初の 1 週間は毎日、その後最初の 1 か月は毎週、90 日目までは毎月監視します。

ステップ 9：結果を記録する

うまくいったこと。うまくいかなかったこと。学んだこと。（after-action-report を参照してください。）

---

失敗パターン

URL の一覧がない。 移行チームはすべて把握していると思っていますが、そうではありません。古い PDF、アーカイブされた投稿、被リンクのあるマーケティング用ランディングページなどがあります。一覧を作成してください。

301 ではなく 302 リダイレクトを使う。 302 は一時的なリダイレクトです。SEO の評価は確実には引き継がれません。特別な理由がない限り、301 を使ってください。

すべてをホームページにリダイレクトする。 「ユーザーに行き先を探してもらいます」。ユーザーは探してくれず、すぐに離脱します。個別に対応付けてください。

リダイレクトチェーンが長い。 /a → /b → /c → /d。それぞれのリダイレクトで評価が少しずつ失われ、遅延も増えます。/a → /d に短縮してください。

HTML 以外の URL を忘れる。 PDF、画像、ダウンロードファイルにも URL があり、被リンクもあります。対応表に含めてください。

クエリ文字列を忘れる。 /page?id=123 は /page とは別の URL です。クエリ文字列のバリエーションには、パターンまたは個別の対応表を用意してください。

末尾のスラッシュを無視する。 ほとんどのサーバーでは、/page と /page/ は別の URL です。正規形を一つ選び、もう一方をリダイレクトしてください。

ステージング環境がない。 移行を実行するのが本番環境で初めてになります。問題が発生します。ステージング環境で準備とテストを行ってください。

ステージング環境が本番環境と大きく異なる。 DNS、CDN、プラットフォームが異なると、ステージング環境ではテストに合格しても、本番環境では失敗します。可能な範囲で本番環境に近いステージング環境を用意してください。

移行元を稼働させたままにする。 2 つのサイトが同じコンテンツを配信することになり、重複コンテンツ、評価の分散、ユーザーの混乱を招きます。移行先に問題がないことを確認したら、移行元を停止してください。

移行元のドメインを更新し忘れる。 ドメインの有効期限が切れると、リダイレクトが機能しなくなり、トラフィックが失われます。移行元のドメインを使っていない場合でも、長期間にわたって更新してください。

ロールバック計画のない一斉移行。 問題が起きたらどうしますか。切り替え前にロールバックを計画してください。

繁忙期に切り替える。 四半期末、ホリデーシーズン、大規模キャンペーンの時期は避けてください。落ち着いた時期を選びましょう。

告知がない。 ユーザーは事前の案内もなく、ブックマークが使えなくなったことに気づきます。戻ってこないユーザーもいます。事前に伝えてください。

移行を一度きりの作業と見なす。 切り替え時点で終わりではありません。30～90 日間モニタリングし、表面化した問題を修正してください。

移行を単なる開発プロジェクトと見なす。 SEO、コンテンツ、サポート、コミュニケーションの担当者も関与する必要があります。初日から部門横断で進めてください。

---

出力形式

移行計画書には、以下を含めます。

• 対象範囲： 対象に含めるもの、対象外にするもの
• 一覧： URL のスプレッドシート
• 監査での判断： 維持、更新、統合、リダイレクト、削除
• URL 対応表： ステータスコードを含む、旧 URL から新 URL への対応
• アーキテクチャ： 新しいプラットフォームのセットアップ、リダイレクトの実装
• 切り替え計画： 切り替え当日の手順書
• ロールバック計画： 問題が起きた場合の対応
• モニタリング計画： 何をどのくらいの期間監視するか
• コミュニケーション計画： 社内および社外への連絡
• 担当者とスケジュール： 誰が、いつ、何を行うか

---

必要なデータが利用できない場合

このスキルの出力は、このスキル単独では生成できないデータ、測定値、またはツールの結果に依存します。必要な入力、ツール、またはデータソースを利用できない、あるいは検証できない場合に認められる出力は、不足している内容を明記した成果物です。何が必要だったか、実際に何を取得または検証できたか、出力のどの部分に影響するかを記載してください。成果物を完成させるために、必要な数値を捏造、推定、または補間することは、いかなる場合も認められません。不足を明記すれば、それで回答として完結します。

---

参考ファイル

• references/migration-runbook.md：切り替え日の手順をまとめたステップごとの手順書です。事前確認、実際の切り替え、直後の検証、最初の 24 時間のモニタリングが含まれます。