WordPressで長年運用してきたサイトをMovable Typeへ移行したいが、「検索順位が落ちないか不安」「具体的な手順がわからない」という悩みをお持ちの担当者の方は少なくありません。本記事では、WordPressからMovable Type（MT）へのCMS移行を実務の視点で解説します。コンテンツのエクスポート・インポートからURLのリダイレクト設計、Googleインデックスの維持、移行後のSEOモニタリングまで、工程ごとに具体的な手順を示します。

この記事でわかること

• WordPressとMovable Typeの移行前に整理すべき情報の種類と確認方法
• コンテンツのエクスポート・インポートと画像ファイルの移行手順
• URLが変わる場合のリダイレクト設計とSEO評価を引き継ぐための実装方法
• Search Consoleを使った移行後のインデックス状況の確認とモニタリング方法
• 移行時によく起きる問題と対処法

1. なぜWordPressからMovable Typeへ移行するのか

WordPressは世界中で広く使われているCMSですが、運用を続けるなかでセキュリティリスク、プラグイン管理の煩雑さ、大規模サイトでのパフォーマンス低下などの課題に直面する組織が増えています。特に金融機関・官公庁・製造業の大手企業・大学などでは、情報セキュリティポリシーの強化を背景に、より堅牢なCMSへの移行が求められるケースが目立ちます。

Movable TypeはWordPressと異なり、コンテンツ更新時に静的HTMLファイルを生成・保存する「静的出力」方式を採用しています。この仕組みにより、公開側のWebサーバーとデータベースの常時接続が不要となり、SQLインジェクションやXSSといった攻撃の経路を構造的に排除できます。表示速度の高速化、Core Web Vitalsスコアの改善という観点でも、SEOへの好影響が期待できます。

WordPressとMovable Typeの機能・コスト・セキュリティ・向いている業種の詳細な比較については、「Movable TypeとWordPress、どちらを選ぶべき？業種・規模・要件別に整理」をあわせてご参照ください。

1-1. 移行を検討すべき主なケース

WordPressからMovable Typeへの移行が有効な場面は、大きく分けて以下のとおりです。

セキュリティ要件の強化：情報システム部門またはセキュリティ監査によって、動的CMSの利用を制限または廃止する方針が決まったケース。特に金融機関・医療機関・官公庁では、静的出力による構造的安全性が選定理由になりやすい。

プラグイン依存の解消：WordPressでは多数のプラグインを導入するほどセキュリティ脆弱性リスクが増え、バージョン不整合によるサイト障害も起きやすくなる。Movable Typeはコア機能が充実しており、外部プラグインへの依存度を大幅に下げられる。

大規模・マルチサイト運用への対応：グループ会社・複数拠点・学部ごとのサイトを一元管理したい場合、Movable Type Advancedのロール管理・承認ワークフロー・マルチサイト機能が有効に機能する。

表示速度・SEOパフォーマンスの改善：静的HTMLによる高速配信はCore Web Vitalsの改善に直結する。LCP（最大コンテンツ描画時間）の短縮が期待でき、検索ランキングへのプラスの影響が見込まれる。

1-2. 移行の基本的な流れ

CMS移行は大きく5つのフェーズで構成されます。

フェーズ1：現状棚卸しと要件定義。既存WordPressサイトのURL構造・ページ数・コンテンツ種別・画像・リンクを整理し、移行範囲を確定する。

フェーズ2：Movable Type環境の構築。サーバー設定・MTのインストール・テンプレート設計・権限設定を行う。並行してステージング環境を用意し、本番への影響をゼロに保つ。

フェーズ3：コンテンツ移行。WordPressからエクスポートしたデータをMovable Typeにインポートし、画像・ファイルを移行。テンプレートとの整合性を確認する。

フェーズ4：リダイレクト設計と動作確認。URLが変わるページのリダイレクトを設定し、全ページの表示・リンク・フォームを確認。SEO観点のチェックも実施する。

フェーズ5：本番切り替えと移行後モニタリング。DNS切り替えまたはサーバー切り替えを実施し、Search Consoleでインデックス状況を継続的に監視する。

2. 移行前の準備と現状棚卸し

移行作業の成否は、事前準備の精度で決まります。「とりあえず移行してみる」というアプローチではSEO評価の損失や大規模なリンク切れを招く可能性があります。以下の項目を体系的に整理することが、スムーズな移行の前提条件です。

2-1. 既存WordPressサイトの棚卸し

まずWordPressサイトの全体像を把握します。確認すべき項目は次のとおりです。

URL構造の確認：WordPressのパーマリンク設定（日付型・スラッグ型・ID型など）を確認し、各ページのURLを一覧化する。記事投稿・固定ページ・カテゴリページ・タグページ・添付ファイルページなど、種別ごとに整理する。

ページ数・コンテンツ量の把握：WordPressの管理画面「投稿一覧」「固定ページ一覧」で総数を確認する。ページ数が数百〜数千規模になる場合は、移行ツールや自動化スクリプトの活用を検討する。

画像・メディアファイルの確認：WordPressのメディアライブラリに登録されている画像・PDF・動画ファイルの数と総容量を把握する。特にWordPressはアップロード時に複数サイズのサムネイルを自動生成するため、実際のファイル数は多くなる。

プラグイン・カスタム機能の洗い出し：使用中のプラグインとその役割を一覧化する。フォーム・EC機能・会員管理・API連携など、Movable Typeでの代替手段が必要な機能を特定しておく。

2-2. SEO関連情報の整理

移行によるSEO評価の損失を防ぐために、以下の情報を移行前に必ず収集・保存します。

Google Search Consoleのデータ確認：現在のインデックス数・検索パフォーマンス（クリック数・表示回数・平均掲載順位）を確認し、スクリーンショットまたはCSVエクスポートで保存する。移行後の変動を比較する基準値として使用する。

被リンク（バックリンク）の把握：外部サイトからリンクを受けているURLを特定する。Google Search ConsoleのリンクレポートやAhrefsなどの外部ツールで主要な被リンクURLを抽出し、これらのページのリダイレクト設定を優先する。

既存サイトマップの保存：XMLサイトマップに登録されているURLの一覧を保存する。WordPressで使用しているSEOプラグイン（Yoast SEO、All in One SEO Packなど）が生成するサイトマップURLを確認し、記録しておく。

メタデータの確認：各ページのtitleタグ・meta descriptionをエクスポートツールまたはスプレッドシートで一覧化する。Movable Typeのテンプレートで同等の設定を再現するための元データとして活用する。

2-3. 移行スコープの確定

すべてのコンテンツを移行するか、特定のコンテンツのみを移行するかを決定します。大規模サイトでは、アクセス数の少ない古いコンテンツをクロールさせず、重要なページのみ移行するという判断も有効です。ただし移行しないページのURLには適切なリダイレクト（301）またはnoindexの設定が必要です。

3. コンテンツのエクスポートとインポート

3-1. WordPressからのエクスポート

WordPressのコンテンツエクスポートは、管理画面から実施できます。

ツール→エクスポートにアクセスし、「すべてのコンテンツ」または「投稿」「固定ページ」など必要な種別を選択してダウンロードします。生成されるのはWordPress独自のXML形式（WXR形式）のファイルです。ページ数が多い場合はファイルサイズが大きくなり、PHPのメモリ制限・実行時間制限でタイムアウトするケースがあります。その場合は期間を絞って分割エクスポートするか、WP-CLIコマンド（wp export）を使用します。

注意点として、このエクスポートには記事・固定ページのテキストコンテンツとカテゴリ・タグ情報が含まれますが、画像・メディアファイルのバイナリデータは含まれません。画像は別途FTPまたはSFTPでサーバーからダウンロードする必要があります。

3-2. Movable Typeへのインポート

Movable Typeは、WordPress（WXR）形式のインポートには非対応です。Movable Type独自のインポート形式（MTエクスポート形式）に変換する必要があります。

変換の方法は主に2つです。

方法1：変換ツールを使用する。WordPressのWXRをMTエクスポート形式に変換するスクリプトやツールが公開されています。Perlスクリプトやオープンソースのコンバーターを使用してWXRをMTフォーマットに変換したうえで、Movable Typeの管理画面（ツール→インポート）からインポートします。

方法2：APIを経由してデータを移行する。Movable TypeのData API（REST API）を使用し、プログラム的にコンテンツを登録する方法です。大規模移行や高度なデータ変換が必要な場合に有効ですが、開発工数がかかります。

インポート後の確認事項として、記事タイトル・本文・カテゴリ・公開日時・スラッグが正確に取り込まれているかを複数のサンプルページで確認します。

3-3. 画像・メディアファイルの移行

画像ファイルの移行はエクスポート・インポートとは別工程です。

まずWordPress側のサーバーから、FTPまたはSFTPでwp-content/uploadsディレクトリをダウンロードします。次に、Movable Type側のサーバーの公開ディレクトリ（通常はmt-static/またはサイト設定で指定したディレクトリ）に画像ファイルをアップロードします。

WordPressとMovable Typeでは画像のパス構造が異なります。WordPressは「/wp-content/uploads/年/月/ファイル名」という構造ですが、Movable Typeでは設定によってパスが変わります。移行後の画像パスに合わせて、記事本文中のimgタグのsrc属性を一括置換する必要があります。本文のURL置換にはSearch Regexなどのツールやデータベース直接操作で対応します。

4. URL変更とリダイレクト設計

CMS移行においてSEO評価の維持に最も重要な工程が、リダイレクト設計です。URLが変わるページに適切な301リダイレクトを設定しないと、被リンクのSEO評価が引き継がれず、検索順位の大幅な低下を招くことになります。

4-1. WordPressとMovable TypeのURL構造の違い

WordPressとMovable TypeではデフォルトのURL構造が異なります。

WordPressはパーマリンク設定によって「/archives/123」（ID型）、「/2024/01/記事名/」（日付+スラッグ型）、「/記事名/」（スラッグ型）など複数の形式を選択できます。

Movable Typeはデフォルトで「/年/月/記事名.html」という静的HTMLファイルとして出力します。テンプレートのArchivesセクションでパスをカスタマイズすることも可能です。

移行時の目標は、可能な限りWordPress側のURLに近い形のパスをMovable Typeでも実現し、URLの変更を最小化することです。これにより必要なリダイレクト数を減らし、リダイレクトチェーンによるページランクの損失を抑えられます。

4-2. リダイレクト設計の基本方針

リダイレクト設計では以下の原則を守ります。

必ず301（恒久）リダイレクトを使用する：Googleは302（一時）リダイレクトでは評価を引き継がないため、恒久的なURL変更には必ず301を使用します。

1対1の対応を原則とする：旧URLから新URLへの対応を1対1でマッピングします。複数の旧URLを1つの新URLに集約する場合でも、各旧URLに個別の301設定を行います。

リダイレクトチェーンを作らない：「旧URL→中間URL→新URL」のような多段リダイレクトはページランクの損失につながります。常に最終URLへ直接リダイレクトするよう設定します。

重要ページを優先する：被リンクが多いページ・SEO的に重要なランディングページ・ナビゲーションで参照されているページを優先してリダイレクト設定を行います。

4-3. .htaccessによるリダイレクト実装

ApacheサーバーではWordPressが配置されていたサーバー（または同一サーバーで旧URLが生き続ける場合）の.htaccessにリダイレクトルールを記述します。

特定のページを個別にリダイレクトする場合は、以下のように記述します。

Redirect 301 /旧パス/記事名.html https://www.example.com/新パス/記事名/

パターンマッチングで複数ページをまとめてリダイレクトする場合は、mod_rewriteを使用します。

RewriteEngine On

RewriteRule ^archives/([0-9]+)\.html$ /column/記事スラッグ/ [R=301,L]

ページ数が多い場合は、旧URLと新URLの対応表（CSVなど）を作成し、スクリプトで.htaccessのリダイレクトルールを自動生成する方法が効率的です。

4-4. Nginx環境でのリダイレクト

NginxサーバーではNginxの設定ファイル（通常はserver {}ブロック内）にreturnまたはrewriteディレクティブでリダイレクトを記述します。

location = /旧パス/記事名.html {

    return 301 https://www.example.com/新パス/記事名/;

}

Nginxの場合は設定変更後にsudo nginx -t（設定テスト）とsudo nginx -s reload（リロード）が必要です。

4-5. リダイレクト設定後の動作確認

リダイレクトの設定後は、必ず動作確認を実施します。

確認ツールとして、curlコマンドやブラウザの開発者ツール（Networkタブ）でHTTPステータスコードが301になっていることを確認します。Screaming FrogなどのSEOクローラーで全ページを一括クロールし、リダイレクト漏れや404エラーを検出することも有効です。

本番切り替え前に、ステージング環境でリダイレクトリストの全URLについて動作テストを実施します。ページ数が多い場合はcurlをループ処理するシェルスクリプトで自動化します。

5. インデックスの維持とSearch Consoleの活用

5-1. XMLサイトマップの再提出

Movable Type側でサイトが公開できたら、まず新しいXMLサイトマップを作成し、Google Search Consoleに提出します。

Movable Typeではテンプレートにサイトマップ生成用のテンプレートを追加することで、XMLサイトマップを自動生成できます。提出するサイトマップには現在公開中の全ページのURLを含め、削除・非公開のページは含めないようにします。

Google Search Consoleの「サイトマップ」メニューからサイトマップのURLを入力して送信します。送信後、Googleによるクロールとインデックス処理が始まります。インデックスへの反映には通常数日〜数週間かかります。

5-2. URLの変更通知と旧URLの削除申請

移行によってURLが変更になった場合、Google Search Consoleの「URL検査」ツールで主要ページの新URLを個別にインデックス登録リクエストすることで、クロールの優先度を高めることができます。

すでにインデックスされている旧URLについては、301リダイレクトが正しく機能していれば、Googleは自動的に新URLへ評価を引き継ぎます。ただし古い静的HTMLファイルが新サイトと同じドメインに残っている場合は、重複コンテンツとして評価されるリスクがあります。旧WordPressのファイルはリダイレクト設定後に速やかに削除するか、noindexを設定します。

5-3. 移行後のモニタリング指標と確認サイクル

移行後は以下の指標を定期的に確認します。

インデックス数の推移：Search Consoleの「カバレッジ」レポートで有効なインデックス数と除外URLを確認する。移行前の水準に戻るまでの推移を週単位で追跡する。

検索パフォーマンスの変動：「検索パフォーマンス」レポートでクリック数・表示回数・平均掲載順位・CTRの変動を確認する。移行直後は一時的な変動が生じることがあるが、リダイレクトが正しく機能していれば2〜4週間程度で安定する傾向がある。

404エラーの検出：「カバレッジ」レポートの「除外」タブで「見つかりませんでした（404）」の件数を確認する。404が多発している場合はリダイレクト設定の漏れを疑い、Screaming FrogなどでURLを再クロールして修正する。

Core Web Vitalsの変化：「Core Web Vitals」レポートでLCP・CLS・INPを確認する。Movable Typeの静的出力に切り替えることで改善が期待できるが、CDN設定や画像最適化が未実施の場合は効果が出ない場合もある。

5-4. モバイルフレンドリーとアクセシビリティの確認

CMS移行に伴ってテンプレートが刷新される場合、モバイルフレンドリーの確認が必要です。Google Search ConsoleのモバイルユーザビリティレポートやPageSpeed Insightsを使ってスマートフォン表示の問題がないかを確認します。

Movable TypeはWebアクセシビリティ対応のためのテンプレート構造を採用しやすく、セマンティックなHTMLマークアップが実現しやすい環境です。フォー・クオリアではWebアクセシビリティ診断サービスも提供しており、移行後のテンプレートの品質向上を支援しています。

6. 移行時のよくある問題と対処法

6-1. 文字化けとエンコーディングの問題

コンテンツ移行時に発生しやすいのが文字化けです。WordPressはUTF-8を標準として使用していますが、MTへのインポート時にエンコーディングが正しく処理されないとタイトルや本文の日本語が化けることがあります。

対処法として、変換・インポートの各ステップでファイルのエンコーディングをUTF-8に統一します。Perlスクリプトを使用する場合はbinmode設定でUTF-8を明示します。インポート後は必ずサンプルページで文字化けがないかを確認します。

6-2. 画像パスのずれ

Movable Typeへの移行後、記事本文内の画像が表示されないケースが多発します。原因はWordPressのuploadsディレクトリ構造とMovable Typeの画像ディレクトリが異なるため、本文のimgタグのsrc属性が旧パスを参照したままになっていることです。

対処法として、Movable Typeのデータベースに格納されている本文のURLを一括置換します。MySQLであればUPDATE文でmt_entryテーブルのentry_text・entry_text_moreカラムの画像パスを置換します。作業前には必ずデータベースのバックアップを取得します。

6-3. カテゴリ・タグ構造の不整合

WordPressとMovable Typeではカテゴリ・タグの管理方式が異なります。WordPressは記事に複数カテゴリを自由に付与できますが、Movable Typeではサイトのディレクトリ構造との連動が密接です。

対処法として、移行前にWordPressのカテゴリ構造をスプレッドシートで整理し、Movable TypeのカテゴリIDと対応付けるマッピングテーブルを作成します。自動変換では吸収できない部分は手動で修正します。

6-4. テンプレートとデザインの再実装

WordPressのテーマ（PHPベース）はそのままMovable Typeでは使用できません。Movable TypeはPerl/テンプレートタグ言語を使用するため、デザインは再実装が必要です。

対処法として、移行前にWordPressサイトの全ページのスクリーンショットを保存し、デザインの基準として活用します。主要なページレイアウト・コンポーネント（ヘッダー・フッター・サイドバー・カード型記事一覧など）を一覧化し、Movable Typeのテンプレートで再現する作業量を事前に見積もります。

6-5. 旧WordPressファイルと新サイトの競合

同一ドメインで移行する場合、WordPressが生成した静的HTMLファイルとMovable Typeが生成する静的HTMLファイルのURLが重複するとどちらのファイルが配信されるか不明になります。

対処法として、Movable Typeへの切り替え直後にWordPressで生成した静的HTMLファイルをFTPで削除します。WordPressのリライトルール（.htaccessのWordPress用ルール）はMovable Type運用では不要なため、適切に整理します。

7. 移行を専門会社に委託するメリットとフォー・クオリアの対応

7-1. 自社対応と外部委託の判断基準

WordPressからMovable Typeへの移行は、サーバー設定・データベース操作・テンプレート設計・SEO設計と多岐にわたる専門知識が求められます。情報システム担当者やWeb担当者が1〜2名体制の組織では、移行作業の実施と通常業務の並行が困難になるケースが多くあります。

外部委託を検討すべき目安は次のとおりです。

ページ数が300ページを超える場合は、リダイレクトマッピングの作成だけでも相当な工数がかかります。移行後のSEOモニタリングを含めた継続サポートが必要な場合や、テンプレートのフルスクラッチ再実装が必要な場合も、専門会社への依頼が現実的です。

7-2. フォー・クオリアのCMS移行サポート

フォー・クオリアは、Movable TypeのProNet認定パートナーとして、WordPressからMovable Typeへの移行支援に対応しています。

移行支援の主な対応範囲は以下のとおりです。

現状棚卸しと移行計画の策定：WordPressサイトのURL構造・コンテンツ量・SEO状況を調査し、移行スケジュールとリスクを整理します。

Movable Type環境の構築・テンプレート設計：要件定義に基づいたMovable Typeのインストール・サーバー設定・テンプレート設計を担当します。既存デザインの再現から新規デザイン制作まで対応します。

コンテンツ移行と画像ファイル移行：エクスポート・変換・インポートの一連作業、画像パスの修正、カテゴリ・タグ構造の整理を実施します。

リダイレクト設計と実装：旧URLから新URLへの301リダイレクトのマッピングと.htaccess・Nginx設定の実装、クロールによる動作確認を行います。

移行後SEOモニタリング：Search Consoleでのインデックス状況確認・404エラー対応・Core Web Vitalsの改善提案まで移行後の安定稼働を支援します。

制作実績20,000件以上の経験をもとに、業種・規模・セキュリティ要件に応じた最適なCMS移行をご提案します。WordPressからMovable Typeへの移行を検討されている方は、まずはお気軽にご相談ください。

8. まとめ

WordPressからMovable Typeへのアクセスを維持したまま移行するためには、以下のポイントが重要です。

移行前の現状棚卸しを徹底することが最初のステップです。URLの一覧化・被リンクの把握・Search Consoleのデータ保存を行い、移行後の比較基準を明確にします。

コンテンツのエクスポート・インポートはWordPressのWXR形式をMTエクスポート形式に変換するプロセスを経ます。画像ファイルの移行とパス修正は別工程として計画的に実施します。

リダイレクト設計はSEO維持の核心です。URLが変わるすべてのページに1対1の301リダイレクトを設定し、リダイレクトチェーンを作らないことが原則です。

Search Consoleを活用して、新サイトマップの提出・URLの変更通知・インデックス数とパフォーマンスのモニタリングを移行直後から継続的に実施します。

移行時のよくある問題（文字化け・画像パスずれ・カテゴリ不整合・旧ファイルとの競合）は、事前の設計と確認工程で大半を防げます。

CMS移行は一度実施すると覆すことが難しい大規模プロジェクトです。移行後にセキュリティの向上・表示速度の改善・運用負荷の最適化を実現するためには、計画段階からの専門的なサポートが効果的です。フォー・クオリアでは、Movable TypeのProNet認定パートナーとして移行計画から構築・移行後の運用まで一貫して支援しています。CMS移行をご検討の際は、ぜひご相談ください。

 まずはお気軽に
ご相談ください