WordPressからモダン構成へ移行する手順：URL・記事・運用を引き継ぐ

「WordPressをやめたい」と感じたら、困っている理由を整理します。保守費や更新作業、表示速度、機能・デザインの制約では、取るべき対策が異なります。WordPressのままで改善できることと、移行で変わることを比較して判断します。

WordPressを編集用CMSとして残す場合は、本体やプラグインの更新・脆弱性対応も残ります。「脱WordPress」が必要かは、移行後の負担まで含めて判断します。

移行するかどうかを判断する前に、次の項目を確認して記録します。まだ確認できていない項目がある場合は、その調査から始めます。

「WordPress 移行」には、WordPressを使い続けたままサーバーやドメインを変える引っ越しと、WordPressをやめて別の仕組みに乗り換える移行があります。この記事が扱うのは後者です。サーバーの変更だけを予定している場合は、WordPress公式の移行手順を確認してください。

乗り換えを判断するときは、今の不満に加えて、移行後に誰が更新し、誰が障害や機能追加に対応するかを比べます。

• WordPressを継続して運用を見直す：現在の編集画面やプラグインが業務に合っており、更新・バックアップ・障害対応の担当を決めれば課題を解消できる場合。必要なプラグインを整理し、保守体制の改善にかかる費用と移行費用を比較します。
• サイト制作サービスや別のCMSへ乗り換える：会社案内、お知らせ、フォームなどが中心で、担当者が画面から更新したい場合。今あるページや機能を再現できるか、独自ドメイン・URL・データ出力の条件を移行先で確認します。
• ヘッドレスCMSと表示側を分ける：記事は社内で更新し、表示やシステム連携は開発担当者が保守する場合。デザインの自由度に加えて、構築費、CMSの利用料、コードの保守、フォームなどの運用を含めて比較します。

予約、会員、EC、多言語、サイト内検索をプラグインで実現している場合は、代替機能と移行費用を確認してから判断します。記事だけ移せても、必要な業務が続けられるとは限りません。費用と更新体制の比較は中小企業サイトの運用コストと構成の選び方、CMSの選定はヘッドレスCMSの選び方で詳しく扱っています。

以下では、Next.js（表示）+ microCMS（管理）+ Cloudflare Pages（配信）を移行先の構成例として比較します。更新担当者の作業と、開発担当者が保守する範囲を合わせて確認します。

補足：費用と更新体制の比較は、ホームページ維持費の記事で解説しています。この記事では、どのように移行するかの実務を扱います。

ヘッドレスCMSは、記事を管理画面から更新し、表示側を別の仕組みで実装する選択肢です。お知らせやブログを社内で定期的に更新する場合に、更新担当者と開発担当者の作業を分けて設計できます。この記事ではmicroCMSを構成例にしています。

現在の記事で使っている本文、画像、カテゴリー、公開日、カスタムフィールドを整理し、移行先のデータ項目へ対応づけます。プレビューや承認の手順、利用者の権限も、現在の更新業務に合わせて確認します。

CMSを導入しても、表示側のコードやフォームの保守は残ります。必要な機能・契約条件とCMSの利用料は、採用する前に公式の情報で確認してください。更新が少ない固定ページではCMSを置かない方法も候補です。製品ごとの比較はヘッドレスCMSの選び方で扱っています。

移行先を決めたら、次の順で進めます。各工程の成果物と確認する担当者を決め、公開前に切り戻しの方法を用意します。

• 棚卸し（現状の分析）

  ページ・記事・画像・URL・プラグインと、利用中の機能を一覧にします。検索流入や問い合わせに使われているページを確認し、維持・統合・廃止を判断します。バックアップを取得し、移行前の表示と計測値を記録します。

• 技術選定・設計

  記事はCMS、固定ページはコード管理など、更新頻度と担当者に合わせて振り分けます。今のデザイン・記事・URLをどこまで引き継ぎ、プラグインの機能を何で代替するかを決めます。担当者が更新と確認を行えることも、設計の条件に含めます。

• 実装・データ移行

  現在の見た目を可能な範囲で再現し、記事と画像を移します。移行前後の表示、フォーム、内部リンク、title・description・canonicalなどを比較します。デザインの変更は移行に欠かせないものではないため、必要な場合は別の作業範囲として決めます。

• リダイレクトの設定・公開の切り替え

  URLが変わるページは、新旧URLの対応表を作り、対応する新ページへの301リダイレクトを設定します。ドメインの接続先が変わる場合はDNSも切り替えます。ドメイン・DNSの管理権限と現在のレコードを確認し、メール用のMX・SPF・DKIMなども引き継ぎます。メールが旧レンタルサーバーを利用している場合は、解約前にメールの継続先とデータ移行を確認します。旧サーバーの解約は、バックアップと切り戻し方法を確保し、旧URLへのアクセスを転送し続けられることを確認してから判断します。

• 公開後の確認・運用の引き継ぎ

  主要ページと画像の表示、旧URLの転送、フォームの送信・受信、記事の更新を確認します。Search Consoleでインデックス登録と検索流入を追い、問題があるURLを調査します。更新手順と障害時の連絡先を担当者へ引き継ぎます。URLを変更した場合、Googleは、リダイレクトを一般的に1年以上維持するよう案内しています。旧サーバーを残す期間と、転送を維持する期間は分けて設計します。

重要：見た目・記事・URLはできる範囲で引き継ぎ、テーマやプラグインに依存した内部の仕組みを、新しい構成で実装し直します。デザインを必ず一新する必要はありません。引き継げる範囲と、変更・代替が必要な機能を移行前に合意します。

WordPressをやめると決めた後につまずきやすい、3つの技術的な壁と対策です。

WordPress移行の費用は、ページ数とページの種類に加えて、必要な機能と検証の範囲で変わります。固定ページとお知らせが中心のサイトと、会員・予約・EC・多言語・外部連携があるサイトでは、必要な設計が異なります。

• 初期費用：現状調査、構成設計、ページ・記事・画像の移行、フォームなどの代替実装、URL・SEO・表示の検証、公開切替、運用資料の作成を分けて確認します。デザイン刷新や追加機能が含まれるかも明記します。
• 継続費用：配信、CMS、フォーム通知、AIツール、更新代行・保守の費用を初期費用とは分けて比較します。無料枠の利用を前提にする場合も、上限と、上限を超えたときの料金を確認します。
• 期間：記事・画像の量、カスタム投稿や機能の代替、デザイン確認、社内承認、DNS・メールの切替、公開後の検証を工程別に見積もります。現状を調べる前に期間を一律に決めず、必要な資料、確認する担当者、公開の希望日を共有します。

見積もりは「移行作業一式」でまとめず、対象ページ・機能、確認回数、切替作業の分担、公開後の対応範囲が分かる形で比較します。具体的な支援の範囲と概算の費用は、記事の最後の案内からご相談いただけます。

更新方法は移行前に選びます。お知らせはCMS、固定ページはAIを使った社内更新など、複数の方法を組み合わせることもできます。

WordPressから移行すると、保守の対象と更新の手順が変わります。担当者・対応範囲・費用を一覧にして引き継ぎます。