2026年9月23日

WordPressのインデックス状況を定期監視してSEOリスクを早期発見する方法

SEO・パフォーマンス

インデックスの問題は、気づくまでに時間がかかるほど影響が大きくなります。対策の中心は、「Search Console のページのインデックス登録レポートを決まった頻度で見ること」と、「WordPress側でインデックスを止めてしまう設定変更を自動でチェックすること」の2本立てです。この記事では、週ごとに見るべき項目、WordPressで起きやすい原因とその確認方法、サーバーのcronで動かす簡単な監視スクリプトの例を説明します。

なぜ定期監視が必要か

WordPressサイトでは、本人が意図しないうちにインデックスを妨げる変更が入ることがあります。代表的なのは次のような場面です。

ステージングから本番へ移行したとき、「検索エンジンがサイトをインデックスしないようにする」の設定が残っていた
SEOプラグインの更新や設定の見直しで、カテゴリーや投稿タイプがまとめて noindex になった
セキュリティ系の設定やCDNのルールで、Googlebot へのレスポンスがエラーになっていた
テーマ変更でcanonicalの出力が変わり、記事が別のURLの重複として扱われた

どれもサイトを普通に閲覧しているだけでは気づきにくく、検索流入が落ちてから原因を探すことになりがちです。

ステップ1：Search Console で週に1回確認する項目

Search Console の「ページのインデックス登録」レポート（画面の表記は変わることがあります。2026年10月現在）では、登録済みのページ数と、登録されていないページの理由別の件数が表示されます。週に1回、次の点を確認します。

登録済みページ数が急に減っていないか
「noindex タグによって除外されました」が増えていないか。増えていれば、意図した除外か設定ミスかを確かめる
「robots.txt によりブロックされました」に、公開したいページが含まれていないか
「サーバーエラー（5xx）」やリダイレクト関連のエラーが出ていないか
「クロール済み - インデックス未登録」「検出 - インデックス未登録」が急に増えていないか

最後の2つは、内容が薄い、似たページが多い、サイト全体のクロールが追いついていないなど、原因が複数考えられます。件数がゆっくり推移しているだけなら様子を見て、急増したときに対象URLを調べるのが現実的です。

気になるURLは「URL検査」で個別に調べます。Googleが選んだcanonical、最終クロール日、ページの取得可否、検出された noindex の有無などが分かります。「公開URLをテスト」を使うと、現在のページの状態も確認できます。

また、Search Console に登録しているアカウントのメール通知を有効にしておくと、新しい種類の問題が検出されたときに知らせてもらえます。ただし通知は検出から少し遅れて届くことがあり、通知だけに頼るのは避けます。

ステップ2：WordPress側の設定を点検する

インデックスの問題が見つかったときに、WordPress側で確認する順番です。上から順に、起きやすく確認しやすいものを並べています。

1. 検索エンジンでの表示の設定

管理画面の「設定」→「表示設定」にある「検索エンジンでの表示」にチェックが入っていると、WordPressはページに noindex を出力します。WP-CLIでは次のように確認できます。

# 1 なら通常、0 なら「インデックスしないように」の状態
wp option get blog_public

2. SEOプラグインの noindex 設定

投稿タイプ・カテゴリー・タグ・著者アーカイブなどの単位で noindex を設定できるプラグインが多くあります。記事ごとの詳細設定で noindex になっていることもあるため、レポートで除外されたURLの種類を見て、該当する設定を確認します。

3. robots.txt

WordPressは実ファイルがない場合に仮想の robots.txt を出力しますが、SEOプラグインやサーバーに置いた実ファイルで上書きされていることもあります。Disallow: / だけが書かれていると、サイト全体のクロールが止まります。

4. HTTPヘッダーの X-Robots-Tag

サーバー設定やセキュリティプラグインで X-Robots-Tag: noindex が付いていると、HTMLを見ても気づきません。ヘッダーの確認が必要です。

5. canonical とリダイレクト

テーマやプラグインの変更で canonical の向き先が変わっていないか、http と https、www の有無で余計なリダイレクトが発生していないかを確認します。

ステップ3：変更を自動で検知するスクリプト

Search Console のデータは反映に数日かかるため、WordPress側の設定ミスはサイト側で先に気づけるようにしておくと安心です。次のスクリプトは、トップページと主要記事について、HTTPステータス、X-Robots-Tag、meta robots、robots.txt の全体ブロック、blog_public の値を確認し、問題があれば終了コード1で終わります。

#!/bin/bash
# index-watch.sh : インデックスを妨げる設定の簡易チェック
SITE="https://example.com"
WP_PATH="/var/www/html"
URLS=("$SITE/" "$SITE/sample-post/")
NG=0

for u in "${URLS[@]}"; do
  code=$(curl -s -o /dev/null -w '%{http_code}' -A 'Mozilla/5.0 (index-watch)' "$u")
  [ "$code" != "200" ] && echo "NG status $code : $u" && NG=1

  if curl -sI "$u" | grep -i '^x-robots-tag:' | grep -qi 'noindex'; then
    echo "NG X-Robots-Tag noindex : $u"; NG=1
  fi

  if curl -s "$u" | grep -ioE '<meta[^>]*name=.robots.[^>]*>' | grep -qi 'noindex'; then
    echo "NG meta robots noindex : $u"; NG=1
  fi
done

if curl -s "$SITE/robots.txt" | grep -qiE '^Disallow:[[:space:]]*/[[:space:]]*$'; then
  echo "NG robots.txt に Disallow: / があります"; NG=1
fi

if [ "$(wp option get blog_public --path="$WP_PATH" 2>/dev/null)" = "0" ]; then
  echo "NG blog_public=0（インデックスしない設定）"; NG=1
fi

exit $NG

URLS には、トップページ、アクセスの多い記事、カテゴリーページなど、種類の違うURLを数件入れます。robots.txt のチェックは単純な行の一致なので、特定のボットだけを Disallow: / で拒否している場合にも反応します。その場合は確認したうえで条件を調整してください。cronで毎日実行し、出力をメールやチャットに送るようにしておけば、設定ミスの当日に気づけます。

# crontab -e で毎朝7時に実行し、問題があったときだけ通知する例
0 7 * * * /home/user/bin/index-watch.sh > /tmp/index-watch.log 2>&1 || mail -s "index-watch NG" you@example.com < /tmp/index-watch.log

WAFやセキュリティプラグインによっては、ボットらしいアクセスへの応答が通常の閲覧と異なることがあります。このスクリプトはGooglebotの見え方を再現するものではないため、Googlebotで問題が疑われるときはURL検査の「公開URLをテスト」で確認してください。多数のURLを定期的に調べたい場合は、Search Console の URL Inspection API を使う方法もありますが、1日あたりの利用上限があります。

ステップ4：問題を見つけたときの対処

原因を直したら、URL検査で「インデックス登録をリクエスト」を送るか、サイトマップを再送信します。多数のURLが影響を受けた場合は、修正後に「ページのインデックス登録」レポートの該当する理由から「修正を検証」を実行すると、Googleが再確認を進めます。回復には数日から数週間かかることがあり、その間も設定が戻っていないかを監視スクリプトで見続けます。

設定を戻す作業の前には、SEOプラグインの設定のエクスポートやデータベースのバックアップを取り、何をいつ変えたかを記録しておくと、次に同じ問題が起きたときの調査が速くなります。

まとめ

インデックスの問題は気づきにくいため、Search Console のレポート確認とサイト側の自動チェックを組み合わせる
週に1回、登録済みページ数と noindex・robots.txt・サーバーエラーなどの理由別件数の変化を見る
WordPress側では、検索エンジンでの表示の設定、SEOプラグインの noindex、robots.txt、X-Robots-Tag、canonical の順に確認する
簡単なシェルスクリプトとcronで、設定ミスをその日のうちに検知できる
修正後はインデックス登録のリクエストや修正の検証を行い、回復まで監視を続ける