WordPressからMovable Typeへの移行 ── 「逆方向」だからこそ整理しておきたい実務手順

この記事は、WordPressで作った中小企業・士業事務所のサイトを運用している担当者と、その移行を請け負う制作会社の方に向けて、「移行すべきかどうかの判断基準」と「実際の移行手順」の両方をまとめたものです。

CMSの移行というと「Movable TypeからWordPressへ」の記事ばかりが見つかります。 しかし実務では、WordPressからMovable Type(またはMovableType.net)へという逆方向の移行が合理的になるケースが確かにあります。 逆方向ゆえに情報が少ないので、この記事で移行判断と実務手順をまとめて整理します。

「WordPressで作ったサイトはあるが、更新するのは月に数回。それなのに、本体やプラグインの更新通知への対応に追われている」──中小企業や士業事務所のサイトでよくある状態です。

サイトの目的が集客と信頼形成で、更新はお知らせとコラムが中心。そうしたサイトにとって、CMSに求めるものは拡張性よりも、手がかからないことと、壊れにくいことです。この記事では、WordPressからMovable Typeへの移行を検討する際の判断材料と、実際の移行手順を解説します。

この記事で使う用語

発注する側の担当者の方にも読んでいただけるよう、専門用語を先に整理しておきます。

1. まず結論

• WordPress→Movable Typeの移行は技術的に確立しており、MovableType.netのインポート機能はWordPress形式のエクスポートファイル(XML)に対応しています。記事・固定ページに加え、本文やカスタムフィールドから参照されている画像・ファイルも取り込めます。
• 移行が合理的なのは、更新頻度が低め・更新者が少人数・拡張要件が固定的なサイトです。動的な会員機能やECをWordPressプラグインで組んでいるサイトには向きません。
• 移行の成否を分けるのはCMSの機能差よりも、URL設計と301リダイレクト、そしてプラグイン機能の代替方針です。ここを事前に決めずにデータだけ移すと、SEOと業務の両方でつまずきます。
• カスタム投稿タイプやカスタマイズされたXMLは、そのままでは読み込めない場合があり、変換・手直しの工数を見込みます(公式マニュアルにも明記されています)。

この記事の知識マップ

WordPressは更新頻度の低いサイトでも本体・プラグインの継続的な更新対応が避けられず、プラグインは脆弱性の主要因になりやすい。移行先のMovable Type、特にSaaS型のMovableType.netは静的パブリッシングとサービス側でのセキュリティ対応によってその負担を軽減し、専任のWeb担当者がいない小規模環境に向く。データ移行はWordPressがエクスポートするWXR形式のXMLをMovableType.netのインポート機能が読み込む形で進むが、カスタム投稿タイプはそのままでは読み込めないことがあり、カテゴリー階層もエクスポートファイルの書き換えが要る。移行の成否を左右するのはURLの扱いで、全URLの棚卸しと新旧URL対応表の確定を301リダイレクトより先に行い、公開後はXMLサイトマップとSearch ConsoleでSEO評価の下落を確認する順序が推奨される。

flowchart LR
    accTitle: WordPressからMovable Typeへの移行の知識マップ
    accDescr: WordPressのプラグイン運用が抱える脆弱性リスクを静的パブリッシングとSaaS運用が軽減すること、WXR形式のエクスポートとインポートによるデータ移行の依存関係、カスタム投稿タイプやカテゴリー階層で起きる変換の必要性、そしてURL棚卸し・対応表・301リダイレクトの順序とSearch Consoleによる検証がSEO評価の下落を防ぐ流れを示す図。
    wordpress["WordPress"]
    movabletype_net["MovableType.net"]
    movable_type["Movable Type(ソフトウェア版)"]
    small_office["管理者が実質不在の小規模環境"]
    wordpress_plugin["WordPressプラグイン"]
    plugin_vulnerability["プラグインの脆弱性"]
    static_publishing["静的パブリッシング"]
    wp_export["WordPressのエクスポート機能"]
    wxr_format["WXR形式(WordPress eXtended RSS)"]
    mt_import["MovableType.netのインポート機能"]
    custom_post_type["カスタム投稿タイプ"]
    category_hierarchy["カテゴリー階層"]
    permalink["パーマリンク"]
    url_mapping_table["URL対応表(リダイレクトマッピング)"]
    url_inventory["URL棚卸し表"]
    redirect_301["301リダイレクト"]
    seo_ranking_loss["SEO評価の下落"]
    xml_sitemap["サイトマップ"]
    search_console["Google Search Console"]
    plugin_feature_replacement["プラグイン機能の代替"]
    movable_type -->|"の後継"| wordpress
    movabletype_net -->|"推奨される対応"| small_office
    wordpress -->|"利用する"| wordpress_plugin
    wordpress_plugin -.->|"原因になり得る"| plugin_vulnerability
    movabletype_net -->|"軽減する"| plugin_vulnerability
    movable_type -->|"利用する"| static_publishing
    static_publishing -.->|"軽減する"| plugin_vulnerability
    wordpress -->|"利用する"| wp_export
    wp_export -->|"利用する"| wxr_format
    movabletype_net -->|"利用する"| mt_import
    mt_import -.->|"利用する"| wxr_format
    mt_import -.->|"前提とする"| wp_export
    custom_post_type -.->|"両立しない"| mt_import
    category_hierarchy -->|"で構成できる"| mt_import
    wordpress -->|"利用する"| permalink
    url_mapping_table -->|"前提とする"| permalink
    url_inventory -->|"より先に行うべき"| url_mapping_table
    url_mapping_table -->|"より先に行うべき"| redirect_301
    redirect_301 -->|"軽減する"| seo_ranking_loss
    xml_sitemap -->|"推奨される対応"| seo_ranking_loss
    seo_ranking_loss -->|"で確認できる"| search_console
    movabletype_net -.->|"前提とする"| plugin_feature_replacement
    plugin_feature_replacement -->|"前提とする"| wordpress_plugin

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全23件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. なぜ「逆方向」の移行が起きるのか

WordPressは世界で最も使われているCMSで、それ自体は優れた選択肢です。一方で、動的CMSであるがゆえの運用負担があります。

• 更新対応が止められない。本体・テーマ・プラグインの更新は継続的に発生し、放置はそのままリスクになります。CMSやプラグインの脆弱性については、IPAが繰り返し注意喚起を出しており、特にプラグイン起因の問題が目立ちます。
• 担当者が不在になりがち。制作会社が納品したまま保守契約がなく、「誰も更新ボタンを押していない」サイトは珍しくありません。
• プラグインの相性問題。更新のたびに表示崩れや機能停止が起きる構成では、更新すること自体が怖くなり、さらに放置が進みます。

Movable Typeは、あらかじめHTMLを生成して配信する静的パブリッシングが基本のCMSです(必要に応じてダイナミック配信も選べます)。閲覧者に返すページが静的ファイルであれば、公開側でCMSのプログラムが動かない分、攻撃面と障害点を減らせます。

さらにSaaS型のMovableType.netを選べば、CMS本体のアップデートやセキュリティ対策はサービス側が実施し、SSL(HTTPS)も追加費用なしで利用できます。「サイトの中身には手をかけたいが、CMSの面倒は見たくない」という体制に合う構成です。

3. 移行先の選択肢 ── Movable TypeとMovableType.net

移行先は大きく2つあります。

少人数運用のコーポレートサイト・士業サイトであれば、まずMovableType.netを検討し、要件が収まらない場合にソフトウェア版を検討する順番が現実的です。承認フロー(申請・承認)とステージング機能は、「所長の確認を経てから公開したい」といった士業事務所の運用と相性が良い機能です。

4. 移行手順の全体像

移行は次の順で進めます。データ移行(手順3)より先に、URLの棚卸し(手順2)を置くのがポイントです。

1. 現状棚卸し ── ページ・機能・プラグインの一覧化
2. URL設計 ── 新旧URL対応表(301マッピング)の確定
3. データ移行 ── WordPressエクスポート → インポート
4. テンプレート再構築 ── デザインとメタ情報の実装
5. 機能の代替実装 ── フォーム・検索など
6. 検証 ── 新旧照合、リダイレクト実測
7. 公開 ── DNS切替、サイトマップ送信、Search Console確認

手順2(URL設計)を手順3(データ移行)より前に置くのには理由があります。URLの規則は、301の対応表と、記事本文の中の内部リンクの両方に染み込むからです。先にデータを入れてしまってから「やはりURL規則を変えよう」となると、301の対応表を作り直すだけでは済まず、インポート済みの記事本文に残っている旧URLのリンクを全件洗い直し、検証もやり直すことになります。逆に、URL規則さえ先に確定していれば、データ移行(手順3)とテンプレート再構築(手順4)は並行して進められます。先に決めるほど後戻りが減る順番になっている、と理解してください。

5. コンテンツ移行の実務

5.1. WordPress側 ── エクスポート

WordPressの管理画面で次のように操作します(WordPress公式の「Tools Export screen」)。

1. 左メニューの 「ツール」→「エクスポート」 を開きます。
2. 書き出す範囲を選びます。「すべてのコンテンツ」を選ぶと、投稿・固定ページ・コメント・カスタムフィールド・ターム(カテゴリー、タグ)・ナビゲーションメニュー・カスタム投稿タイプが1つのファイルにまとまります。
3. 「エクスポートファイルをダウンロード」ボタンを押すと、XMLファイルが手元に保存されます。これがWXR形式のファイルです。

ファイルが大きくなりすぎるときは、この画面で分割できます。「すべてのコンテンツ」ではなく「投稿」を選ぶと、カテゴリー・投稿者・期間(開始日と終了日)・ステータスで絞り込んで書き出せます。「固定ページ」も投稿者・期間・ステータスで絞り込めます。記事数が多いサイトは「2023年」「2024年」…と期間で区切って複数ファイルに分け、順に読み込むのが確実です。「メディア」だけを選んで書き出すこともできます。

5.2. MovableType.net側 ── インポート

1. 管理画面の左サイドバーで「ツール」→「インポート」をクリックします。
2. 読み込むファイルを指定します。対応形式は、MovableType.netからのエクスポートファイル、Movable Type形式、WordPress形式、CSV形式です。WordPressから出したXMLは「WordPress形式」としてそのまま読み込めます。
3. 「アイテムのインポート」を有効にすると、記事本文内やカスタムフィールドからURLを抽出し、ファイルをダウンロードしてアイテム(画像・添付ファイル)として取り込みます。

公式マニュアルには、実作業で効いてくる注意が明記されています。

• 読み込みには時間がかかる場合があります。完了すると登録メールアドレス宛に完了メールが届く仕組みです。「画面が固まった」と誤解して途中で操作しないでください。ファイルサイズや件数の上限は公式マニュアルに明記されていませんが、1回で通らない・時間がかかりすぎる場合は、5.1の期間による分割が現実的な回避策になります。
• 記事のBASENAME(URLに使われる文字列)は、半角英数字が含まれる場合に半角英数字のみが引き継がれます。他の記事と重複する場合は数字が付加されます。日本語スラッグを使っていたサイトは、ここでURLが変わります。第6章の新旧URL対応表で必ず拾ってください。
• ウェブページは記事としてインポートされます。

公式マニュアルによると、取り込みの対応範囲は次のとおりです。

カテゴリーの階層が崩れたときの直し方は、公式マニュアルの「インポート」ページに具体的に書かれています。Movable Type形式でインポートする場合、エクスポートファイル内の PRIMARY CATEGORY: と CATEGORY: の値を、ルートカテゴリ名/サブカテゴリ名 のようにスラッシュ区切りの形へ書き換えると、階層を保ったまま取り込めます。カテゴリー階層を業務上どうしても維持したいサイトでは、この書き換えを移行作業の手順に組み込んでおいてください。手順の原文はMovableType.netのインポートマニュアルにあります。

同じマニュアルには、カスタム投稿タイプについても具体的な修正例が載っています。たとえば <wp:post_type>portfolios</wp:post_type> を <wp:post_type>page</wp:post_type> に書き換える、という形です。「読み込めなかった」で終わらせず、XMLをテキストとして直せば通ることがある、と知っておくだけで見積もりが変わります。

WordPressのカスタム投稿タイプ・カスタムフィールドを多用している場合は、公式の変換ツールと手順の解説を参照しつつ、移行対象のコンテンツ種別ごとに「自動で移るもの/変換が要るもの/手で作り直すもの」を仕分けます。この仕分け表が、そのまま移行の見積もりになります。

なお、記事数が多い場合や構成が複雑な場合に備えて、公式の移行支援の窓口も用意されています。ソフトウェア版Movable Typeへの移行についても、公式のQ&Aが公開されています。

6. URLとSEOの引き継ぎ

CMS移行でSEO評価を落とす原因のほとんどは、CMSの種類ではなくURLの扱いです。

WordPressのパーマリンク設定(/?p=123、/2024/05/post-name/、/category/post-name/ など)と、移行後のURL構造は通常一致しません。次の手順で引き継ぎます。

1. 全URLの棚卸し。記事・固定ページ・カテゴリー・タグ・画像ページを含め、公開中の全URLを一覧化します(サイトマップやクロールツールを利用)。
2. 新URLへの対応表を確定。移行後のURL規則を先に決め、旧URL→新URLの対応表(301マッピング)を作ります。検索流入の多いページから優先的に確認します。
3. 301リダイレクトを設定。変わるURLには恒久リダイレクト(301)を設定します。
4. ページ内要素の引き継ぎ。タイトル、メタディスクリプション、見出し構造、構造化データは、テンプレート再構築時に意識的に引き継ぎます。SEOプラグインが出力していた要素は、移行後はテンプレートでの実装に置き換わります。
5. 公開後の確認。XMLサイトマップの再送信、Search Consoleでのインデックスとエラーの監視、主要ページのリダイレクト実測(ステータスコード確認)を行います。

この「URL設計が先、データ移行とデザインは後」という順番は、CMS移行に限らずサイトリニューアル全般の原則です。当社のサイトリニューアル事例でも、最初に行ったのはデザインではなくURL棚卸しでした。

7. プラグイン機能の代替 ── 「探す」と「不要になる」を分ける

WordPressから移行するとき、プラグイン一覧は不安の種に見えます。しかし機能ごとに整理すると、多くは次の3つに分類できます。

特に問い合わせフォームは、集客サイトの生命線です。移行を機にフォームの通知メールが届かなくなる事故は実際に起きるため、公開前に必ず実際に送信して確認します。フォームメールの不達については「問い合わせフォームのメールが届かないときの調べ方」にまとめています。

8. まとめ ── どんなサイトに向くか(士業・少人数運用のコーポレートサイト)

WordPress→Movable Type(特にMovableType.net)への移行が向くサイト像を挙げます。

• 更新はお知らせ・コラム・実績紹介が中心で、更新箇所が定型的
• 専任のWeb担当者がおらず、CMSの保守に人を割けない
• 税理士・司法書士などの士業サイトのように、公開前に確認・承認を挟みたい
• 会員機能・EC・予約システムのような動的機能を持たない(または外部サービスに切り出せる)
• セキュリティ事故がそのまま信用問題になる業種で、攻撃面を減らしたい

逆に、プラグインによる拡張を今後も積極的に使う計画があるサイトや、動的機能がサイトの中核であるサイトは、WordPressに残る(そして保守体制を整える)方が合理的です。移行は目的ではなく、運用体制とサイトの要件を釣り合わせる手段です。

サイト全体の構成や費用感から検討したい場合は、「中小企業のホームページ制作費用」と「技術系B2Bのサービスページ構成」もあわせてご覧ください。

CMS移行をご検討の方へ

WordPressの保守負担にお悩みの場合も、いきなり移行を決める必要はありません。まずは、現在のサイトのページ・機能・プラグインの棚卸しと、移行した場合に何が変わるか(何が不要になり、何を作り直すか)の整理から始めるのが安全です。

合同会社小村ソフトでは、CMS移行を含むホームページ制作と、移行方針の整理を含む技術相談を承っています。現状の棚卸しからの相談はお問い合わせからご連絡ください。

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

WordPressの記事はMovable Typeへそのまま移せますか？

投稿・固定ページなどの基本的なコンテンツは移行できます。MovableType.netのインポート機能はWordPress形式のエクスポートファイル(XML)に対応しており、記事本文やカスタムフィールド内で参照している画像・ファイルも取り込めます。ただし、カスタム投稿タイプや大きくカスタマイズされたデータはそのままでは読み込めない場合があり、変換や手直しが必要です。移行前に、どのコンテンツがWordPressの標準機能で、どれがプラグイン・カスタマイズ依存かを仕分けることが重要です。

CMSを移行するとSEO評価は下がりませんか？

CMSの種類そのものよりも、URLが変わるかどうかと、リダイレクトを正しく設定するかが影響します。移行前に全URLの棚卸し表を作り、新URLへの対応表を確定し、変わるURLには301リダイレクトを設定します。タイトル・メタディスクリプション・見出し構造を引き継ぎ、公開後はXMLサイトマップの再送信とSearch Consoleでの確認を行えば、移行を理由とした大きな下落は避けられます。逆に、この作業を省くと、CMSが何であっても評価は失われます。

WordPressのプラグインで実現していた機能はどうなりますか？

プラグインという仕組み自体は持ち込めないため、機能ごとに代替を決めます。問い合わせフォームは移行先のフォーム機能や外部フォームサービスで作り直し、SEO系プラグインが出力していたメタ情報はテンプレートで実装し、関連記事やパンくずもテンプレートで組みます。一方、セキュリティ対策系やバックアップ系のプラグインは、静的配信・SaaS型の構成では役割自体が不要になることが多く、「代替を探す機能」と「そもそも不要になる機能」を分けて考えるのがポイントです。

Movable TypeとMovableType.netのどちらを選ぶべきですか？

自社でサーバーを管理し、プラグインやデータベース連携を含めて自由に拡張したい場合はソフトウェア版のMovable Type、サーバー管理やCMS本体のアップデートを手放して運用を軽くしたい場合はSaaS型のMovableType.netが向いています。中小企業のコーポレートサイトや士業サイトのように、専任のWeb担当者がいない体制では、本体の更新やセキュリティ対応をサービス側に任せられるMovableType.netを起点に検討するのが現実的です。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。