WordPressのプラグインを整理したくても、「削除したら表示が崩れないか」「必要なデータまで消えないか」と、不安になることはありませんか。
一方で、以前から動いているプラグインでも、WordPressやPHPの環境が変わると、問題が表面化する場合があります。
Webuzzが管理を担当しているサイトのテスト環境でも、致命的エラーや非推奨の通知を確認し、利用状況などを見直したうえで、対象のプラグインをテスト環境から削除しました。
削除する前に確認したいのは、そのプラグインが担う役割と、なくなった場合の影響です。
この記事では、実際の判断例を交えながら、残す・削除する・代替する目安と、削除前後の確認手順を紹介します。
もくじ
WordPressプラグインを削除する前に、役割を確認する
最初に、「何のために入れたプラグインか」を確認しましょう。
自分では使っていないつもりでも、公開中のページや、ほかの機能から利用されている可能性があります。
例えば、フォームやアクセスカウンターは、プラグインを止めると必要な機能が使えなくなる場合があります。
記事内にショートコードという呼び出し用の記法を入れている場合は、停止後に表示が変わったり、記法がそのまま残ったりすることもあります。
管理画面の「プラグイン」一覧で説明や設定へのリンクを確認し、どこで使っているかを調べます。
| 確認先 | 見ること |
|---|---|
| プラグインの設定画面 | 有効な機能と、その用途 |
| 投稿・固定ページ | 専用ブロックやショートコードの使用 |
| ウィジェット | カウンターなどの表示機能 |
| テーマや独自コード | プラグインの機能を直接呼び出していないか |
| 関連するプラグイン | 停止すると困る依存関係がないか |
ショートコードを使うプラグインなら、公式説明で記法を確認し、その文字列を投稿・固定ページから探す方法があります。
ただし、管理画面の検索だけですべての使用箇所が見つかるとは限りません。
テーマ側の確認が必要な場合は、制作・管理担当者にも相談しましょう。
無効化と削除は、操作の意味が異なる
無効化は、プラグインの通常の機能を止め、ファイルを残す操作です。
一方、削除はプラグインのファイルを取り除く操作で、プラグイン側の実装によっては、設定や保存データの削除処理も実行されます。
WordPress公式の開発資料（英語）でも、無効化とアンインストールは区別されています。
「まず無効化して影響を見ること」と、「削除すること」は、分けて考えましょう。
＊公式資料は2026年10月24日に確認しました。
残す・削除する・代替する判断の目安
役割が分かったら、今も必要な機能か、現在の環境で使い続けられるかを確認します。
数を減らすことだけを目的にせず、必要性と保守状況を組み合わせて判断しましょう。
| 確認できた状況 | 対応の目安 |
|---|---|
| 必要な機能で、問題なく利用できている | 継続利用し、更新や対応状況を確認する |
| 機能を使っておらず、停止による影響もない | 削除を検討する |
| ほかの機能と重複している | 役割を整理し、不要な側の停止を検討する |
| 必要な機能だが、不具合や互換性の問題がある | 更新・修正情報を確認し、必要なら代替を検討する |
| 用途や影響が分からない | 削除を保留し、使用箇所を調べる |
更新が長く止まっている場合は、現在のWordPressやPHPへの対応状況、公式サイトの案内、サポート情報も確認します。
ただし、最終更新が古いという情報だけで、今の環境で使えないと断定はできません。
同様に、非推奨の通知が出たことと、処理を停止させる致命的エラーが出たことも、同じ状態ではありません。
必要な機能か、何が起きているか、今後も維持できるかを確認して、対応を選びます。
テスト環境で問題が出たプラグインを削除した事例
Webuzzでは、管理を担当しているサイトをWordPress 7.1.3・PHP 8.3系の環境へ移す検証のため、Dockerイメージを使ったテスト環境を用意しました。
テスト環境のWordPressと、対象プラグインのバージョンは次のとおりです。
| 対象 | バージョン |
|---|---|
| WordPress | 7.1.3 |
| Count per Day | 3.6.1 |
| Audit Trail | 1.2.4 |
＊テスト環境での確認日：2026年10月23日
この環境で、Count per Dayには致命的エラー、Audit Trailには非推奨の通知が出ていることを確認しました。
以下は、今回のテスト環境での確認結果と、そこで削除を判断した経緯です。
Count per Dayは、移行先のテスト環境で致命的エラーが発生
アクセス集計に使っていたCount per Dayは、現在の本番サイトでは動作しています。
しかし、今回のテスト環境に入れたところ、古い配列・文字列のアクセス構文に関する致命的エラーが出ました。
処理が停止する種類のエラーだったため、このテスト環境では使えないと判断し、削除しました。
本番で動いていることと、移行先の環境でも使えることは別です。
また、記事制作時にWordPress.orgの公式掲載ページ（英語）を確認したところ、2019年10月27日付で閉鎖され、ダウンロードできない状態でした。
理由は「ガイドライン違反」と表示されています。
これは後から確認した公開情報であり、閉鎖の理由が今回のエラーの原因だったという意味ではありません。
Audit Trailは、利用状況も見直して削除
操作履歴を記録するAudit Trailでは、動的プロパティの作成に関する非推奨の通知が出ました。
Count per Dayの致命的エラーとは異なり、この通知自体が処理停止を示していたわけではありません。
もともとは、万一に備えて履歴を残すために入れたもので、普段はほとんど確認していませんでした。
更新が止まっていたことと、今回の通知も踏まえて利用状況を見直し、テスト環境から削除しました。
記事制作時に確認した公式掲載ページ（英語）にも、最新3つのWordPressメジャーリリースでテストされていない旨の注意書きがありました。
この事例の判断は、「非推奨の通知が出たから必ず削除する」というものではありません。
ほとんど使っていない機能を残す必要があるか、保守状況も含めて考えた結果です。
＊公式掲載ページは2026年10月24日に確認しました。テスト環境での確認結果と、後から確認した公開情報を分けて記載しています。
プラグインを削除する手順
ここからは、WordPressの管理画面を操作できる場合の基本的な手順です。
今回の事例ですべての作業を実施したという意味ではなく、削除時に確認したい一般的な進め方を整理しています。
削除前に、設定・データ・バージョンを残す
まず、削除対象の名前とバージョン、WordPressとPHPのバージョンを記録します。
使用していたバージョンを記録しておくと、後から不具合や対応状況を調べる際の手がかりになります。
設定画面の記録に加え、必要な履歴や集計データがあれば、保存・エクスポートの方法も確認してください。
別のプラグインに切り替える場合も、過去のデータをそのまま引き継げるとは限りません。
削除後に何が消えるかと、残したいデータをどう保存するかを、先に確認します。
ファイルとデータベースをバックアップする
設定のメモや画面の保存だけでは、サイト全体を元に戻せません。
削除前には、WordPressのファイルとデータベースをバックアップし、復元方法も確認しておきましょう。
サーバーの自動バックアップを使う場合は、取得日時、保存対象、利用できる復元方法を確認します。
バックアップがあるつもりでも、必要な時点へ戻せるかが分からなければ、作業後の対応に迷います。
可能であれば、テスト環境で停止・削除による影響を先に確かめます。
対象を1つずつ無効化し、影響を確認して削除する
WordPress公式の案内（英語）では、管理画面から対象を無効化し、その後に削除する流れが示されています。
基本の操作は、次のとおりです。
- 「プラグイン」から「インストール済みプラグイン」を開く。
- 対象の名前を確認し、「無効化」を選ぶ。
- 関連するページや機能に、想定外の影響がないか確認する。
- 不要と判断でき、データ保存も済んでいれば「削除」を選ぶ。
- 確認画面の内容を読み、削除を実行する。
複数をまとめて止めると、変化が出た際に原因を切り分けにくくなります。対象を1つずつ扱い、変更内容と確認結果を残しましょう。
無効化した時点で問題が出たら、そのまま削除せず、使用箇所や依存関係を調べます。
管理画面に入れない場合の対処は、この手順とは別です。
原因が分からないまま、サーバー上のフォルダをまとめて消すことは避けてください。
＊公式資料は2026年10月24日に確認しました。
削除後は表示・機能・データを確認する
削除の完了メッセージが出ても、確認は終わりではありません。
トップページだけでなく、そのプラグインと関係する場所を優先して調べます。
| 確認対象 | 確認すること |
|---|---|
| 主要ページ | 表示崩れやエラーがないか |
| 記事・ウィジェット | 専用表示やショートコードが不自然に残っていないか |
| 関連機能 | フォーム、検索、カウンターなどが想定どおりか |
| 管理画面 | ログインや必要な操作ができるか |
| 代替機能 | 切り替え後の表示・設定・計測が正しいか |
削除するプラグインによっては、SEO設定やリダイレクトなど、見た目だけでは分かりにくい機能にも影響します。
「ページが開いたから大丈夫」とせず、削除前に整理した役割に沿って確認しましょう。
また、削除時に設定やデータが消えていれば、再インストールするだけでは元の状態に戻せません。
削除後に問題が出た場合は、変更記録をもとに原因を確認し、必要に応じて保存した設定やバックアップからの復元を検討します。
プラグインは、必要な機能を確認してから整理しよう
プラグインを削除してよいかは、今の役割と、停止・削除した場合の影響を確認して判断します。
「以前から動いているから残す」「更新が古いから削除する」と、1つの情報だけで決めず、機能の必要性や対応状況、実際に起きている問題を合わせて確認しましょう。
今回の事例では、本番で動いているCount per Dayでも、移行先のテスト環境では致命的エラーが発生しました。
Audit Trailでは非推奨の通知を確認し、利用状況や保守状況も踏まえて、それぞれテスト環境から削除しました。
削除を進める際は、必要な設定やデータを保存し、ファイルとデータベースをバックアップします。
そのうえで、対象を1つずつ無効化して影響を確認し、削除後も表示や関連機能を確かめてください。
用途や影響が分からない場合は、先に使用箇所を調べ、必要に応じて管理担当者へ確認しましょう。
目指すのは、プラグインの数を減らすことではなく、必要な機能を保ちながら、管理を続けられる状態に整えることです。
