WordPressをやめたい｜PHP脆弱性の確認と静的サイトへの乗り換え

「管理画面を開くたびに更新のお知らせが出ていて、押してよいのか分からない」「入れた覚えのないプラグインがたくさん並んでいる」「保守費を払い続けているけれど、ほとんど更新していない」。こうした声から行き着くのが、「もうWordPressをやめたい。でも、やめたら何が困るのか分からない」という迷いです。

最初にお伝えしておきたいのは、WordPressは悪い道具ではないということです。無料のソフトで、管理画面から誰でも文章や写真を差し替えられ、機能も後から足せます。それでも「やめたい」と感じるのは、多くの場合、道具の良し悪しではなく、自社の使い方と、道具が求める手間が合っていないからです。

2026年10月21日には、WordPressの土台であるPHPに重大な脆弱性が公表されました。「やめるかどうか」の前に、今のサイトで確認しておくべきことがあるので、最初にまとめます。そのうえで、やめたい理由を3つに分け、乗り換え先の選択肢、とくに当サイトでも使っている「静的サイト」の仕組みを説明し、やめて困ること（管理画面、プラグインの機能、記事とURLの扱い）と進め方をお伝えします。WordPressそのものの弱点と対策はワードプレスは危険？セキュリティの弱点と今日からの対策で扱っているので、ここでは「やめたい人が次にどうするか」に絞ります。仕組みや仕様の説明は、2026年10月時点で確認できた公式の情報にもとづいています。

【2026年10月】PHPの重大な脆弱性が公表されました

この章は2026年10月23日時点の内容です。状況は日々変わるため、最新の情報は公式の発表で確認してください。

何が公表されたのか

PHPの開発元であるPHP Groupは、2026年10月21日、2つの重大な脆弱性（CVE-2026-109618、CVE-2026-109619）を修正したと発表しました。開発元は、これらを悪用されると認証なしで、外部からプログラムを実行されるおそれがあるとして、すべての利用者に直ちに更新するよう強く呼びかけています。深刻度は、GitHub上の脆弱性情報で最も高い区分の「Critical（緊急）」、共通の評価指標（CVSS v4）で9.2とされています。2つの組み合わせは「PHP2Shell」と呼ばれています。

修正されたのは、次のバージョンです。

PHP 8.1以前は、PHP Groupによるサポートがすでに終わっており、開発元からは修正版が出ていません（ソースからPHPを組み立てる人向けに、最小限の修正だけが提供されています）。国内ではJPCERT/CCが10月22日に注意喚起を、IPA（情報処理推進機構）が同日に対策の案内を出しています。

WordPressへの影響

WordPress.orgは10月21日に「Critical PHP Security Release」という告知を出しています。要点は次のとおりです。

• この問題はWordPress固有のものではなく、PHPのアプリケーションを動かすあらゆるサーバーに関わる
• WordPress本体の更新は必要なく、予定もない。対処するのはPHPの側
• サーバー会社が対応を進めている可能性があるが、更新の有無は自分でも確認する
• PHP 8.2より古い版は、サポートが終わっている。自分でサーバーを管理していてその版を使っているなら、更新の準備をする間、サーバーを止めることも考えるよう案内している

つまり、WordPressをいつも最新にしていても、PHPが古ければ対象になります。

今すぐ確認する3つのこと

1. PHPのバージョンを調べる。 WordPressの管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」で確認できます。サーバー会社の管理画面に表示されることもあります。
2. 表のバージョンより古ければ、サーバー会社に更新の状況を問い合わせる。 レンタルサーバーなら、管理画面でPHPの版を切り替えられることが多くあります。ただし版を上げるとテーマやプラグインが動かなくなることがあるため、更新前にバックアップを取り、更新後にサイトの表示とフォームの送信を確かめます。
3. PHP 8.1以前で、更新できない事情があるなら、先延ばしにしない。 IPAも、古いままの運用を放置せず、暫定的なアクセス制限や、場合によっては一時的な公開停止も検討するよう案内しています。更新や移行に必要な人手と費用を確保できないなら、サービスの移行や縮小、公開の終了も含めて方針を決めるよう求めています。

開発元は、更新できない場合の緩和策も示していますが、特定の攻撃経路を減らすだけで、サイトが安全になるわけではないとし、更新だけが完全な対策だと明記しています（JPCERT/CCも同じ立場です）。すでに攻撃を受けていないかを調べる観点（不審なリクエストやエラーの記録など）も示されており、心当たりがあれば、サーバー会社や制作を頼んでいる相手に相談してください。

静的サイトなら関係ないのか

公開側でPHPを動かしていない静的サイトは、対象のPHPそのものを公開側に持ちません。「守る範囲が小さくなる」という利点の一例です。ただし、次の2点には注意してください。

• 同じサーバーに、問い合わせフォームの受付プログラムなど、PHPで動くものが別に残っていないか
• 今回のニュースを受けて、あわてて乗り換える必要はないこと。移行には記事とURLの整理、転送の設定、確認といった手順が要ります。まず今のPHPを更新して危険を取り除き、そのうえで落ち着いて検討するほうが失敗が少なくなります

やめる・続けるのどちらでも、PHPやサーバーの更新を誰が担当するのかを決めておくことが、次の章以降の判断の出発点になります。

WordPressをやめたい理由は3つに分けられる

「やめたい」の中身によって、取るべき手は変わります。自分の理由がどれに当たるかを確かめてください。

1. 更新の手間が負担になっている

WordPressのサイトは、本体、見た目を決める「テーマ」、機能を足す「プラグイン」の3つでできています。それぞれに新しい版が出るため、管理画面には更新のお知らせがたびたび表示されます。WordPressの公式ドキュメントも、サイトを安全に保つためにプラグインとテーマは常に最新版に更新すべきだと案内しています。

負担を減らす仕組みも用意されています。公式ドキュメントによると、本体の小さな更新は多くのサイトで既定で自動的に行われ、プラグインとテーマもバージョン5.5以降は1つずつ自動更新を有効にできます。ただし同じドキュメントは、自動更新の前に、以前の状態へ戻せる定期的なバックアップを取っておくことを勧めています。

つまり、自動にしても「表示が崩れたら誰が直すのか」「戻すためのバックアップはあるか」という確認は残ります。サーバー側のPHPやデータベースも、古くなれば更新が必要です（今回のPHPのニュースがその例です）。更新の手間がつらいとは、この終わりのない確認を誰が引き受けるのか決まっていない状態だと言えます。

2. セキュリティが心配

詳しい数字と対策は前述の記事にゆずります。WordPressのサイトでは、公開しているサーバーの上で、ページを組み立てるプログラムと、ログインできる管理画面が常に動いています。便利さの源であるこの仕組みが、同時に守らなければならない対象にもなっています。対策を続ける人がいなければ、心配はなくなりません。

3. 費用がかさんでいる

WordPressの本体は、GPLという利用条件で公開されている無料のソフトです。ソフトそのものにお金はかかりません。費用がかかっているのは、その周りです。

• WordPressを動かせるサーバーの料金
• 有料のテーマやプラグインの利用料
• 更新やバックアップ確認などの保守作業の費用
• 不具合が起きたときの修理の費用

このうち大きいのは、多くの場合、人の手間の費用です。保守の範囲と相場の考え方はホームページ保守は何を頼めるのか｜範囲と相場に、維持費全体の見直し方は中小企業のホームページ維持費は月いくらが適正かにまとめています。

理由によって、やめなくても解決することがある

真ん中の列で済むなら、無理に乗り換える必要はありません。試しても負担が変わらない、そもそも管理画面をほとんど使っていない、という場合に、乗り換えが現実的になります。

静的サイトと動的サイトは何が違うのか

ページを作るタイミングが違う

ウェブの技術資料として広く参照されているMDN（Mozillaが提供する開発者向けの資料）は、ウェブサーバーを2種類に分けて説明しています。

• 静的なサーバー：置いてあるファイルを、そのままの形でブラウザに送る
• 動的なサーバー：静的なサーバーに、アプリケーションサーバーとデータベースを加えたもの。送る前に、データベースの内容をひな形に流し込むなどして、中身を組み立てる

WordPressは動的な側です。WordPressの公式サイトによると、WordPressはPHPとデータベース（MariaDBまたはMySQL）の上で動くソフトです。訪問者がページを開くと、サーバーの上でPHPのプログラムが動き、データベースから記事を取り出してページを組み立てて返します。

静的サイトは、公開の前にすべてのページをHTMLのファイルとして書き出しておき、訪問者にはそのファイルをそのまま渡す方式です。

当サイトの構成を例にすると

当サイトは静的サイトで、構成は次のとおりです。

• Astro（アストロ）という道具を使う。公式ドキュメントによると、Astroは既定で、すべてのページを「ビルド」（公開前の書き出し作業）の時点で静的なページとして作ります。当サイトはこの書き出しだけを使っています
• 書き出したファイルはCloudflare Pages（クラウドフレア・ページズ）という配信サービスで公開している
• 原稿や設定はGitで履歴を管理し、変更を送ると自動でビルドと公開が行われる

公開までの流れはGitとは？｜Webサイト更新を安全にするバージョン管理の基本と公開までの流れで説明しています。

更新・速さ・保守の違い

仕組みの違いは、日々の運用の違いにつながります。

静的サイトにも保守はある

「静的サイトなら保守はいらない」と言われることがありますが、ゼロにはなりません。WordPressのような更新作業はなくなっても、ドメインの更新と名義、配信サービスやGitのアカウント（パスワードと二要素認証）、問い合わせフォームなどの外部サービス、制作に使う道具の版上げは管理が必要です。

ドメインの更新を忘れたときに起きることはSSL・ドメインの更新忘れで実際に起きることで扱っています。静的サイトは、守る範囲が小さくなる仕組みであって、守らなくてよい仕組みではない、と考えるのが正確です。

「WordPress以外」の乗り換え先は大きく4つ

WordPressをやめると決めても、行き先は静的サイトだけではありません。大きく分けると、次の4つの道があります。

1. WordPressを続けたまま、負担を減らす

やめる前に検討したい道です。負担の多くはWordPressのままでも減らせます。管理画面で自分で更新したい、ブログを頻繁に書く、という場合は、この道がいちばん合理的なこともあります。

2. ホームページ作成サービスに移る

画面上でページを作り、サーバーの管理はサービス側が引き受ける形のサービスです。WordPressと同じように管理画面から自分で更新でき、本体やプラグインの更新を自分で行う必要はありません。

その代わり、機能やデザインの自由度、月々の料金、解約時にデータをどこまで持ち出せるかは、サービスの規約で決まります。料金の総額と、将来やめるときの扱いを確認しておくと安心です。

3. 静的サイトに作り直す

前の章で説明した方式です。更新作業やサーバーの負担は小さくなりますが、文章を直すには制作者に頼むか、ファイルの扱いに慣れた人が社内にいる必要があります。

4. 静的サイトに、更新のための仕組みを組み合わせる

静的サイトの弱点である「自分で更新しにくい」を補う方法です。たとえば、次のような組み合わせがあります。

• 記事の管理だけを外部の管理サービス（ヘッドレスCMSと呼ばれます）に任せ、静的サイトはそこから内容を取り込んで書き出す
• 営業日やお知らせなど、よく変える項目だけを編集できる画面を用意する
• WordPressを編集用として非公開の場所に残し、公開する側だけを静的なファイルに書き出す。Cloudflareの公式ドキュメントにこの手順がありますが、変更のたびに書き出しと公開のやり直しが必要で、フォームやコメントは使えません

組み合わせが増えるほど複雑になるので、「何を、誰が、どのくらいの頻度で更新するか」に見合った分だけにします。

どれが正解ということはありません。自分で更新しやすいのは1と2、サーバー側の保守が小さいのは3と4です。次の章の「困ること」を確かめてから選びましょう。

やめて困ること：管理画面とプラグインの機能

乗り換えで失敗しやすいのは、WordPressが黙ってこなしていた仕事に、やめてから気づく場合です。代表的なものを確認していきます。

管理画面で自分で直せなくなる

静的サイトに作り直すと、WordPressのように、ログインして文章を書き換え、保存すればすぐ反映、という更新はできなくなります（4つ目の道で更新の仕組みを足した部分を除きます）。

ここで確かめたいのは、実際にどれだけ管理画面を使っていたかです。過去1年の更新を書き出してみてください。

• 営業日・臨時休業のお知らせ
• メニューや料金の変更
• ブログや新着情報の投稿
• 写真の差し替え
• スタッフ紹介や求人の更新

ほとんど更新していなければ、困ることは少ないでしょう。週に何度も更新していたなら、その項目だけでも自分で直せる仕組みを残すか、続けるほうが合っています。

プラグインが担っていた機能を洗い出す

管理画面の「プラグイン」の一覧から有効なものを書き出し、それぞれの役割と、静的サイトでの代え方を決めます。

当サイトも、フォームの送信は外部のフォームサービスに任せ、サイトマップは書き出しのときに自動で作っています。Cloudflare Pagesの「Functions」という機能を使えば、専用のサーバーなしにフォームの受け付けなどの処理も動かせます（公式ドキュメント）。

フォームを外部サービスに任せる場合は、送信内容が自社に届くか、自動返信がどうなるかを、乗り換えの前に試しておきます。フォームの作り方の注意点は問い合わせフォームで離脱を減らす｜項目数と自動返信にまとめています。

予約や会員の機能、毎日の記事更新など、動的な仕組みが中心なら、やめるのは得策ではないかもしれません。やめることで増える手間が、減る手間を上回るなら、続けるほうが合理的です。

乗り換えの進め方：記事とURLの扱い

乗り換えでいちばん気をつけたいのは、これまでに積み上げた記事と、そのURL（ページのアドレス）の扱いです。次の順番で進めると、取りこぼしが少なくなります。

手順1：ページと記事、URLを棚卸しする

まず、今のサイトにあるページと記事、そのURLを一覧にします。WordPressの公式ドキュメントによると、記事のURLの形は「パーマリンク設定」で決まり、記事番号を使う形（例：sample.com/?p=123）、日付と名前を使う形（例：sample.com/2008/03/31/sample-post/）、記事の名前だけの形などから選べます。カテゴリーやタグの一覧ページにもURLがあります。

Googleの検索の公式ドキュメントは、古いURLの一覧を作る手がかりとして、サイトマップ、アクセス解析で訪問の多いページ、CMSから取り出す一覧などを挙げ、画像のURLも同じように扱うよう書いています。

手順2：記事と画像を取り出す

WordPressには、記事を取り出す機能が標準で付いています。公式ドキュメントによると、管理画面の「ツール」→「エクスポート」で、投稿、固定ページ、コメント、カスタムフィールド、カテゴリー、タグ、ユーザーなどを含むXML形式のファイル（WXRと呼ばれます）をダウンロードできます。

注意したいのは画像です。取り込み機能の説明では、別のWordPressに取り込むとき「添付ファイルをダウンロードしてインポートする」を選ぶことで画像などを取り込めるとされています。つまり画像そのものは、記事のファイルとは別に取り出す必要があると考えておくのが安全です。サーバーから画像一式を受け取るか、制作を頼む相手に取り出しを依頼します。

あわせて、今のサイト全体のバックアップも取っておきます。戻せるバックアップの考え方はバックアップは「取っただけ」では戻せないをご覧ください。

手順3：残す・まとめる・消すを決める

記事ごとに、残す、まとめる、消す、のどれかを決めます。

Googleの検索の公式ドキュメントでは、移転で新しいサイトに移さないページは、新しいサイトで正しく「404」（見つからない）または「410」（削除済み）の応答を返すようにと案内しています。移す先のないページは、無理に転送先を探すより、なくなったことを正しく伝えるのが基本です。

手順4：古いURLから新しいURLへの転送を設定する

URLが変わるページは、古いURLを開いた人を新しいURLへ自動で案内する「転送（リダイレクト）」を設定します。Googleの検索の公式ドキュメントでは、検索結果に表示するURLを変えたい場合、できる限りサーバー側の恒久的な転送を使うよう勧めています。恒久的な転送は「301」または「308」という番号で表します。

同じくGoogleの移転のドキュメントでは、次の点も挙げられています。

• 古いURLと新しいURLの対応表を作り、サイト内のリンクも新しいURLに書き換える
• 転送を何段もつなげない（できれば新しいURLへ直接。つながる場合も、理想は3段まで）
• 転送はできるだけ長く、一般的には少なくとも1年は残す

静的サイトでも、サーバー側の転送は設定できます。当サイトが使っているCloudflare Pagesでは、公式ドキュメントによると、「_redirects」というファイルに古いURLと新しいURLを1行ずつ書いておくと、その規則どおりに転送されます。注意点として、番号を書かないと一時的な転送（302）として扱われるので、恒久的な転送にしたい行には「301」と明記します。書ける数には上限もあるので、ページ数が多い場合は公式ドキュメントで確かめてください。

手順5：ドメインはそのままで切り替える

サイトの仕組みを替えても、ドメインはそのまま使えます。新しいサイトの準備ができたら、ドメインの設定（DNS）で、サイトの行き先を新しい配信先に向け替えます。このとき、次の点に気をつけます。

• 古いサーバーは、新しいサイトに切り替わったことを確かめるまで解約しない
• 古いサーバーで会社のメールも受け取っているなら、解約でメールも止まるので、移し先を先に決めておく
• DNSを別の会社に移す場合は、メールなどの設定を書き写し忘れない

独自ドメインのメールの移し方は独自ドメインのメールをGmailのまま使う方法と導入手順で、サーバーを替えるときの考え方はレンタルサーバーの選び方と乗り換えの判断基準でも扱っています。

手順6：公開後に確かめる

切り替えたら、次の点を実際に操作して確かめます。

1. パソコンとスマホで、主なページと画像が表示されるか
2. 古いURLを開いて、新しいURLに転送されるか
3. 問い合わせフォームから実際に送信して、自社に届くか
4. 新しいサイトマップをサーチコンソールに登録したか

移転直後は検索の表示が揺れることがあるので、しばらく様子を見ます。

静的サイトへの乗り換えが向く会社・向かない会社

ここまでの内容をもとに、静的サイトへの乗り換えが合いやすいかどうかを整理します。

向いている会社・お店

• 更新は営業日の変更や年に数回のお知らせくらいで、更新する項目が決まっている
• 会社案内やお店の案内が中心で、ページ数が多くない
• 更新や保守を誰が担当するか決まっておらず、制作会社とも疎遠になっている

向いていない会社・お店

• 毎日、あるいは週に何度も、複数の人が記事を書いている
• 予約、ネットショップ、会員ページなどを自分のサイトの中で動かしている
• 社内にWordPressに慣れた担当者がいて、更新も保守も回っている
• 思い立ったときに、自分ですぐ文章を直したい

「向いている」に多く当てはまるなら、WordPressの便利さのうち、使っていない部分のために手間と費用を払っている可能性があります。

判断に迷ったときの3つの質問

やめるかどうか、やめるならどこへ行くかを決めるための質問を3つ挙げます。紙に書き出して答えてみてください。

質問1：過去1年、誰が、何を、何回更新したか

更新の実績は、いちばん確かな判断材料です。特定の項目だけ頻繁に更新しているなら、その項目だけ自分で直せる仕組みを考えます。誰も更新していないのに保守費を払っているなら、まず契約を見直す段階かもしれません。

質問2：プラグインを外したら、困る機能はどれか

有効なプラグインごとに「なくなったら困るか」を答え、困るものは代わりの方法と費用を確かめます。困る機能が多く、どれも自分のサイトの中で動かす必要があるなら、続けるほうが合っています。

質問3：減らしたいのは、手間か、費用か、心配か

最初の章で分けた3つの理由のうち、どれをいちばん減らしたいのかを決めます。

• 手間なら、更新を頼める相手を決めるだけで解決することもある
• 費用なら、今の内訳を分けてから比べる（乗り換えの費用も含めて）
• 心配なら、守る範囲を小さくする静的サイトは有力な選択肢になる

静的サイトへの乗り換えは、「自分ですぐ直せる自由」と引き換えに「守る手間」を小さくする選択です。この交換が得かどうかが、判断の軸になります。

まとめ

• 2026年10月のPHPの重大な脆弱性では、WordPressの更新は不要で、PHPの版の確認と更新が必要。8.2.35・8.3.36・8.4.27・8.5.12以上か確かめる
• WordPressは悪い道具ではない。やめたい理由は、更新の手間・セキュリティの心配・費用の3つで、WordPressのまま減らせることもある
• 静的サイトは、ページを公開前に書き出しておく方式。公開側で動くプログラムがないため守る範囲が小さくなるが、自分で更新しにくく、保守もゼロにはならない
• 乗り換え先は、WordPressを続ける・作成サービス・静的サイト・静的サイト＋更新の仕組みの4つ
• やめる前に、管理画面の使い方と、プラグインが担っていた機能を洗い出す
• 記事とURLは、棚卸し→取り出し（画像は別に）→整理→301の転送→切り替え→確認の順で進める

当スタジオは静的サイトを基本にしており、当サイトもAstroで書き出し、Cloudflare Pagesで公開しています。今のサイトを続けるか乗り換えるかの整理からでもかまいませんので、迷ったときは格安パッケージをご覧いただくか、お問い合わせからお声がけください。