PHPに依存しないCMSの選び方——WordPressからの移行先をEmDash・ヘッドレスCMS・静的サイトで比べる
WordPressから移るなら、PHPに依存しないCMSはどれがいいのか。同居型のEmDash、SaaSのヘッドレスCMS、Git＋Markdownの静的サイト、ノーコードの4つの型に分け、比べる6つの軸と向く案件、移行の順番を実装者の目線で整理します。
「WordPressの更新は続けてきた。でも今度はPHPそのものを上げてくださいと言われた」。2026年10月のPHPの脆弱性では、WordPressやプラグインの更新では足りず、PHP本体の更新が必要になりました。サーバー側のPHPの更新まで自社で回す体制が取れるかどうかが、分かれ目になります。
結論から言うと、移行先は「PHPを使わない」だけで選ぶと失敗します。先に決めるのは、だれが記事を更新するかです。この記事では、PHPに依存しない移行先を4つの型に分け、比べる軸と向く案件、移行の順番までを整理します。移らずにWordPressを続ける選択肢も、最初に並べておきます。
PHPを外すと、サーバー側のPHPの更新が要らなくなる
WordPressから移る理由がPHPの保守なら、移行先は「PHPのサーバーを自分で持たない」構成を選びます。
WordPressはPHPで動くCMSです。公式の動作環境のページも、PHPのバージョンを条件に挙げています（WordPress の動作環境）。つまりWordPressを使う限り、PHP本体の更新も運用の一部になります。
2026年10月21日には、PHPの開発チームが深刻度の最も高い区分（Critical）の脆弱性2件の修正版を出しました（php.net）。これはPHP本体の問題なので、WordPressやプラグインを更新しても直りません。PHPのサーバーを持つ場合は、本体の更新も運用に含まれます。PHPの開発チームは修正版を出しているので、更新すれば塞げます。今回の脆弱性の影響と対応は「PHPに緊急の脆弱性2件（2026年10月）WordPressサイトで今日やること」にまとめています。
その前に：WordPressを続ける選択肢もある
移行先を比べる前に、移らないという選択肢も並べておきます。PHPの更新が負担なら、その作業を引き受けてくれる先に任せる方法があります。
PHPの更新まで任せられるサーバーに替える
マネージドWordPressと呼ばれるホスティングや、多くのレンタルサーバーでは、PHPやサーバーOSの更新をサーバー会社が引き受ける形です。サーバーだけ移せば、テーマもプラグインも今のまま使えます。プラグインに頼る機能が多いサイトほど、この方法の手間は小さく済むんです。
保守契約を見直す
更新の担当がいないことが問題なら、本体・プラグイン・PHPの更新を保守契約に含めてもらう方法もあります。WordPressは扱える制作会社が多いので、頼み先を見つけやすいのも強みです。
ここから先は、移行すると決めたときの型の選び方です。続けるか移るかの判断はWordPressを続けるか移るかの判断軸をまとめた記事で整理しています。
移行先は4つの型に分けて考える
PHPに依存しない移行先は、管理画面とデータがどこにあるかで4つの型に分かれます。ポイントは次の4つです。
- 同居型CMS。管理画面とサイトが1つのアプリに入っている
- SaaSのヘッドレスCMS。管理画面は外部のサービスにある
- Git＋Markdownの静的サイト。記事はファイルとして持つ
- ノーコードのサービス。デザインも更新もサービスの画面で行う
同居型CMSは、WordPressに近い使い心地のまま移れる
同居型は、WordPressと同じく管理画面と公開ページが1つのアプリに入っている型です。例として、Astroで作られたCMSのEmDashがあります。記事を書く人は管理画面にログインし、保存して公開するので、この流れはWordPressとほとんど変わりません。
このサイトもEmDashで動いていて、サーバーはCloudflareのWorkers、データはD1、画像はR2という構成です。PHPのサーバーはどこにもありません。
SaaSのヘッドレスCMSは、管理画面をサービスに任せる
ヘッドレスCMSは、記事を管理する画面と、サイトの見た目を分けたCMSです。たとえば国産のmicroCMSは、管理画面をサービスとして提供し、記事をAPIで渡すしくみです。サイト側はAstroなどで別に作り、APIから記事を受け取って表示します。
管理画面のサーバーはサービス側が運用しますが、そのかわりデータは契約しているサービスの中に置かれます。
Git＋Markdownの静的サイトは、更新する人を選ぶ
記事をMarkdownのファイルとして持ち、ビルドしてHTMLにする型です。Astroならコンテンツコレクションという機能で、ファイルを記事として扱えます。更新はファイルを書き換えてGitにコミットする作業になります。
サーバーに置くのはビルド済みの静的ファイルだけなので、動いている部分がいちばん少ない型です。反面、GitやMarkdownに慣れていない人には更新しにくくなります。
ノーコードのサービスは、作るところから任せる
デザインも記事の更新も、サービスの画面の中で完結する型です。国産ならSTUDIOのように、デザインの編集画面とCMS、公開用のサーバーをまとめて提供するサービスがあります。
コードを書かずに作れます。サーバーの保守もサービス側です。ただし、できることはサービスが用意した機能の範囲に限られます。
比べる軸は6つ。いちばん効くのは「だれが更新するか」
移行先の比較は、6つの軸を表で並べると判断しやすくなります。ポイントは2つです。
- 最初に見るのは「だれが更新するか」
- どの型を選んでも、保守の作業はゼロにならない
比べる軸 | WordPress（参考） | 同居型CMS | SaaSのヘッドレス | Git＋Markdown | ノーコード |
|---|---|---|---|---|---|
だれが更新するか | 社内の担当者 | 社内の担当者 | 社内の担当者 | 主に開発者 | 社内の担当者 |
編集画面 | WordPressの管理画面 | 自社サイトの管理画面 | サービスの管理画面 | エディタとGit | サービスの編集画面 |
データの持ち主 | 自社で契約したサーバーのデータベース | 自社アカウントのデータベース（例：Cloudflare D1） | サービスの中 | 自社で管理するGitリポジトリ | サービスの中 |
ホスティング | 自社で契約する（安価な選択肢が多い） | 自社で契約する | 表示側は自社で契約 | 自社で契約する | サービスに含まれる |
移行のしやすさ | 移らないので不要 | WordPressの取り込み機能があるものも | CSVなどで流し込む（形式の変換は必要） | 記事をファイルに変換する | WordPressの取り込み機能があるものも（一部のデータのみ） |
保守で残る作業 | 本体・プラグイン・PHPの更新（サーバー会社に任せられる場合も） | CMSと部品の更新 | 表示側の部品の更新 | 表示側の部品の更新 | ほぼサービス任せ |
プラグイン・情報量 | 非常に多い | まだ少ない | サービスによる | 少ない | サービスによる |
「だれが更新するか」で、候補は半分に絞れる
更新するのが社内の担当者なら、素のGit＋Markdownは外れます。毎回コミットを頼むことになり、更新が止まるからです。Gitの上に編集画面をかぶせるGitベースのCMSもありますが、そのぶん部品と保守が増えます。逆に、開発者だけが更新するサイトなら、管理画面のない静的サイトがいちばん軽く済みます。表のほかの軸は、この1つを決めてから比べれば十分です。
データの持ち主は、やめるときに効いてくる
SaaSとノーコードは、データがサービスの中にあります。サービスをやめるときに、記事や画像をどの形で取り出せるかは各サービスの仕様しだいです。契約する前に、取り出す方法を公式の資料で確かめておくと安心です。同居型とGit＋Markdownは、データが自社の側に残ります。
サーバーを持たない構成で何が消えて何が残るかは「サーバー保守を抱えたくない制作会社へ」でくわしく書いています。
型ごとに向く案件、向かない案件
どの型が合うかは、サイトの規模より更新のしかたで決まります。ポイントは4つです。
- 同居型は、社内で記事を更新し、データを自社で持ちたい案件
- SaaSのヘッドレスは、同じ記事を複数の場所に出したい案件
- Git＋Markdownは、開発者が更新する技術寄りのサイト
- ノーコードは、小さく早く作り、機能が決まっているサイト
同居型が向くのは、更新する人がWordPressに慣れている案件
社内の担当者がWordPressで記事を書いてきたなら、同居型がいちばん戸惑いが少なく済みます。管理画面で書いて公開する流れが同じだからです。記事の項目もコンテンツタイプとして案件ごとに決められます。向かないのは、WordPressのプラグインに頼った機能が多いサイトです。プラグインはそのまま動かないので、機能ごとに作り直すことになります。
SaaSのヘッドレスが向くのは、管理画面の運用を手放したい案件
管理画面のサーバーやログインの仕組みまで、サービス側に任せたい案件に向きます。同じ記事をサイトとアプリの両方に出したいときも、APIで渡す型は扱いやすくなります。向かないのは、データを自社の外に置けない案件です。
Git＋Markdownと、ノーコードが向く場面
Git＋Markdownは、技術ブログやドキュメントのように、書く人が開発者の案件に向きます。ノーコードは、ページ数が少なく、デザインの自由度よりも早さを取りたい案件に向きます。どちらも、会員機能や複雑な予約のような独自の処理を足すのは得意ではありません。
移行で失敗しない順番は、棚卸しから
型を決める前に、今のサイトにあるものを書き出します。順番は4つです。
- 棚卸し。ページ、更新する人、使っているプラグインの機能を書き出す
- 移行先の型を選ぶ。だれが更新するかから決める
- URLとリダイレクト。変わるURLに301リダイレクトを用意する
- 公開後の確認。404と計測を確かめ、旧サーバーはしばらく残す
棚卸しで、プラグインの「機能」を書き出す
プラグインの名前ではなく、それが担っている機能を書き出します。お問い合わせフォーム、SEOの設定、予約、会員などです。PHPに依存しない移行先では、WordPressのプラグインはどれも動きません。機能ごとに、移行先の標準機能か、別のサービスか、作り直すかを決めます。
URLとリダイレクトで、検索の評価を引き継ぐ
URLが変わるページには、古いURLから新しいURLへ301リダイレクトを用意します。用意しないと、検索結果やブックマークから来た人が404にたどり着きかねません。リニューアルでのURLの扱いは「ホームページのリニューアルで検索順位を落とさないために」に、EmDashへ移る具体的な手順は「WordPressからEmDashへ移行する手順」にまとめています。
公開後は、旧サーバーをすぐに消さない
公開したら、404のログとアクセス解析の数字を見て、漏れたURLを拾うんです。旧サーバーは、新しいサイトが落ち着くまで残しておきます。EmDashの公式の移行ガイドも、新しいサイトを確かめ終えるまでWordPressを残すよう案内しています（Migrating from WordPress）。
よくある質問
WordPressのデザインは、そのまま使えますか？
そのままは使えません。WordPressのテーマはPHPで書かれているので、移行先の仕組みで作り直します。見た目をほぼ同じに再現することも可能ですし、作り直すついでに表示の速さや更新のしやすさを見直す機会にもなります。
PHPに依存しないCMSなら、脆弱性の心配はいりませんか？
いりますが、心配の中身が変わるんです。PHPやサーバーOSの更新は手放せます。一方で、サイトを作る部品やCMS本体には脆弱性が見つかることがあるので、更新は続きます。SaaSやノーコードでは、その多くをサービス側が引き受けます。
全部のページを一度に移さないといけませんか？
切り替えを1回で済ませるほうが、URLやリダイレクトの管理は単純です。同じドメインで新旧のCMSを混ぜると、URLの振り分けが複雑になるからです。ただ、ブログだけをサブドメインに分けるなど、切り分けやすい部分から段階的に移す方法もあります。どちらにするかは棚卸しの結果で決めます。
まとめ
PHPの更新を自社で抱えたくない場合は、移行先の型を選び直す方法と、WordPressのまま任せ先を見直す方法があります。綴はWordPressからEmDashへの引っ越しを中心に、案件に合えばEmDash以外のPHPに依存しないCMSへの移行もお手伝いしています。進め方は移行支援の案内にまとめました。どの型が合うか迷っている段階でもかまわないので、お問い合わせから今のサイトの状況をお聞かせください。
本記事は2026年10月時点の情報です。