2026年5月29日

WordPressのSEOに悪影響なプラグインを特定して安全に削除する手順

SEO・パフォーマンス

プラグインがSEOに悪影響を与える経路は、主に「表示速度の低下」「検索エンジン向けタグの重複・誤設定」「質の低いページの自動生成」「改ざんやスパムリンクの入口」の4つです。この記事では、どのプラグインがどの経路で問題を起こしているかを切り分ける方法と、データや設定を失わずに停止・削除する手順を説明します。作業はバックアップを取ったうえで、できればステージング環境で行ってください。

プラグインがSEOに悪影響を与える4つの経路

「プラグインが多いとSEOに悪い」とよく言われますが、数そのものが評価を下げるわけではありません。問題になるのは、次のような具体的な影響を持つプラグインです。

表示速度とCore Web Vitalsの悪化：全ページで大きなCSS・JavaScriptを読み込む、外部サービスへの通信が多い、重いデータベース問い合わせを毎回実行する、といったもの。ページエクスペリエンスは検索の評価要素の一つですが、速度だけで順位が決まるわけではない点も押さえておきます。
meta・canonical・構造化データの重複や誤り：SEOプラグインを2つ有効にしている、テーマとプラグインの両方がOGPや構造化データを出している、といった状態です。canonical が2本出たり、意図しない noindex が付いたりします。
薄いページの大量生成：添付ファイルページ、タグアーカイブ、絞り込み用のパラメータ付きURLなどを大量に作り、クロールの無駄や重複を生むもの。
セキュリティ上の入口：更新が止まった・脆弱性が放置されたプラグインや、正規の配布元以外から入手したプラグインは、スパムページやリンクを埋め込まれる原因になります。改ざんされると検索結果に見知らぬ日本語の商品名が並ぶ、といった深刻な被害につながります。

どの経路の問題かで調べる場所が変わるので、まず症状から当たりを付けます。

手順1：有効なプラグインの棚卸しをする

最初に、有効なプラグインと更新状況を一覧にします。WP-CLI が使える環境なら次のコマンドが手早いです。

# 有効なプラグインと更新の有無を一覧表示
wp plugin list --status=active --fields=name,version,update

# 無効化したまま放置しているプラグインも確認
wp plugin list --status=inactive --fields=name,version

一覧ができたら、各プラグインについて「何のために入れたか」「今も使っているか」「最終更新はいつか」を確認します。WordPress.org の公式ディレクトリのページでは、最終更新日や、テスト済みの WordPress バージョンを確認できます。長期間更新がないもの、ディレクトリから公開停止になっているもの、役割が他のプラグインやテーマと重複しているものが最初の候補です。

無効化されているだけのプラグインも、ファイルはサーバーに残っています。脆弱性のあるファイルは無効化中でも直接アクセスされる可能性があるため、使わないものは削除まで進めるのが基本です。

手順2：タグの重複・誤設定をソースで確認する

検索エンジン向けのタグの問題は、ページのHTMLを見れば確かめられます。ブラウザでソースを表示するか、次のように取得して該当行だけを抜き出します。

curl -s https://example.com/sample-post/ | grep -iE '<title|rel="canonical"|name="robots"|name="description"|application/ld\+json'

確認するポイントは次のとおりです。

<title> や rel="canonical" が1つだけか
公開したいページに noindex が付いていないか
構造化データ（JSON-LD）が二重に出ていないか、内容が矛盾していないか

WordPress 5.7 以降は wp_robots フィルターで robots メタタグを組み立てる仕組みがあり、プラグインはここに noindex を追加できます。特定のページだけ noindex が付く場合は、そのページ種別に設定項目を持つプラグイン（SEOプラグイン、会員制プラグイン、フォームプラグインなど）を疑います。

あわせて Google Search Console の「ページのインデックス登録」レポートで、「noindex タグによって除外されました」や「代替ページ（適切な canonical タグあり）」に、本来インデックスさせたいURLが入っていないかを見てください。URL検査ツールでは、Google が選んだ canonical も確認できます。

手順3：速度に影響しているプラグインを特定する

速度の問題は、計測ツールでプラグインのファイルを特定するのが近道です。

PageSpeed Insights や Chrome DevTools の Lighthouse で対象ページを計測し、「使用していない JavaScript の削減」などの指摘に出てくるファイルのURLを見ます。/wp-content/plugins/プラグイン名/ というパスから、どのプラグインのファイルかが分かります。
DevTools のネットワークタブで plugins/ と入力して絞り込むと、そのページで読み込まれているプラグインのファイルと容量が一覧できます。
サーバー側の処理が遅い場合は、Query Monitor プラグインが役立ちます。データベースの問い合わせ、読み込まれたスクリプトやスタイル、HTTP API の外部通信を、どのプラグイン（コンポーネント）が発生させたかで集計して表示します。

計測値は回線や時間帯でぶれるため、1回の結果で判断せず、同じ条件で複数回測ってください。Search Console の「ウェブに関する主な指標」レポートは実際のユーザーのデータ（フィールドデータ）に基づくので、ラボ計測との違いも意識して見ます。

手順4：疑わしいプラグインを一時的に止めて切り分ける

候補が絞れたら、実際に止めて変化を確かめます。本番でいきなり無効化すると、フォームや決済が止まるなどの影響が出るため、次のどちらかの方法を使います。

ステージング環境で無効化する：本番の複製で1つずつ、または半分ずつ無効化して、タグの重複や速度が改善するかを確認します。候補が多いときは半分ずつ止める二分探索にすると早く絞り込めます。
Health Check & Troubleshooting プラグインのトラブルシューティングモード：自分のログインセッションだけでプラグインを無効化した状態を再現でき、訪問者の表示には影響しません。ただしログイン中の表示が前提になるため、キャッシュ経由の表示や外部ツールでの計測にはステージングの方が向いています。

無効化して問題が解消したら、そのプラグインが原因です。代わりの手段（設定変更、別の軽いプラグイン、テーマの機能）で目的を満たせるかを検討します。全ページではなく特定ページでだけ必要なプラグインなら、削除ではなく読み込み範囲を絞る対応も選べます。

<?php
// 子テーマの functions.php か mu-plugin に記述
// お問い合わせページ以外ではフォームプラグインのスタイルとスクリプトを読み込まない例
add_action( 'wp_enqueue_scripts', function () {
	if ( is_page( 'contact' ) ) {
		return;
	}
	// ハンドル名はプラグインごとに異なる。Query Monitor の「Scripts」「Styles」で確認する
	wp_dequeue_style( 'example-form-style' );
	wp_dequeue_script( 'example-form-script' );
}, 100 );

ハンドル名を推測で書いても効果はありません。Query Monitor などで実際のハンドル名を確認し、該当ページで機能が動くことをテストしてから本番に反映してください。

手順5：データを引き継いでから削除する

削除の前に、そのプラグインが保存しているデータと、サイトのどこで使われているかを確認します。ここを飛ばすと、削除後にSEO上の問題が新たに発生します。

リダイレクト設定：リダイレクト用プラグインは、設定を独自のテーブルやオプションに保存しています。削除すると転送が止まり、過去のURLが404になります。設定をエクスポートし、移行先（別のプラグインやサーバー設定）で同じ転送が動くことを確認してから削除します。

SEOプラグインの乗り換え：タイトルやメタディスクリプション、noindex の個別設定は、プラグインごとの投稿メタに保存されています。主要なSEOプラグインには他のSEOプラグインからの設定取り込み機能がありますが、対応範囲はバージョンによって異なります（2026年10月現在）。取り込み後、代表的なページのタグを手順2の方法で確認してから旧プラグインを削除してください。2つのSEOプラグインを並行して有効にしておく期間は短くします。

ショートコード：本文にショートコードを使っていた場合、削除後は [example_shortcode] のような文字列がそのまま表示されます。事前に使用箇所を検索しておきます（テーブル接頭辞は環境に合わせて変更）。

wp db query "SELECT ID, post_title FROM wp_posts WHERE post_status = 'publish' AND post_content LIKE '%[example_shortcode%'"

確認が済んだら、無効化してから削除します。

wp plugin deactivate example-plugin
# 数日様子を見て問題がなければ削除
wp plugin delete example-plugin

管理画面から削除すると、プラグインによってはアンインストール処理で自身のデータベースのデータも消します。FTPでフォルダだけを消した場合は逆にデータが残ります。どちらの挙動になるかはプラグイン次第なので、削除前のバックアップから戻せる状態にしておくことが大切です。不要なオプションの確認には wp option list --search="example_*" が使えますが、他のプラグインのデータと名前が似ていることもあるため、DBから手作業で消すのは慎重に行ってください。

削除後に確認すること

削除が終わったら、次の点を確認します。

XMLサイトマップが表示され、Search Console で送信済みのサイトマップが読み込めているか（サイトマップを生成していたプラグインを外した場合は、WordPress 本体の /wp-sitemap.xml などの代替を用意する）
robots.txt の内容が意図どおりか
代表的なページの title・canonical・robots・構造化データ（手順2のコマンドで再確認）
過去のURLへのリダイレクトが動いているか
添付ファイルページの扱い。WordPress 6.4 以降の新規インストールでは添付ファイルページが既定で無効になっていますが、それ以前からのサイトでは設定やプラグインに依存しているため、意図せずインデックス対象になっていないかを見ます

Search Console のインデックス登録レポートは反映に時間がかかります。数週間は推移を見守り、除外されたURLが急に増えていないかを確認してください。プラグインを削除しても順位が上がる保証はありません。目的はあくまで、検索エンジンと読者にとって正しい状態に戻すことです。

まとめ

SEOへの悪影響は「速度」「タグの重複・誤設定」「薄いページの生成」「セキュリティ」の4経路で考えると切り分けやすい
棚卸しで不要・放置・重複のプラグインを洗い出し、HTMLのタグ、計測ツール、Query Monitor で原因を特定する
切り分けはステージングか、自分のセッションだけに効くトラブルシューティングモードで行う
削除前にリダイレクト、SEO設定、ショートコードの使用箇所を引き継ぎ・確認し、バックアップを取る
削除後はサイトマップ、robots.txt、canonical、リダイレクトを再確認し、Search Console で数週間推移を見る