みなさん、こんにちは。
2026年8月に入ったある日、WordPressのサイトヘルスチェック画面を開くと、見慣れない警告が突然表示されていることに気づきました。
「古いデータベースサーバー」
これまで「WordPress本体もプラグインも、とりあえず常に最新化しておけば安心！」という運用を続けていたのですが、今回の警告はデータベース（MariaDB）に関するもの。
データベースが古いまま無計画にプラグインの更新を続けていくと、どこかで互換性問題が発生してサイトが真っ白…なんてことにもなりかねません。
そこで今回は、現状のサーバー環境をしっかり整理し、「サイトを壊さない範囲で必要な対応」を行ってみたので、その手順と運用方針をまとめておきます。
サイトヘルスの警告内容と現在の環境を確認
警告の内容を詳しく調べてみると、以下のような状況がわかりました。
- 内容： データベースサーバーがWordPressの推奨バージョンより古い
- リスク： 将来的に互換性問題が発生する可能性がある
しかし、データベース周りはユーザー側でバージョンを自由に変更できる領域ではなく、ホスティング会社（サーバー運営側）による基盤アップデートを待つ必要があります。
そこで、運用している XREA（エクスリア）サーバー の環境とWordPressの推奨環境を照らし合わせてみました。
推奨環境と実際のスペック比較
私が使用しているWordPress 7.1の推奨環境は以下のとおりです。
- PHP： 8.3 以上
- MariaDB： 10.11 以上
対して、現在のサーバー環境を確認してみた結果がこちらです。
- PHP： 8.3（推奨環境をクリア！）
- MariaDB： 10.6（動作はするが、推奨からは外れつつある…）
PHPはしっかり新しいバージョンに対応できていましたが、MariaDBが推奨より古い状態でした。これで警告の原因がMariaDBにあると確定です。
XREAのサーバー更新に関する見通し
利用しているXREAはWordPressのワンクリックインストールを提供しているサービスでもあるため、古いデータベースを長期間そのまま放置するとは考えにくい状況です。
実際、前回の大きな基盤アップデート（2022年9月）では以下のような更新が行われていました。
- 移行内容： MySQL 5.7 → MariaDB 10.6
- 停止時間： 6時間。ただし、順次アップデートのため、実際に自分のサーバーが停止したのは数分程度と思われる
今回の MariaDB 10.6 は 2026年7月に公式EOL（サポート終了） を迎えているため、そう遠くない未来に運営側で再度の基盤アップデートが入るはずだと見ています。
ユーザー側で直接MariaDBを操作できない以上、「しばらくはこの状態で安全に維持しつつ、運営側の更新を待つ」 という方針をとることにしました。
更新ポリシーの緊急見直し
XREAのコントロールパネルを確認したところ、前述の通り、PHPは php83（8.3）を設定していたため問題ありません。
一方で、WordPressやプラグインの更新ポリシーが曖昧なままになっていたため、今回の警告を機にサイトを壊さないための自動更新停止ルールを設定しました。
今回実施した対応
1. WordPress本体のメジャー更新を停止
インストール済みのプラグイン「WPCode」を使って、メジャーアップデートが自動で実行されないように制限しました。（※セキュリティに関わるマイナー更新は許可したままにします）
【設定手順】
- WordPress管理画面 → WPCode
- 新規スニペットを追加
- タイプ： PHP Snippet / 挿入方法： 自動挿入 / 場所： あらゆる場所で実行
- 以下のコードを貼り付けて保存・有効化
add_filter( 'allow_major_auto_core_updates', '__return_false' );
WPCodeについては下記の記事も参考にしてください。
2. プラグインの自動更新を停止
古いデータベース環境のまま互換性チェックなしで最新版へ上げるのはリスクが高いため、今後は「必要に応じて手動で更新する」運用に切り替えました。
重いプラグインの棚卸しと削除
サイトへの負荷を抑え、トラブルを未然に防ぐために「本当に必要なプラグインだけを残す」整理もあわせて行いました。
削除したプラグイン
- Elementor
- 固定ページ一覧を確認したところ、Elementorで構築されたページが1つも存在しなかったため。無効化しても全ページが正常表示されることを確認し、そのまま削除しました。この環境では「入っているだけで重い」存在だったので、判断はスムーズでした。
負荷は重いが残したプラグイン
- All in One SEO (AIOSEO)
- 評判は正直微妙なところもあるが、SEO設定やRSSで使用しているため残す（更新は手動で慎重に）。
- Site Kit by Google
- 管理画面から最近の投稿のPVを手軽に確認できて便利なので残す（更新は手動で慎重に）。
その他の軽量プラグインは動作に影響していないため、現状維持としています。
今後の方針 – 運営側のDB更新を待ちながら安定運用
今回の調査と対応で、環境が綺麗に整理されました。
- PHP 8.3
- 推奨範囲内で問題なし
- MariaDB 10.6
- 推奨から外れつつあるため、XREA側の更新待ち
- WordPress本体
- メジャー更新を停止（手動管理）
- プラグイン
- 自動更新を停止＆Elementor削除で大幅に軽量化
結論として、「しばらくはこの構成で安定運用しつつ、XREA側の次の基盤アップデートを待つ」 という方針に落ち着きました。
MariaDBはユーザーが触れない領域だからこそ、こちら側ではWordPressとプラグインを「壊れない構成」に整えておくことに集中した形です。
インフラ維持には現実的な選択も大切
2026年8月に届いた「古いデータベースサーバー」という警告をきっかけに、XREA上のWordPress環境をじっくり見直す良い機会になりました。
「常に最新化するのが正解」と思い込みがちですが、インフラの状況によっては「今の環境で壊さずに動かし続けるための現実的な選択」も大切だと実感しています。
もし同じような警告が出て焦っている方がいれば、まずは一度冷静に環境を整理し、壊れない設定から試してみてはいかがでしょうか。
本日も最後までお読みいただきありがとうございました。
それでは、よいWordPressライフを！
【追記】Elementor削除後にGA4のPVが激減！？予期せぬトラブルと解決策
Elementorを削除して「これで環境もスッキリ軽量化できた！」と安心していたのですが、直後に思わぬトラブルが発生しました。
なんと、Google アナリティクス（GA4）のPV（ページビュー）が突然まったく集計されなくなってしまったのです。
発生した症状
- リアルタイムレポート： 正常に動く
- イベント：
ad_impressionなどは問題なく届く - PV・セッション数： 極端に激減（ほぼゼロ）
「イベントは届いているのに、なぜかPVだけが欠損する」という不可解な現象が発生していました。
原因はElementor削除による head 構造の変化とSite Kitのタグ不一致
結論から言うと、原因は Site Kitが挿入するGoogleタグ（GTタグ）とGA4データストリーム（Gタグ）の内部状態のズレ でした。
<head>構造の変化
Elementorを削除したことで、テーマの<head>内のHTML構造が変化しました。- Site Kitの誤認とタグ再挿入
Site Kitが「タグの構成が変わった」と判断し、Googleタグ（GT-xxxx）を新たに自動挿入。 - データストリームの不一致
GA4側は従来の測定ID（G-xxxx）のデータストリームで受信を待っていたため、「ページ側は GT タグで送信しているのに、GA4 側は G のデータを待っている」 という状態になり、PV計測だけが落ちてしまいました。
※なお、広告イベント（ad_impression）などは別ルートで送信されるため、PVが壊れていても届いていました。これが「イベントは動くのにPVだけ減る」原因です。
DevToolsで確認できた実際の状態
ブラウザのDevToolsで <head> 内のソースコードを確認してみると、以下のような「併存による不一致」が起きていました。
- Site Kitにより GT タグが有効化されている
<script src="https://www.googletagmanager.com/gtag/js?id=GT-xxxxx"> gtag("config", "GT-xxxxx"); - 従来の G タグ（測定ID）側はログインユーザー除外設定で無効化されている
window["ga-disable-G-xxxxx"] = true;
つまり、「GTタグは動作しているが、GA4が参照しているGタグ側が不一致＆無効化状態」になっていたのが原因でした。
※欠損期間について
異変に気づくまで約1日半かかりました。GA4は過去データを後から補完・復旧することはできないため、この1日半のPVデータは残念ながら欠損したままとなります。
解決方法 – Site Kit の「切断 → 再接続」
最終的に、Site Kitの設定を一度リセットして繋ぎ直すことで完全に復旧しました。
復旧手順
- WordPress管理画面 → Site Kit → 設定 → Analytics
- 「アナリティクスを Site Kit から切断」 を実行
- 再度 Analytics を接続し直す
- 「アナリティクスのコードを配置」 のスイッチをオンにする
この操作を行うことで、GTタグとGタグの転送設定が再構築され、GA4がGTタグを正しく検出できるようになりました。現在はPV・セッション数ともに正常な数値へ戻っています。
プラグインの整理（特にページビルダー系やヘッダーに影響を与えるプラグインの削除）を行った際は、見た目の崩れだけでなく「アクセス解析タグが正しく発火しているか」まで確認することが大事だと痛感しました。
今回のような検証、「うちの環境ではどうなんだろう？」と気になった方はいませんか。
ビューローみかみでは、構想段階の壁打ちからPoC・実装・現場導入まで、現場で「使い続けられる」ものづくりを支援しています。
技術顧問サービスでは、本記事のような技術的な質問・検証にも継続的にお答えしています。「相談したら契約」ということはありません。システムを作らない判断も含めて、率直にお話しします。
▶ 技術顧問サービスの詳細はこちら
気になることがあればお気軽にご相談ください。
