- 2026年10月21日のPHPの緊急更新で、WordPressのサイトは「WordPress本体・プラグイン・PHP・サーバー」をまとめて面倒を見続ける必要があることがはっきりしました。
- 脱WordPressの選択肢は、大きく5つです。WordPressを続けて保守の体制を整える、静的化する、ヘッドレスCMSと静的配信に分ける、ホームページ作成サービスに移る、サーバーレスで動く新しいCMSに移る。どれが合うかは、更新の頻度、社内の人手、サイトに必要な機能で変わります。
- どの道を選んでも、移行は数週間から数か月かかることがあり、その間も今のサイトは公開されたままです。まず今のWordPressのPHPを修正版に更新し、そのうえで移行を進めます。
なぜ今「脱WordPress」が話題になるのか
2026年10月21日、PHPの公式サイトは、認証なしで外部からプログラムを実行されるおそれのある脆弱性2件を直した修正版を公開しました。修正版はPHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35で、Webのリクエストを処理しているすべてのPHPの利用者に、すぐ更新するよう強く勧めています［php.net］。経緯と影響は「php2shellの解説記事」にまとめています。
WordPressは、PHP（Webサイトを動かすプログラミング言語）とデータベースの上で動くCMS（ホームページの更新システム）です。WordPress.orgは推奨環境としてPHP 8.3以上を挙げ、サポートの終わった古いPHPやMySQLを使うとセキュリティ上のリスクがあるとしています［WordPress.org「Requirements」］。
つまりWordPressのサイトを安全に保つには、テーマやプラグイン、WordPress本体、PHP、サーバーのどれも古いままにしないことが必要です。WordPress.orgも、サイトを安全に保つためにプラグインとテーマを常に最新版へ更新するよう求めています［WordPress.org「Plugin and themes auto-updates」］。今回の緊急更新で、この手間を改めて意識した会社も多いはずです。「更新の手間が少ない仕組みに移れないか」と考えるのは自然な流れです。
ただし、WordPressをやめれば保守がなくなるわけではありません。移った先にも、それぞれ別の手間と制約があります。以下で、中小企業のコーポレートサイトや採用サイトを想定して、現実的な選択肢を比べます。
WordPressから移行するときの5つの選択肢
1. WordPressを続け、保守の体制を整える
いちばん移行の手間が少ないのは、WordPressを使い続けたまま、更新を確実に回す体制をつくることです。たとえば次のような体制です。
- PHPのバージョンを、サポート期間中のものにそろえる（手順は「WordPressのPHPバージョンアップ手順」）
- 使っていないプラグインとテーマを削除し、残したものは更新を続ける。WordPress 5.5からは、プラグインとテーマごとに自動更新を有効にできます［WordPress.org］
- 更新の前にバックアップを取り、更新後に表示とフォームを確認する担当者を決める
デザインや更新のしかたは今のままなので、社内の担当者が慣れている場合に向いています。一方で、PHPやプラグインの更新はこれからも続きます。今回のような緊急の更新にも、その都度対応が必要です。
2. WordPressを静的化する（HTMLに書き出す）
静的化は、WordPressで作ったページをHTMLファイルに書き出して、そのHTMLだけを公開する方法です。訪問者が見るのは書き出したファイルなので、公開しているサーバーではPHPもデータベースも動きません。
WordPressのプラグインとしてもこうした機能が提供されています。例としてSimply Staticの説明では、WordPressのサイトは非公開のまま置いておき、訪問者には書き出した静的なサイトを見せる使い方を案内しています［WordPress.org プラグインディレクトリ「Simply Static」］。
更新の画面は今のWordPressのままなので、担当者が操作を覚え直す必要はありません。ただし、注意点が2つあります。
- WordPress自体は残る：記事を書くためのWordPressは残るので、本体やプラグイン、PHPの更新は引き続き必要です。外から見えない場所に置けば狙われにくくはなりますが、なくなるわけではありません。
- サーバーで動く機能は別の手段が要る：問い合わせフォーム、サイト内検索、会員ページなど、サーバー側でプログラムを動かす機能はHTMLだけでは動きません。Simply Staticでも、フォームとの連携は有料版の機能として挙げられています［同上］。フォームを外部のサービスに置き換えるなどの手当てが必要です。
3. ヘッドレスCMSと静的配信に分ける
ヘッドレスCMSは、記事を入力・保存する管理画面だけを提供し、表示の部分を持たないCMSです。サイトの見た目は別に作り、CMSからAPI（プログラムどうしでデータをやり取りする窓口）で記事を受け取ってページを組み立てます。組み立てたページは、HTMLを配信する静的ホスティングから公開できます。
WordPress自体もREST APIを備えていて、JSON形式で記事などのデータをやり取りできます。WordPress.orgは、これを使えばまったく別のアプリケーションにWordPressのコンテンツを持ち込めるとしています［WordPress.org「REST API Handbook」］。ただし、管理画面にWordPressを使う場合はPHPの更新が残ります。PHPの保守をなくしたいなら、管理画面にクラウドで提供されるヘッドレスCMSのサービスを選ぶことになります。
表示の速さやデザインの自由度を確保しやすい反面、作るには開発の知識が必要です。見た目を変えるたびに制作会社や開発者に頼む形になりやすく、社内に詳しい人がいない会社には負担になります。
4. ホームページ作成サービスに移る
ホームページ作成サービスは、デザイン、更新の画面、公開用のサーバーをまとめて提供するクラウドサービスです。たとえば国内向けのStudioは、Webサイトの構築・公開・運用をひとつのサービスで行えると説明しています［Studio公式サイト］。ほかにWix、ネットショップならShopifyなどがあります。
サーバーやCMS本体の更新はサービスの提供会社が行うので、自社でPHPやプラグインの更新を気にする必要はなくなります。その代わり、次の点はサービスごとに違うため、契約前に公式の情報で確かめてください。
- 料金の体系（ページ数、編集者の人数、独自ドメインなどで変わることがあります）
- 作りたいページや機能がそのサービスで作れるか
- 今のURLを保てるか、リダイレクトを設定できるか
- 将来またほかへ移るときに、データを書き出せるか
デザインや機能の自由度は、サービスの機能の範囲に限られます。サービスの仕様変更や価格改定も、自社では決められません。
5. サーバーレスで動く新しいCMSに移る（EmDashなど）
新しい選択肢として、サーバーを自社で持たずに動くCMSも出てきています。その一つが、Cloudflareが公開しているオープンソースのCMS「EmDash」です。
- 2026年4月1日にベータ版（v0.1.0のプレビュー）として発表され、9月28日（米国時間）に安定版のEmDash 1.0が公開されました［Cloudflare Blog］。
- TypeScriptで書かれ、サイト制作用のWebフレームワーク「Astro」を使っています。ライセンスはMITです［Cloudflare Blog］。
- CloudflareのWorkersなどの上で動くほか、Node.jsとSQLiteが使えるサーバーでも動きます。GitHubの説明には「PHPは不要」とあります［GitHub emdash-cms/emdash］。
- プラグインはそれぞれ隔離された環境で動き、あらかじめ宣言した権限しか使えない設計です。CloudflareはこれをWordPressのプラグインの安全性の問題への解決策と説明しています［Cloudflare Blog］。
- WordPressの「エクスポート」で作るWXRファイル、または専用のプラグインから、既存のWordPressサイトを取り込めます［Cloudflare Blog］。
- Cloudflareは2026年8月12日に自社のブログをEmDashへ移したと公表しています［Cloudflare Blog］。
ここからは当センターの見方です。PHPの更新から離れられる点は魅力ですが、公開から日が浅いため、WordPressに比べるとプラグインやテーマ、扱える制作会社やノウハウはまだ少ない状態です。見た目を作るにはAstroの知識が要るので、開発者がいる会社か、開発を任せられる相手がいる会社に向いています。また、CMS本体やプラグインの更新がなくなるわけではありません。
CMS比較表：保守の手間と移行の難しさ
5つの選択肢を、当センターの見方で比べると次のようになります。サイトの規模や作り方によって変わるので、目安としてご覧ください。
| 選択肢 | 保守の手間 | PHPの更新 | 更新のしやすさ | 移行の難しさ | 向いている会社 |
|---|---|---|---|---|---|
| 1. WordPressを続ける（保守体制を整える） | 多い。本体・プラグイン・PHPを継続して更新 | 必要 | 今のまま | 低い（移行しない） | 今の運用に慣れていて、保守を任せられる相手がいる |
| 2. WordPressを静的化 | 中くらい。非公開のWordPressの更新は続く | 必要（非公開側） | 今のまま。公開には書き出しの手順が加わる | 中くらい。フォームなどの置き換えが要る | 更新は少なめで、動的な機能が少ないサイト |
| 3. ヘッドレスCMS＋静的配信 | 中くらい。表示部分の保守は開発者が担う | 選ぶCMSによる（サービス型なら不要） | 入力は簡単。見た目の変更は開発が要る | 高い。表示部分を作り直す | 開発者がいる、またはデザインや速さにこだわりたい |
| 4. ホームページ作成サービス | 少ない。サーバーや本体の更新は提供会社 | 不要 | 画面で直感的に編集しやすい | 中くらい。ページを作り直すことが多い | ページ数が多くなく、社内で手軽に更新したい |
| 5. サーバーレスの新しいCMS（EmDashなど） | 中くらい。CMS本体やプラグインの更新は続く | 不要 | 管理画面で編集。見た目の変更は開発が要る | 高い。テーマを作り直す | 開発者がいて、新しい仕組みを試せる |
どう選ぶか
迷ったときは、次の順に考えると絞り込みやすくなります。
- サイトで何をしているか：会社案内や採用情報が中心か、問い合わせフォームや会員ページ、ネットショップがあるか。サーバーでプログラムを動かす機能が多いほど、静的化は難しくなります。
- 誰が、どのくらい更新するか：社内の担当者が毎週お知らせを更新するなら、更新画面の使いやすさを優先します。年に数回しか変えないなら、ほかの条件を優先してかまいません。
- 保守を誰が担うか：社内に詳しい人がいるか、制作会社や保守の委託先に任せられるか。保守を任せられる相手がいるなら、WordPressを続けるのも十分に現実的です。
「PHPの更新が不安だから」という理由だけで移行先を決めると、作り直しの費用や新しい仕組みの学習のほうが大きくなることがあります。今の運用で困っていることを書き出してから、選択肢を比べるのがおすすめです。
移行の前にやること：今のWordPressのPHPは先に更新しておく
移行先を選び、新しいサイトを作って切り替えるまでには時間がかかります。その間も、今のWordPressのサイトはインターネットに公開されたままです。「どうせ移行するから」と更新を後回しにすると、移行が終わるまでの間、修正されていない脆弱性を抱えたまま運用することになります。
まず今のサーバーのPHPを修正版（8.5.12 / 8.4.27 / 8.3.36 / 8.2.35のいずれか以降）にしてください［php.net］。レンタルサーバーなら、提供会社の告知で対応状況を確かめます（レンタルサーバー各社の対応状況まとめ）。8.1以前を使っている場合は修正版が出ていないため、サポート中のバージョンへの切り替えが先です（PHP 8.1以前を使い続けるリスク）。今のサーバーで新しいPHPを選べないなら、まずサーバーだけを移す方法もあります（WordPressのサーバー移行手順）。
WordPress本体とプラグインも、移行が終わるまでは更新を続けます。移行の作業で使うバックアップも、このタイミングで取っておくと後の作業が楽になります。
WordPress移行の進め方
1. 今のサイトを棚卸しする
移行先がどこでも、最初にやることは同じです。今のサイトにあるものを一覧にします。
- ページとURL：固定ページ、投稿、カテゴリーの一覧ページ、PDFや画像のURL。アクセス解析で、よく見られているページと、検索から入ってくるページも確かめます。
- フォーム：問い合わせや資料請求のフォームと、その通知メールの送り先。
- 外部との連携：アクセス解析のタグ、広告のタグ、予約システムや地図の埋め込み、SNSとの連携。
- プラグインでやっていること：SEOの設定、リダイレクト、バックアップなど。移行先で同じことをどう実現するかを決めます。
記事のデータは、WordPressの「ツール」→「エクスポート」で書き出せます。投稿、固定ページ、コメント、カスタムフィールド、カテゴリー、タグ、ユーザーなどがWXRというXMLファイルにまとめられます［WordPress.org「Tools Export screen」］。移行先が取り込みに対応していれば、このファイルを使えます。
2. URLはできるだけ変えない。変えるなら301リダイレクト
検索結果やほかのサイトからのリンクは、今のURLを指しています。新しいサイトでも同じURLを使えるなら、それがいちばん確実です。
URLが変わるページは、古いURLと新しいURLの対応表を作り、古いURLにアクセスした人を新しいURLへ転送（リダイレクト）します。Googleは、URLを変えるときは、可能な限りサーバー側の永続的なリダイレクト（301など）を使うよう勧めています［Google検索セントラル「リダイレクトと Google 検索」］。サイト内のリンクも新しいURLに直します。
Googleはサイトの移転について、変更は一度に1つずつ行うよう勧めています。例として、ドメインの変更とCMSの変更を同時にせず、順に行う形を挙げています［Google検索セントラル「サイトを移転する方法」］。CMSを変えるときは、ドメインは変えずに進めるのが無難です。また、移転のあとは検索順位が一時的に変動することがあり、中規模のサイトでは新しいURLが表示されるまでに数週間以上かかることがあるとしています［同上］。
3. テスト環境で確認する
新しいサイトは、公開前に本番とは別のURLやテスト環境で作り、次の点を確かめます。
- 主要なページの表示（パソコンとスマートフォン）
- 問い合わせフォームの送信と、通知メールが届くか
- 対応表どおりに、古いURLから新しいURLへリダイレクトされるか
- アクセス解析や広告のタグが入っているか
- テスト環境が検索エンジンに登録されないようになっているか
4. DNSを切り替える
確認がすんだら、ドメインのDNS（ドメイン名とサーバーの住所を結びつける仕組み）を新しいサイトに向けます。切り替えた直後は、古い情報を覚えている訪問者が旧サイトを見ることがあります。TTL（DNSの情報を一時保存してよい時間）の考え方や、メールも同じドメインで使っているときの注意は「WordPressのサーバー移行手順」で説明しています。切り替えはアクセスの少ない時間帯に行うと、問題が起きたときの影響を小さくできます［Google検索セントラル］。
5. 旧環境はすぐに消さない
切り替えたあとも、旧サイトとそのバックアップはしばらく残しておきます。リダイレクトの漏れや、移し忘れたページが見つかったときに確かめられるからです。旧サイトを止めるまでは、旧サイト側のPHPやWordPressの更新も続けてください。止めたら、旧サーバーの契約とデータの扱いも決めておきます。
よくある質問
WordPressをやめれば、セキュリティの心配はなくなりますか？
なくなりません。ホームページ作成サービスでは提供会社が更新を担いますが、管理画面のパスワードや編集者のアカウントの管理は自社で行います。ほかの選択肢でも、CMS本体やプラグイン、外部サービスの更新や設定の見直しは続きます。WordPressをやめると、PHPの更新を自社で気にしなくてよくなる場合がある、というのが正確なところです。
移行している間、今のWordPressはそのままでいいですか？
いいえ。切り替えまでは今のサイトが公開されたままなので、PHP、WordPress本体、プラグインの更新は続けてください。特にPHPは、今回の修正版（8.5.12 / 8.4.27 / 8.3.36 / 8.2.35）に更新されているかを先に確かめます。
移行すると検索順位は下がりますか？
Googleは、URLの変更を伴う移転では順位が一時的に変動することがあるとしています［Google検索セントラル］。URLをできるだけ今と同じにし、変わるページには301リダイレクトを設定することで、影響を抑えられます。
EmDashはWordPressの代わりにすぐ使えますか？
Cloudflareは2026年9月に安定版の1.0を公開し、WordPressからの取り込み機能も用意しています［Cloudflare Blog］。ただ、公開から日が浅く、見た目を作るにはAstroなどの開発の知識が必要です。社内や委託先に開発者がいるかどうかで判断してください。
どれを選べばいいか分かりません
まず今のサイトで何をしているか（フォーム、会員ページ、ネットショップなど）と、誰がどのくらい更新するかを書き出してみてください。それによって候補はかなり絞れます。
Webセキュリティ診断センターでは、今のWordPressのPHP更新から、移行先の検討、URLの対応表とリダイレクトの設定、サーバー移行までご相談をお受けしています。「WordPressを続けるか、移行するか」を決めかねている段階でもかまいません。無料相談はこちら
参考にした情報
- php.net「Security advisory: Critical remote code execution vulnerabilities, update now」（2026年10月21日）
- WordPress.org「Requirements」
- WordPress.org「Plugin and themes auto-updates」
- WordPress.org「Tools Export screen」
- WordPress.org「REST API Handbook」
- WordPress.org プラグインディレクトリ「Simply Static」
- Studio公式サイト
- Cloudflare Blog「Introducing EmDash」（2026年4月1日） / 「EmDash 1.0」（2026年9月28日） / 「The Cloudflare Blog – Brought to you by EmDash」
- GitHub「emdash-cms/emdash」
- Google検索セントラル「サイトを移転する方法」 / 「リダイレクトと Google 検索」
