WordPress is Dead？乗り換え後も続く対処と、専門家の必要性

監修: 菊地 将（リブランディング株式会社）

2026年10月22日、情報処理推進機構（IPA）が、PHPの脆弱性（PHP2shell）への対策を公表しました。WordPressの動作要件にはPHPが含まれ、PHPのバージョンの更新が欠かせません。そのため、「WordPressはもう時代遅れではないか」「乗り換えたほうがよいのでは」と考える運営者もいるでしょう。では、すでにWordPressから別の基盤へ乗り換えたサイトは、問題なく運営できているのでしょうか。弊社は、乗り換えたと公開している117サイトを調べました。弊社の基準で不具合に分類した状態が1つ以上見つかったのは、34サイトです。乗り換えたと公開しているサイトでも、見続ける作業は残ります。この記事では、調査の結果、直しても終わらない外部要因、乗り換え前後に確認したい項目を順に整理します。

「WordPress is Dead？」と言われても、利用はまだ多い

ウェブサイトで使われている技術の利用率を集計する調査サービスW3Techsによると、2026年11月3日の表示で、WordPressは「コンテンツ管理システムが判明しているサイトの58.2％」、「全ウェブサイトの39.5％」で使われています。W3Techsの履歴では、全ウェブサイトに占めるWordPressの割合は、2025年11月の43.2％から2026年11月の39.5％へ下がっています。それでも、今も多くのサイトがWordPressで動いています。

利用が多いからこそ、今回のPHPの件は問題になります。IPAは、PHP 8.2.35より前の8.2系、8.3.36より前の8.3系、8.4.27より前の8.4系、8.5.12より前の8.5系が対象だとして、「開発者が提供する情報をもとに、最新版へアップデートしてください。」と呼びかけています。さらに、「更新や移行が完了するまで、脆弱な状態での運用を放置せず、利用環境に応じた暫定対策やアクセス制限を検討してください。」とも述べています。WordPressで動くサイトは、動かしているPHPのバージョンを確認し、必要なら更新しなければなりません。利用が多いぶん、対応が必要になるサイトも多くなります。

WordPress側にも、見続ける作業があります。WordPressのセキュリティ情報を扱う企業のPatchstackは、2025年にWordPressのエコシステムで見つかった新しい脆弱性が11,334件だったと報告しています。2026年7月22日には、IPAが、WordPressの脆弱性（脆弱性に付ける共通の識別番号CVEで、CVE-2026-60137とCVE-2026-63030）に関する注意を出しました。IPAは、運用環境や設定によっては自動更新が有効でなかったり、更新に失敗していたりする可能性があると述べています。

WordPress本体の仕組みも確認しておきます。WordPressの公式ドキュメントによると、既存のサイトは、軽微な修正を含むマイナーなコア更新を既定で受け取ります。一方、プラグインとテーマの自動更新は「特別な場合」にしか行われないとされています。本体は自動で更新されても、プラグインやテーマは別に見る必要があります。

ここまでは、WordPressを続ける場合の話です。では、すでに乗り換えたサイトは、どのような状態にあるのでしょうか。弊社が調べました。

調査の対象と方法

調査の対象は、WordPressから別の基盤へ乗り換えた、または移ったと公開している組織や個人のサイトです。公開情報から候補を集め、次の条件で除きました。件数は一覧の行やURLの単位で数えているため、212から除外分を引いた値は、調査したサイト数と一致しません。複数のURLが書かれた行は1URLごとに1サイトとして数え、ドメインが同じものは1つにまとめたためです。

区分	件数
入力した候補（3つの一覧の行数の合計）	212
除外：サイトのURLが空、またはURLの形式でない	72
除外：ホスト型サービス上のURL（ブログサービスなど）	18
除外：入力時点で公開状態を取得できなかったもの	6
調査したサイト（複数URLの行を分けて数え、同じドメインを1つにまとめた数）	117

調査は2026年11月3日の2時5分から2時25分（日本時間）にかけて行いました。取得したのは公開ページと公開の応答だけです。検索エンジンなどの巡回の可否を示すファイル（robots.txt）の指定を守り、同じホスト（ドメイン）へは1秒に1回以下、1サイトあたり最大60回のリクエスト（ページを取得する通信）にとどめました。見た項目は、HTTPSと証明書、セキュリティ関連のヘッダー、メールの認証設定、内部リンク、サイトマップ、検索エンジン向けの設定、構造化データなどです。

結果は3つに分けました。「不具合」は、弊社の判定基準で、観測された挙動が仕様に反する、または利用者や検索エンジンの巡回に支障が出る状態としたものです。各項目の判定条件は、次の章の表に示します。「推奨未満」は推奨に届かない状態、「情報」は事実のみを記録する項目です。この記事の「34サイト」は、不具合に分類した項目に1つ以上当てはまったサイトの数です。推奨未満と情報は含めていません。

117サイト中34サイトで、不具合が見つかった

不具合に分類した項目に1つ以上当てはまったのは、117サイト中34サイト（約29％）でした。項目別の内訳は次のとおりです。1つのサイトが複数の項目に当てはまることがあるため、サイト数の合計は34を超え、のべ39になります。

項目	該当サイト数	見つかった状態
画像のalt属性がない	12	img要素（画像）に、代替テキストを示すalt属性がない（装飾を示す指定のある画像は除く）
内部リンク切れ	8	サイト内のリンク先が404・410・5xxの応答を返す、または接続できない
サイトマップの不備	4	解析できない、または別ホストやhttpのURLを含む
サイトマップのlastmod（更新日）の形式不正	4	更新日の値が、日時の標準書式（W3C Datetime）になっていない
トップ・サイトマップ掲載ページのnoindex	3	トップやサイトマップに載っているページに、検索結果へ載せない指定（noindex）がある。意図した設定かどうかは確認していない
SPFレコードの重複	3	メールの送信元認証（SPF）の設定が複数あり、エラーになる
取得したページの非200	2	サイトマップやリンクから取得したページが、4xxや5xxの応答を返す、または転送が繰り返される
構造化データ（JSON-LD）の構文エラー	2	検索エンジン向けのデータ（JSON-LD）が、JSONとして解析できない
能動的な混在コンテンツ	1	HTTPSのページが、httpのスクリプトなどを参照している（ブラウザでの実際の読み込みまでは確認していない）

SPFについては、インターネットの技術仕様を定める文書であるRFC 7208が、同じドメインに複数のレコードを持たせることを禁じています。同RFCには、該当するレコードが複数あるとき、結果はpermerror（恒久的なエラー）になると書かれています。設定した本人は認証を通しているつもりでも、受信側では認証が成立しません。

不具合は、1つの領域に収まらなかった

弊社の判定基準で不具合に分類した9項目の該当サイト数です（117サイト中、1つ以上に該当したのは34サイト）。1つのサイトが複数の項目に当てはまるため、合計は34を超えます。

内訳を見ると、不具合は検索流入（SEO）、HTMLの作り、メール、セキュリティの複数の領域にまたがっています。件数が多いのは、alt属性、内部リンク切れ、サイトマップ、noindexといった、サイトの作りと運用に関する項目でした。セキュリティに関する不具合は、混在コンテンツの1サイトにとどまります。メールの認証に関するものは、SPFの重複の3サイトです。移行や公開の前に、noindexやリダイレクトの事故を防ぐ確認は、SEOリリース前チェックの作り方で整理しています。

不具合には当たらないものの、確認できた事実がほかに2つあります。

• 既知の脆弱性が登録されているバージョンのライブラリを、公開ページから確認できたサイトが7サイトありました。確認できたバージョンは、jQuery 1.8.3、1.12.4、2.1.3、Bootstrap 3.4.1、Swiper 9.0.5と12.0.0です。ライブラリ名とバージョンが一致する既知の脆弱性が、公開データベースのOSVに登録されているという照合結果です。これは「推奨未満」の区分で、34サイトには含めていません。実際に悪用できるかは検証していません。
• HTMLの中に、wp-contentなどWordPressの痕跡が残るサイトが26サイトありました。WordPressと新しい基盤を併用している、あるいは乗り換えの途中という可能性があります。

不具合の領域がこれだけ広がっていることは、ひとつの専門分野だけで確認すると見落とす項目が出やすい、と弊社は考えます。サイトの技術面を領域ごとに確認する方法は、テクニカルSEOの7領域の実務チェックリストで解説しています。

直しても終わらない、外から来る期限と更新

CA/Browser Forumの基準（Baseline Requirements）に記載された、発行日が各日付以降の証明書の最大有効期間です。

調査で見つかった不具合を直しても、運用は終わりません。サイトの外側で決まる期限や更新が、時間とともに来るためです。公式文書で確認できたものを表にまとめます。

項目	公式文書で確認できる内容	運用への影響
PHP（WordPressなどが動くプログラミング言語）の脆弱性対策	IPAは2026年10月22日、PHP 8.2.35より前の8.2系、8.3.36より前の8.3系、8.4.27より前の8.4系、8.5.12より前の8.5系を対象に、最新バージョンへのアップデートを求めた	動かしているPHPのバージョンを把握し、更新する必要がある
PHPのサポート期間	各リリースは初回の安定版から2年間は通常のサポート、その後さらに2年間は重大なセキュリティ問題に限ったサポート	使っているバージョンの終了日を把握し、期限前にバージョンを上げる必要がある
TLS証明書（通信を暗号化するHTTPSの証明書）の有効期間	ウェブサイトの証明書に関する基準（Baseline Requirements）を定めるCA/Browser Forumでは、発行日が2026年3月15日以降の証明書の最大有効期間は200日、2027年3月15日以降は100日、2029年3月15日以降は47日	更新の間隔が短くなるため、手作業の更新は漏れやすい
jQueryのサポート	公式は最新バージョンのみをサポートし、1.xと2.xはサポート終了。3.xは重大なセキュリティ修正とバグ修正のみ。4.xが現行	サポートが終わった1.xや2.xを使い続けると、修正が提供されない
メールの送信者要件	Googleは2024年2月1日以降、Gmail宛てに1日5,000通を超えて送る送信者に、SPF（送信元の認証）、DKIM（メールへの電子署名）、DMARC（認証に失敗したメールの扱いを送信側が示す仕組み）の設定を求めている	送信元の認証設定が不十分だと、届かなくなるおそれがある
WordPressの更新	マイナーなコア更新は既定で自動。プラグインとテーマの自動更新は特別な場合のみ	本体以外は、担当者が更新を見る必要がある
依存パッケージ（サプライチェーン）	米国の政府機関であるCISA（Cybersecurity & Infrastructure Security Agency）は2025年9月23日、自己増殖型のワーム「Shai-Hulud」が500を超えるnpmパッケージ（JavaScriptのソフトウェアを配布する仕組みで公開されたもの）を侵害したと注意喚起した	開発で使うパッケージの側で起きた侵害が、自社のサイトに及ぶことがある

WordPressから静的なサイトやクラウドのサービスへ乗り換えても、この表のうち多くは当てはまります。証明書、メールの認証、使っているソフトウェアの更新は、基盤を問わず発生する作業です。

この結果から言えること

今回の調査結果から、次のことが言えます。

• WordPressから乗り換えたと公開している117サイトのうち、34サイトに、弊社の基準で不具合に分類した状態があった
• 不具合は、SEO、HTML、メール、セキュリティの複数の領域にまたがっていた
• 証明書やPHP、ライブラリなどには、サイトの外側で決まる期限や更新がある

弊社の見解：日頃から備える体制と、運用を守れる専門家が要る

サイトの基盤が変わっても、証明書、メールの認証、使っているソフトウェアの更新は基盤を問わず発生する作業です。

ここからは、調査結果を踏まえた弊社の考えです。調査の数字から直接導いたものではありません。

乗り換えやメンテナンスは、サイトの状態を見直す大きな機会です。ところが、今回調べた117サイトのうち34サイトで、不具合に分類した状態が見つかりました。今回のPHPの件のように騒ぎになってから一度行うだけでは足りず、日頃から、継続して対処する体制が必要だと考えます。証明書、PHP、ライブラリ、メールの認証など、外から来る更新は、騒ぎが収まったあとも続くからです。

サイトの乗り換えは、専門的な作業です。乗り換えたと公開しているサイトでも不具合が見つかっているのですから、運用を専門知識のない担当者だけで続けるのは、さらに難しくなると考えます。運用に求められる専門性は、今後さらに高まっていくと考えます。

AIによって、サイトを作れる会社や個人は、今後も増えていくと見ています。一方、公開したあとに更新や脆弱性への対応を続け、サイトを守れる人は、同じ速さでは増えないと考えます。サイトを作る作業が簡単になっても、証明書の更新、PHPやライブラリの更新、メールの認証、検索まわりの設定は、作ったあとも続きます。しかも、HTML、メール、セキュリティ、検索と、複数の領域にまたがります。今回の調査で、不具合が1つの領域に収まらなかったことも、その表れです。

今後重要になるのは、サイトを作る人よりも、管理と運用を守れる人です。IPAの中小企業向けのガイドラインにも、セキュリティの専門家を探したい人向けの案内があります。AIO（AI検索への対応）の導入を内製するか外注するかの考え方は、AIO導入の体制構築の判断基準で整理しています。

乗り換え前後に確認したい項目

乗り換えの前後に、確認しておきたい項目を表にしました。調査で見つかった状態と、公式文書で確認できた期限や更新に対応しています。

確認項目	見る場所と内容
証明書の更新	有効期限の通知先と、自動更新の仕組みがあるか。有効期間の上限が短くなる予定を踏まえ、手作業に頼っていないか
PHPなどのバージョン	使っているバージョンが公式のサポート期間内か。終了日を把握しているか。IPAが示した対象のバージョン（8.2系は8.2.35より前など）を使っていないか
JavaScriptライブラリ	jQueryなどのバージョンが、公式にサポートされているバージョンか。古いバージョンを呼んでいる箇所が残っていないか
メールの認証	SPF、DKIM、DMARCが設定されているか。SPFのレコードが複数になっていないか
内部リンクと旧URL	乗り換え後に、サイト内のリンク先が404になっていないか。旧URLから新URLへの転送が設定されているか
サイトマップ	解析できるか。別ホストやhttpのURLが混ざっていないか。更新日の書式が正しいか
noindexの指定	検索に出したいページに、noindexが残っていないか
構造化データ	JSON-LDの構文が壊れていないか
画像のalt属性	画像に代替テキストの属性があるか
旧環境の扱い	旧WordPressの管理画面や、wp-contentなどが公開されたまま残っていないか
更新の担当	プラグイン、テーマ、依存パッケージの更新を、誰がいつ確認するかが決まっているか

すべて確認できても、不具合がないことが保証されるわけではありません。確認できていない項目や、分からない項目から、順に見てください。サイトマップの見方は、XMLサイトマップの確認方法で解説しています。

まとめ

PHPの脆弱性への対応が呼びかけられる今、WordPressを続ける場合も、別の基盤へ乗り換える場合も、サイトを守る作業は終わりません。WordPressから乗り換えたと公開している117サイトを調べたところ、34サイトで、弊社の基準で不具合に分類した状態が見つかりました。

チェックリストは、この調査に限らず、さまざまな形で出回っています。ただ、リストがあっても、続々と見つかる脆弱性やエラー、期限の変更に、継続して対応しなければ意味がありません。最終的には、専門知識を持つ専門家に依頼し続けることが、サイトを守る現実的な方法だと弊社は考えます。

参考文献・データ元

関連記事

• › テクニカルSEOとは？クロールからセキュリティまで、企業担当者が押さえるべき7領域の実務チェックリスト
• › SEOリリース前チェックの作り方｜noindex・canonical・robots・リダイレクトの事故を防ぐ
• › XMLサイトマップの確認方法｜送信URL・更新日・エラーをチェック

関連テーマ

AIO SEO MEO 口コミ・風評対策 採用改善