WordPressのプラグインは、今のサイトに足りない機能を補うものだけ選ぶのが基本です。テーマ・サーバー・導入済みプラグインの担当を確認し、バックアップや問い合わせなど、必要な役割の不足を埋めていきます。
全サイトに共通する必須製品のセットや、適切な個数の上限はありません。まず必要な機能と既存の担当を整理すれば、追加する候補と、そのまま維持するものを分けられます。
必須の製品を探す前に、必要な機能を整理する
「おすすめ」やランキングを読む前に、サイトで実現したいことを決めるのが出発点です。プラグインはWordPress本体の機能を拡張するため、テーマやサーバーで目的を満たせる部分から確認します。
サイトの役割と、今の担当を洗い出す
記事を読むブログ、問い合わせを受ける企業案内、商品を販売するサイトでは、必要な機能もそれぞれ別です。たとえば問い合わせを外部サービスで受け付けているなら、WordPress内に別のフォームを作る必要はありません。
先に「何をしたいか」を書き、その右に担当しているテーマ・サーバー機能・プラグイン名を並べてください。名前だけで分からないものは公式説明と設定画面を照合し、有効になっている機能まで確かめます。
確認したいのは、機能の有無だけでなく目的に足りる範囲を担当しているかです。次の章の表を使い、担当・不足・追加候補を一組にして整理できます。
個数より、不足・重複・実際の動作を見る
「何個から入れすぎか」は、数だけで決められません。同じ個数でも担当する処理や使うページが違うため、機能の重複と実際の動作を調べます。
私が過去に行った切り分け
私は一度、原因不明のトラブルを調べる中で、プラグインが関係しているのではないかと疑いました。インストール済みのものをすべて停止し、一つずつ有効に戻したところ、症状が再発するプラグインを切り分けられた経験があります。
ここで参考にしたいのは、プラグインの役割を把握しておくことの大切さです。本番サイトで全停止すると、プラグインが担うフォームや表示などに影響が出るおそれがあるため、この経験をそのまま共通の操作手順にせず、影響と戻し方を確認してから検証します。
役割ごとに、追加が必要かと候補を判断する
追加を考えるのは、必要な役割を既存の仕組みで満たせないときです。表の候補を一括で入れず、現在の担当と不足する条件を照らし合わせて選んでください。
| 役割 | 既存の担当 | 追加する条件 | 候補例 | 重複・依存の注意 | 確かめること |
|---|---|---|---|---|---|
| 保存・復元 | サーバーの保存、既存のバックアップ | 保存先・期間・復元方法の不足 | UpdraftPlus | 保存対象と保存先の違い | ファイル・DB、取得日時、復元可能性 |
| 問い合わせ | 既存フォーム、外部の受付 | 必要な受付方法・項目の不足 | Contact Form 7 | フォーム表示と送信記録は別の役割 | 送受信、記録保存、迷惑送信対策 |
| SEO情報 | テーマ、既存のSEO機能 | 必要なメタ情報等の管理機能の不足 | Rank Math SEO | ExUnit等との二重出力 | 公開ページのメタ情報・サイトマップ |
| 速度・キャッシュ | サーバーのキャッシュ、画像処理 | 測定した問題に対応する機能の不足 | 環境に適合する機能 | キャッシュ対象と除外設定 | 同じページ・条件での変更前後 |
| 防御 | サーバーのWAF、既存の認証対策 | ログイン保護等の対象の不足 | 不足する対策を担う機能 | WAFと認証・スパム対策の違い | 保護対象、ログ、管理者の復旧方法 |
| 表示・編集補助 | 標準ブロック、テーマの機能 | 必要な表現・編集機能の不足 | Lightning利用時のVK Blocks等 | 使ったブロックやテーマとの関係 | 利用ページと停止時の表示 |
保存・復元と、問い合わせの不足を確認する
バックアップは、保存してあることと、必要な状態へ戻せることを分けて確認します。ファイルとデータベースの対象、保存日時・期間・場所、取り出し方と復元方法が判断材料です。
既存のバックアップで目的を満たしていれば、その仕組みを維持します。一方、同じサーバーとは別の場所にも保存したい、必要な期間を残せないといった不足があれば、UpdraftPlusなどが候補です。
UpdraftPlusは無料版でもGoogle DriveやDropboxなどへの保存に対応し、PremiumではOneDriveなどの保存先や更新前の自動バックアップが加わります。外部ストレージ側の容量・料金も含め、使う保存先と必要な機能を選んでください。
サーバー側にバックアップがある場合も、復元ボタンの名称だけで作業完了と考えないことが大切です。たとえばConoHa WINGでは、リストアで取り出したデータからWebデータやデータベースを復旧する案内が別に用意されています。
WordPress内で問い合わせを受け付けたいときに、既存の方法では必要な項目などを用意できなければ、Contact Form 7が候補です。ただし、Contact Form 7単体には送信内容を保存する機能がありません。
送信記録も必要なら保存の仕組みを別に検討し、テスト送信では送信完了の表示と受信先への到着を両方確認します。保存する情報・期間・閲覧できる担当者も、運用前に決めておく項目です。
スパム対策などの連携を使う場合は、送信者の情報がどの外部サービスへ渡るかも確認してください。フォーム本体と連携先の条件を合わせて見ると、受け付けた情報の扱いまで整理できます。
SEO・速度・防御・表示の担当を重ねない
SEOプラグインを選ぶ基準は、タイトル・説明文・サイトマップなど、必要な情報を今の構成で管理できるかです。既存機能で足りれば維持し、不足があればRank Math SEOなどの対応機能を比較します。
LightningでExUnitを使っている場合は、別のSEOプラグインを追加する前に担当を分けてください。ExUnitにもメタディスクリプション等の出力機能があり、同じ情報を二重に出す原因になります。
「SEOはRank Mathにまとめ、ExUnitの重なる機能を使わない」といった分担を決め、公開ページの出力まで照合するのが基本です。解析タグも、Site Kitなどですでに設定しているなら、同じIDを別の機能へ重ねて登録しません。
速度対策では、遅いページと計測条件をそろえ、画像やサーバー側の機能から不足を見つけます。ページキャッシュを追加する場合は、ログイン後やカートなど利用者ごとに内容が変わるページを、同じ扱いにしないことが重要です。
防御では、Webアプリへの攻撃を検知・遮断するWAFと、ログイン時の二要素認証や試行回数の制限を別々に確認します。「WAFがあるから防御は全部済んでいる」とは判断できません。
まず更新・強いパスワード・必要な権限を整え、足りない保護対象に合う対策を選んでください。表示補助も同様に、標準ブロックやテーマで作れない表現があるときだけ、対応する拡張を検討します。
候補の環境・更新・無料と有料の範囲を比較する
必要な役割が決まったら、次に見るのは候補を自分の環境で維持できるかどうかです。機能の多さよりも、必要な機能を使え、更新や不具合時の対応まで続けられるかで判断します。
公式配布元と、対応版・依存関係を見る
WordPress.orgの配布ページや開発元の公式サイトで、製品名と作者を照合してください。対応するWordPress・PHPの条件、最終更新、変更履歴、必要なテーマや別プラグインも確認します。
「このWordPress版では未テスト」という表示は、配布情報にその版までの動作確認が示されていないという意味です。確定した非互換と同じ扱いにせず、公式の対応案内やサポート情報を調べます。
要件は更新で変わるため、以前使えたことだけでは判断できません。たとえば2026年10月15日確認時点のContact Form 7 6.2.2は、WordPress 7.1以上・PHP 8.3以上が動作条件です。
候補に合わせて本番のPHPをすぐ変えるのではなく、テーマや他のプラグインも含めた互換性と復旧方法を確認してから進めてください。環境を保ったまま必要な役割を満たせる候補も、比較の対象になります。
必要機能・継続費用・サポートを比べる
無料で必要な機能が足りるなら、無料版を維持する選択で十分です。有料版は、不足する保存先や運用機能、必要なサポートがあるときに比較します。
購入前は初回料金に加え、更新料金、対象サイト数、更新・サポートを受けられる期間、契約終了後の扱いを確認してください。有料機能を使うために無料版も必要な製品なら、両方の依存関係を残して管理します。
無料版の機能変更や有料化が分かった場合も、必要な機能と継続条件を見直すのが判断の順序です。継続・代替のどちらを選ぶ場合も、保存データを移せるかと移行後の動作まで確かめます。
不要に見えるプラグインを、整理する前に確認する
名前に覚えがないものや機能が似ているものは、削除対象ではなく確認対象です。使っている場所と依存関係を調べれば、必要な機能を残したまま整理できます。
ブロック・フォーム・データ・代替機能を確認する
管理画面で操作していなくても、過去の記事のブロックやフォーム、別の拡張が、そのプラグインを必要とする場合があるためです。停止前に、次の項目を確認してください。
- 記事・固定ページ内の専用ブロック、ショートコード、フォーム
- テーマや有料拡張など、対象のプラグインを必要とする機能
- 設定、送信記録、バックアップなどの保存場所と書き出し方法
- 代替機能の設定内容と、引き継いだ後の出力・動作
- 停止前のバックアップ、戻し方、確認するページと作業担当
たとえばSEO製品同士でメタ情報が重なっていても、片方の専用ブロックや別の機能を使っていれば、その製品全体をすぐ止める判断にはなりません。まず機能単位で担当を整理し、停止できる条件を確かめます。
停止と削除を分けて、検証する
無効化はプラグインの動作を止める操作で、削除はそのファイルを取り除く操作です。削除時には設定や独自のデータも消す仕組みを実装できるため、再インストールだけで元どおりと考えず、製品ごとの扱いを確認します。
停止を検証する候補が決まったら、可能なら本番に近い検証環境で、対象を一つずつ変えて前後を比べてください。本番で行う必要がある場合は、機能が止まる影響・作業時間・バックアップと復旧担当を先に決めます。
停止後の確認は、トップページが開くかだけでは不十分です。対象を使っていたページ、編集・保存、フォームの送受信、SEO情報など、そのプラグインが担当していた機能を点検します。
停止により必要な機能に不具合が出たら、削除へ進まず、事前に決めた戻し方で復旧して動作を確かめてください。問題が見つからず、依存関係・残すデータ・代替機能の確認も済んだものは、製品の公式案内に沿って削除できるかを判断します。
追加・維持・停止検証のいずれかを選ぶ
棚卸しの結果として選ぶのは、追加・維持・停止検証の三つです。まだ役割を説明できないものは、停止を急がず担当や公式資料を確認します。
不足がなければ追加せず、機能の担当を決める
| 判断 | 当てはまる状態 | 次に確かめること |
|---|---|---|
| 追加 | 必要な機能がなく、候補が環境・運用条件に適合 | 導入前の保存、有効化後の設定と機能確認 |
| 維持 | 既存の仕組みで必要な範囲を満たしている | 更新、保存、目的の機能の定期確認 |
| 停止検証 | 役割が不要、または代替済みで、依存・データの扱いを確認済み | 個別停止の影響、戻し方、検証後の削除可否 |
必要なプラグインは残し、重なる部分は機能ごとに担当を決めるのが基本です。別の保存先へ備えるバックアップのように、役割の違いを説明できるものは、名前が似ていても単純な重複とは分けて考えます。
決まった作業に進み、変更後の確認を続ける
追加する候補が決まったら、公式案内に沿う導入・有効化・設定へ進んでください。Rank Mathを選んだ場合はSEO出力、バックアップを選んだ場合は保存対象と復元可能性を、それぞれ確認します。
Lightningの表示拡張は実際に作るページに合わせて選び、停止候補は影響の検証へ進める段階です。選んだ製品名・担当機能・利用ページを記録しておくと、更新時や不具合時にも確認先をたどれます。
「必須だから入れる」で終わらず、必要な機能を動く状態まで整え、その後の更新・保存・主要機能の点検を担当者へ結び付けてください。目的と担当が明確なら、次に追加や整理を考えるときも、同じ基準で判断できます。