CMS移行とSEO

TL;DR — CMS移行は、公開プラットフォーム、コマース基盤、フロントエンド構成など、サイトを別のシステムへ移すことです。検索エンジンとユーザーが依存しているURL、コンテンツ、title、canonical、リンク、メディア、構造化データ、リダイレクト、robots制御を保ちます。URLが同じでも生成HTMLやメタデータが変わればSEOパリティを検証し、URLが変わるなら完全なマッピングと永久リダイレクトを用意します。

CMS移行とは何か

CMS移行は、ウェブサイトを作成・配信するコンテンツ管理システムまたはプラットフォームを置き換えることです。WordPressからヘッドレスシステム、Drupalから別のエンタープライズCMS、コマース基盤間の移行などが含まれます。

見た目が似ていても、URL、HTML、メタデータ、ナビゲーション、フィルター、ページネーション、画像、構造化データ、リダイレクト、robots指示は別物になり得ます。

すべてのCMS移行はURL移行か

いいえ。既存URLが機能していれば、公開URLをすべて同じに保つCMS移行も可能で、通常はこちらが安全です。

スキーム、ホスト名、パス、末尾スラッシュ、ファイル名、意味のあるパラメーターが変われば、プロジェクトはURL移行にもなります。URLマッピング、リダイレクト、内部リンク、canonical、サイトマップの作業を追加します。

SEOパリティとは何か

SEOパリティとは、新しいプラットフォームが、古いサイトの有用な検索可視動作を保つことです。見た目をピクセル単位で同じにすることではありません。

重要なページタイプごとに比較します。

• インデックス可能なURLとステータスコード。
• title、description、見出し、主要コンテンツ。
• canonical、robots指示、hreflang。
• 構造化データ。
• クロール可能な内部リンクとナビゲーション。
• 画像、動画、PDFなどのメディア。
• モバイル出力とレンダリング出力。

パリティには意図した改善も含まれます。改善を別に記録して、移行欠陥と混同しないようにします。

CMS移行でトラフィックを失う理由

多くの場合、新しいプラットフォームが重要な動作を再現しないことが原因です。古いURLの404、ステージングを指すcanonical、消えたカテゴリリンク、クリック後にしか読めない本文、商品・メディアURLの欠落などが例です。

原因はプラットフォーム名より、生成されたサイトにあります。

基本プロセスは何か

1. 現在のURL、テンプレート、コンテンツ、シグナル、リンク、アセット、リダイレクト、連携を棚卸しする。
2. URLを維持するか決める。
3. すべてのテンプレートとシステム動作に測定可能なパリティ要件を書く。
4. コンテンツ項目と変換をマッピングする。
5. ステージングでraw HTMLとレンダリングDOMを比較する。
6. リダイレクト、エラー、canonical、hreflang、構造化データを検証する。
7. 本番切替、ロールバック、監視をリハーサルする。

Website Migration Checklistがフェーズ別の共通手順を提供します。このガイドは各フェーズで新CMSが変え得る点に焦点を当てます。 関連資料

移行時に古いSEO問題をすべて直すべきか

新プラットフォームが再現してしまう高確度の欠陥は直しますが、再設計、コンテンツ書き換え、アーキテクチャ変更、URL整理を1回のリリースへ詰め込みません。可能なら一度に1つの大きな変更を行い、原因を切り分けられるようにします。 関連資料

必須修正と任意改善を分けます。公開後に起きたことを診断するには安定したベースラインが必要です。

TL;DR — リプラットフォームは2つのページ生成システム間の契約移行です。現在のURL、テンプレート、コンテンツ項目、内部リンク、インデックス制御、canonical、hreflang、schema、メディアURL、ファセット、リダイレクト、ステージング設定をすべて棚卸しします。URLを維持するか変えるかを早期に決め、テンプレート契約をraw HTMLとレンダリングDOMで検証し、エンティティからURLまでの照合とロールバックを本番前にリハーサルします。

計画を選ぶ前にリプラットフォームを分類する

CMS移行には、データとCMS、テンプレート、レンダリング、URL、ホスティング、ナビゲーション、分析など複数の変更が含まれます。

各層をスコープへ書き込みます。URL、ホスティング、レンダリング、ナビゲーションも変えるCMS移行は、1回のローンチを共有する4つの移行です。

同じURLか変更URLかを早期に決める

既存URLが有用で新プラットフォームが対応できるなら、URL維持を基本にします。「できない」という説明だけで受け入れず、リダイレクト、再クロール、連携、深いリンク、運用コストを測ります。

現行構造が不安定、古い技術を露出、重複を作る、新しい情報構造を表現できない場合はURL変更が正当化されます。テーマ、ルート、インポート、フィードを作る前に決めます。

URLを変更する場合は、マスター棚卸し、処置、1対1または根拠ある多対1のマッピング、永久リダイレクト、直接内部リンク、注釈、サイトマップを含むURL構造移行を実施します。 関連資料

複数システムから現状の棚卸しを作る

現在のCMSデータベースだけではウェブサイトの棚卸しになりません。複数のクロール、XMLサイトマップとフィード、分析のランディングページ、Search Console、サーバーログ、被リンクとキャンペーンページ、メディアライブラリを組み合わせます。

• クロール可能なURL。
• XMLサイトマップとフィードの出力。
• 分析のランディングページとSearch Consoleのページ。
• クローラーが今も要求する孤立・旧URLを含むサーバーログ。
• 被リンクとキャンペーンのランディングページ。
• メディアライブラリ、PDF、画像、動画のURL。

すべてのURLにコンテンツエンティティ、テンプレート、インデックス状態、canonical先、トラフィックとリンクの重要度、意図した移行先を割り当てます。これはインポート後の照合台帳です。

ページのコピーだけでなくコンテンツモデルを棚卸しする

コンテンツモデルのマッピングは、項目と関係の移動方法を記述します。

• title、要約、本文、著者、日付、更新日。
• タクソノミー、親、コレクション、カテゴリ、タグ。
• slug、ロケール、canonical上書き、robots制御。
• 画像ソース、alt、キャプション、寸法、トリミング、焦点位置。
• 埋め込みコンポーネントと外部参照。

項目が存在するだけでは不十分です。変換ルール、nullの扱い、エンコード、Markdownまたはリッチテキスト変換、埋め込み、参照をテストします。空で表示される移行項目は失われたコンテンツです。

パリティを受入基準に変える

パリティ要件はテンプレート単位で書きます。商品ページと記事では、コンテンツ、schema、ページネーション、内部リンクの契約が異なります。

各テンプレートに、期待するステータスとインデックス可否、canonical生成、robotsとX-Robots-Tag、title・description・H1・本文のソース、構造化データ、パンくず、ナビゲーション、関連リンクの要件を定義します。

• 期待するステータスとインデックス可否。
• canonical生成ルール。
• robots metaとX-Robots-Tagの動作。
• title、description、H1、主要コンテンツのソース項目。
• 必須schemaタイプと表示プロパティの対応。
• パンくず、ナビゲーション、関連リンクの契約。

保持、削除、改善を分けて決めます。既知の欠陥を復元したり、偶然の欠落を改善として受け入れたりすることを防ぎます。

raw HTMLとレンダリング出力をテストする

レンダリング方式は開発者の実装詳細ではなく、リプラットフォームの判断です。GoogleのJavaScript SEO文書がクロール、レンダリング、処理の関係を説明しています。 関連資料

保護対象テンプレートごとにraw HTMLとレンダリングDOMを比較します。

• ユーザー操作なしで主要コンテンツが存在するか。
• リンクが解決可能な実際のa要素か。
• ステータスがエラー状態と一致し、すべてのルートがソフト404になっていないか。
• canonical、robots、schema、画像、本文がレンダリング後にも存在するか。（<a href>）

Googleはnoindexに遭遇するとレンダリングを省略する可能性があるため、JavaScriptで初期noindexを削除する方法は失敗し得ます。意図したインデックス可否を元のレスポンスに置きます。

canonicalとインデックス制御を保つ

canonicalルールが意図したテンプレートロジックから「すべて自己canonical」へ退化すると、フィルター、追跡パラメーター、ページネーション、印刷ビュー、バリエーションが作る重複を露出します。

各ルールを入力と期待出力として記録します。絶対canonicalのホスト、スキーム、パス、エンコード、対象ページの自己canonical、重複バリエーションのcanonical先、robotsとX-Robots-Tag、非200の動作、サイトマップ包含をテストします。

• canonicalのホスト、スキーム、パス、末尾スラッシュ、エンコード。
• インデックス対象ページの自己canonical。
• 重複バリエーションのcanonical先。
• robots metaとX-Robots-Tagの相互作用。
• 非200レスポンスのcanonical動作。
• サイトマップへの包含。

代表ページにはCanonicalization Checkerを使い、クロールでテンプレートを一括検証します。 関連資料

新しいソースモデルから構造化データを再構築する

新しいテンプレートと項目が変わるため、構造化データは自動移行されないことが多いです。各プロパティを新しいソースへ対応付け、表示されるページ内容を説明しているか確認します。

Googleは開発中にRich Results Testでテストし、デプロイ後はリッチリザルトレポートを監視するよう勧めています。テンプレートや配信の問題がリッチリザルトを壊すことがあるためです。 関連資料

構文と適格性の両方を検証します。検証に通ってもリッチリザルトは保証されず、正しい構文でも間違った商品、記事、パンくず、著者、価格、在庫を説明することがあります。

リンク数ではなく内部リンクの機能を保つ

内部リンクのパリティは、重要ページが同等以上のクロール経路で発見可能であることです。

• 主ナビゲーションと補助ナビゲーション。
• パンくずとカテゴリの祖先。
• 関連商品、関連記事、文脈リンク。
• ページネーションとload-moreの代替。
• フッター、ロケール、マーケット選択。
• 移行本文内のリンク。
• 孤立ページ数。

新デザインはリンク総数を保ちながら、深いページを支えたリンクを削ることがあります。宛先とテンプレートごとに変化を分析します。

ファセット、パラメーター、内部検索を要件にする

プラットフォームは新しいフィルターと並べ替えの挙動を導入しがちです。クロール可能、インデックス可能、canonical化、リンク対象、ブロック対象の組み合わせを記録し、パラメーター順、空結果、複数選択、ページネーション、モバイルをテストします。

新CMSが別のパスを生成するなら、古いプラットフォームの包括的robotsルールをそのままコピーしません。robots除外はクロールを減らせますが、シグナル統合や既存インデックスURLの削除はできません。

Faceted Navigation Auditorでパラメーターの組み合わせを調べ、選んだクロールとインデックス制御を検証します。 関連資料

メディアを第一級URLとして移行する

メディア移行はファイルのコピーだけではありません。画像、動画、PDF、ダウンロードURLを保持または明示的にマッピングします。

• 画像、動画、PDF、ダウンロードURL。
• alt、キャプション、title、周囲の文脈。
• 寸法、形式、レスポンシブバリエーション、安定したソースURL。
• 動画プレーヤー、サムネイル、文字起こし、構造化データ。
• PDFのステータス、canonical、ヘッド。

Googleのモバイルファースト指針は、重要なモバイルとデスクトップのコンテンツ、メタデータ、構造化データ、クロール可能なリソースを同等に保つよう勧めています。画像URLを変えると、新URLが処理されるまで画像検索を一時的に失う可能性もあります。 関連資料

リダイレクトとエラー動作を移行する

レガシーリダイレクトはCMS、htaccess、nginx、アプリ、ロードバランサー、CDNルールに分散していることがあります。ローンチ前に書き出して平坦化します。新プラットフォームは空のリダイレクト表で始まり、蓄積したURL履歴を静かに落としがちです。（.htaccess）

本当に欠落したコンテンツもテストします。プラットフォームは「見つからない」と表示する200テンプレートではなく、本物の404または410を返します。HTTP結果を隠さず、カスタムエラー体験は保ちます。

URLが変わるなら、すべてのマッピング済み旧URLをテストします。Redirect Map Builderでレビュー台帳を作り、Bulk HTTP Status Code Checkerで配信後に確認します。 関連資料 関連資料

ステージングを非公開かつテスト可能にする

ステージングの保護と認証済みクロールを両立します。認証、VPN、ネットワーク制御を優先し、QAシステムへ明示的なアクセスを与えます。一時的なrobotsやnoindexはローンチ削除台帳へ記録し、なくなったことを証明します。

完全な移行先棚卸しからステージングクロールを作り、ナビゲーションだけに限定しません。テンプレートと重要度のコホートでベースラインと比較します。

ローンチ前に移行を照合する

照合は4つの質問に答えます。

1. 意図したすべてのコンテンツエンティティをインポートしたか。
2. すべてのエンティティが期待する公開URLまたは意図したURLなし状態になったか。
3. 期待するすべての移行先がテンプレート契約を通過したか。
4. すべての旧URLに承認済みの処置を割り当てたか。

コンテンツタイプ、ロケール、ステータス、インデックス可否、テンプレート別の件数を使います。サイト全体の合計が一致しても、言語、カテゴリ、著者アーカイブ、メディアが丸ごと欠けていることがあります。

切替とロールバックをリハーサルする

本番に近いデータ量と実際の順序でリハーサルします。

• コンテンツ凍結または差分同期。
• 最終データとメディアのインポート。
• リダイレクトとエッジルールのデプロイ。
• アプリ、キャッシュ、キュー、検索インデックス、フィードの有効化。
• インフラ変更時のDNSまたはロードバランサー切替。
• 本番スモークテストと監視開始。

データベースのロールバックが難所です。新スキーマで注文、アカウント、コメント、コンテンツが作成された後にアプリコードだけ戻すと、データを失ったり壊したりします。技術的ロールバックと同時にロールフォワード修正と照合を定義します。

本番を依存関係の順に検証する

本番検証はシステム全体の失敗からページ詳細へ進めます。

1. DNS、TLS、ステータス、ホスト可用性。
2. robots.txt、認証、WAF、全体robots指示。
3. ホームページと保護対象テンプレートごとの代表ページ。
4. canonical、hreflang、schema、リンク、アセット、レンダリング。
5. 全リダイレクトと移行先の検証。

個別URLより先にテンプレート欠陥を直します。1つの不正なcanonical partialが数百万ページへ影響することがあります。

ローンチ後はコホートで監視する

コホート監視は、何が変わったかでURLをまとめます。同一URL、リダイレクト済み、商品、カテゴリ、記事、ロケール、レンダリングテンプレート、メディア、ファセット、被リンク上位ページなどが有用です。

成功レスポンス、リダイレクト失敗、canonical不一致、インデックス可否、レンダリング完全性、内部リンク、サイトマップ、Google選択canonical、クリック、表示、コンバージョン、クローラー活動を追跡します。比較期間を揃え、更新へ注記します。

集計トラフィックだけでは、1つの新テンプレートが失敗し別のテンプレートが成長したことを見分けられません。

AI要約

• CMS移行はページ生成システムを変え、URL、レンダリング、デザイン、アーキテクチャ、ホスティング、連携も変え得ます。
• ルーティングとインポートを作る前に、同一URLか変更URLかを決めます。
• 棚卸し、パリティ契約、rawとレンダリングの比較、照合、ロールバックを本番前に行います。
• 必須欠陥と任意改善を分け、ローンチ後はテンプレートとコホートで監視します。（404）

公式ドキュメント

Google

URL変更を伴うサイト移行、ホスティング変更、JavaScript SEO、構造化データ、モバイルファースト、robotsとサイトマップの公式資料を参照します。 関連資料 関連資料 関連資料 関連資料 関連資料 関連資料

Bing

BingのWebsite Migration資料はCMS移行、監査、リダイレクト、ログ、監視を扱います。古いSite Move Toolの情報は現行Bing Webmaster ToolsとIndexNowで補います。 関連資料 関連資料

出典からの引用

• “Plan your changes to your site one after the other, not everything at the same time.” (翻訳)「サイトの変更は、一度にすべて行わず、1つずつ計画してください。」 Google Search Central。 ガイダンスへ移動
• 言い換え: 変更したURLについて、Googleのサイト移行文書は各移行先がcanonicalとして自分自身を示すべきだと説明しています。 canonicalガイダンス
• “When Google encounters the noindex tag, it may skip rendering and JavaScript execution” (翻訳)「Googleがnoindexタグに遭遇すると、レンダリングとJavaScriptの実行を省略することがあります。」 Google Search Central。 noindexガイダンスへ移動
• 言い換え: Googleは、ユーザーとクローラーに配信しやすい選択肢として、サーバーサイドレンダリングまたは事前レンダリングを今でも勧めています。 レンダリングガイダンス
• “Be sure to check your structured data using the Rich Results Test during development”. (翻訳)「開発中はリッチリザルトテストで構造化データを必ず確認してください。」 Google Search Central。 検証ガイダンスへ移動

CMS移行チェックリスト

スコープと決定

• CMS、データ、テンプレート、レンダリング、アーキテクチャ、URL、インフラ、分析、連携の変更層を列挙する。
• ルート実装前に同一URLか変更URLかを承認する。
• 保持、削除、改善の決定を分ける。

棚卸しと移行

• クロール、サイトマップ、ログ、分析、Search Console、被リンク、フィードを組み合わせる。
• メディア、ファセット、ページネーション、内部検索、リダイレクト、API、アプリを棚卸しする。
• すべてのコンテンツ項目、関係、分類、ロケール、ワークフローをマッピングする。

ステージングQA

• 認証済みクローラーがステージングへアクセスでき、公開発見は防がれている。
• すべての保護対象テンプレートでraw HTMLとレンダリングDOMをテストする。
• ステータス、title、見出し、本文、canonical、robots、hreflang、schemaを比較する。
• ナビゲーション、リンク、アセット、モバイル出力も比較する。

ローンチと監視

• 最終コンテンツ／データ同期と凍結の順序をリハーサルする。
• アプリとデータベースのロールバックまたはロールフォワードをリハーサルする。
• 一時ステージング制御を削除台帳に入れる。
• 本番をシステム、テンプレート、URLの順で検証する。

リプラットフォーム契約

4つの台帳を連携します。

1. エンティティ台帳。 移行するすべてのコンテンツ記録と関係。
2. URL台帳。 すべての旧URLと、同一、移動、統合、廃止、除外の結果。
3. テンプレート契約。 生成ページの動作と合否テスト。
4. 証拠台帳。 インポート、レンダリング、リダイレクト、監視の確認結果。

台帳の内容が一致したときだけ移行を照合済みとします。期待URLのないコンテンツエンティティや、所有エンティティも意図した動作もない公開URLはレビュー対象です。

パリティマトリクス

CMS移行にURL移行ワークストリームは必要か

損失を生むリプラットフォームの失敗

プラットフォーム構築後にURLを選ぶ。 ルーティング、インポート、テンプレート、フィード、リダイレクトが偶然の既定値に固まるため失敗します。実装前に保持か変更かを決めます。

見た目の一致をSEOパリティと呼ぶ。 同じデザインでもステータス、raw HTML、canonical、robots、リンク、schema、モバイル、エラーは異なり得ます。rawとレンダリングのテンプレート契約をテストします。

サイトマップだけを移行する。 サイトマップは、トラフィックやリンクを受ける孤立、リダイレクト、旧、パラメーター、アセットURLを省きます。クロール、ログ、分析、Search Console、被リンク、フィードを組み合わせます。

すべての改善をローンチで行う。 コンテンツ、アーキテクチャ、レンダリング、URL、デザインを同時に変えると回帰診断が難しくなります。必須欠陥と後続改善を分けます。

ロールバックをコードデプロイと扱う。 新スキーマへの書き込み、注文、アップロード、コンテンツ編集はアプリのロールバックで戻らないことがあります。データ照合とロールフォワードも計画します。

よくあるリプラットフォーム失敗

移行先の件数が元の棚卸しより少ない

原因候補： インポート失敗、除外状態、ロケール欠落、未対応タイプ、エンティティ重複排除。修正： 1つの合計ではなく、コンテンツタイプ、ロケール、ワークフロー状態、テンプレートで照合します。

ページは200だがクロールで本文を失う

原因候補： クライアントレンダリング、リソースブロック、API失敗、操作後だけの読み込み、hydrationエラー。修正： 代表ページでrawとレンダリングHTML、コンソール／ネットワークエラー、URL検査のレンダリング表示を比較します。

Googleが予想外のcanonicalを選ぶ

原因候補： コピーされたcanonical、旧またはステージング先、重複ルート、内部リンク競合、サイトマップ競合、実質的に変わった本文。修正： テンプレートcanonical、直接リンク、リダイレクト、サイトマップを意図URLに揃えます。

カテゴリや商品ページがクロールトラップになる

原因候補： 新しいファセットルート、パラメーター順、無限の組み合わせ、カレンダーパス、クロール可能な内部検索。修正： 許可する組み合わせを定め、有用なページだけリンクし、空状態を正直に返し、canonicalまたはインデックス制御を適用します。

レガシーリンクが404を返し始める

原因候補： 旧CMS外にあったリダイレクト、または新ルールエンジンの順序変更。修正： すべての旧層からルールを統合し、チェーンを平坦化し、過去URLの完全な棚卸しをテストします。

構造化データは通るが別エンティティを説明する

原因候補： 項目マッピングの誤り、親データやプレースホルダー、古いキャッシュを出すテンプレート。修正： マークアップを表示内容とソース記録に比較します。構文検証だけでは意味の正確さを証明できません。

CMS移行QAのツール

• Staging vs. Production SEO Diffはステージングと本番の対応サンプルを比較します。 関連資料 関連資料 関連資料 関連資料 関連資料 関連資料 関連資料 関連資料
• SEO Migration Planner & Validatorは、マップレビュー、リダイレクト確認、旧URLステータス、サイトマップ比較をまとめます。
• Redirect Map Builderは正確・不確実・統合マッピングをレビューします。
• Bulk HTTP Status Code Checkerは公開後のステータスを確認します。

CMS移行が正しく出荷されたことを証明する

エンティティからURLへの照合テスト

• 実行するテスト： ソースエンティティ出力、移行先エンティティ出力、期待URL台帳、移行先クロールを安定したコンテンツIDで結合する。
• 期待結果： すべての対象エンティティに承認済み状態とURLがあり、すべての公開移行先に所有エンティティがある。

テンプレート契約テスト

• 実行するテスト： 保護対象テンプレートごとの層化サンプルをクロール・レンダリングし、ステータス、本文、メタデータ、canonical、指示、schema、リンク、アセット、モバイル出力を比較する。
• 期待結果： 保持要件は通過し、差分は承認済みの意図した変更として説明できる。

リダイレクトとエラー状態のテスト

• 実行するテスト： すべての旧URLをBulk HTTP Status Code Checkerまたは完全クロールへ通し、既知の欠落ルートをテストする。
• 期待結果： 移動URLは1つの永久リダイレクトで承認済み等価先へ到達し、欠落URLは404または410になります。

データを意識したロールバックリハーサル

• 実行するテスト： 切替後の書き込みを含む本番同等リハーサルで文書化したロールバックを実行する。
• 期待結果： コード、schema、コンテンツ、注文、セッション、アップロード、キュー、連携が定義済みの一貫した状態になります。

時間を使う価値のあるリソース

関連する私の執筆

• A Website Migration Takes More Than a Checklist to Be Successful（Ahrefs）— 共有プロセス、ステージング、パリティ、監視。
• Redirects for SEO（Ahrefs）— リダイレクトの設計と移行への適用。

このサイトの関連ガイド

• Site Migrations — 移行タイプ、共通リスク、普遍的な手順。
• Website Migration Checklist — プロジェクト用の順序。
• Website Redesign SEO Checklist — URLを維持したままテンプレートを変更する場合に適用します。
• JavaScript SEO — レンダリングと発見を詳しく説明します。

業界の資料

• GoogleのURL変更サイト移行、JavaScript SEO basics、Bingの移行資料など、一次資料を確認します。 関連資料 関連資料 関連資料 関連資料 関連資料 関連資料

CMS移行とリプラットフォームSEOを自分で確認する

スコープ、パリティ、レンダリング、照合、ロールバックに関する5つの確認問題です。

変更履歴