WordPressの「検索エンジンでの表示」設定で何が変わるか

WordPress の「検索エンジンがサイトをインデックスしないようにする」チェックボックスをオンにすると、サイトのすべての公開ページに noindex, nofollow を指定した robots meta タグが付きます。Google はこのタグに従います。タグ付きで再クロールされたページは順に検索結果から外れ、新しいページは追加されません。非公開のステージング環境であれば、それが意図どおりの結果です。しかし Google に載せたい本番サイトであれば、今すぐオフにしてください。訪問者からは何も変わって見えないまま、再クロールのたびにサイト全体が Google から消えていきます。

現在の WordPress でこの設定が出力するもの

このチェックボックスは「設定」→「表示設定」の「検索エンジンでの表示」の行にあり、WordPress のインストーラーのセットアップ画面にも同じチェックボックスがあります。データベースに保存されるのは blog_public オプションという1つの値だけで、チェックを入れると 0、外すと 1 になります。この値によって何が変わるかを、2026年10月時点（最新リリースは 7.1.3）の WordPress コアのソースコードで確認しました。

• すべてのフロントエンドページに robots meta タグが付きます。 テーマの標準の head 出力に次の行が含まれます。

<meta name='robots' content='noindex, nofollow' />

• 組み込みの XML サイトマップが無効になります。 /wp-sitemap.xml のコアサイトマップは 404 を返し、WordPress が生成する robots.txt から Sitemap: の行が消えます。
• robots.txt で新たにブロックされるものはありません。 生成されるファイルには、通常どおり管理画面に対する Disallow と admin-ajax.php に対する Allow が残ります。
• HTTP ヘッダーは追加されません。 コアはこの設定で X-Robots-Tag ヘッダーを送信しないため、シグナルは HTML の中にしかありません。
• サイトは公開されたままです。 チェックボックスの下には「このリクエストを尊重するかどうかは検索エンジンの設定によります。」と書かれています。訪問者や、robots meta タグを無視するクローラーは、引き続きすべてのページを読めます。
• 管理者向けの通知は1か所だけです。 チェックが入っている間、ダッシュボードの「概要」ウィジェットに「検索エンジンでの表示を無効にしています」という行が表示されます。

ダッシュボードがスペイン語の場合、表記はロケールによって異なります。2026年10月に WordPress 翻訳プロジェクトを確認したところ、メキシコ、アルゼンチン、コロンビアなど中南米の複数のロケールではラベルが「Disuade a los motores de búsqueda de indexar este sitio」、スペインで使われるスペイン語では「Pedir a los motores de búsqueda que no indexen este sitio」となっていました。ほとんどのスペイン語ロケールでは、この行は「Ajustes de lectura」画面の「Visibilidad en los motores de búsqueda」という名前で、どのロケールでもダッシュボードの行は「Motores de búsqueda disuadidos」と表示されます。

WordPress のバージョンによる動作の変化

古いバージョン向けに書かれた解説が今も出回っており、そこでは別の仕組みが説明されています。コアのソースコードからは、3つの段階があることがわかります。

最も重要なのは 5.3 での変更です。それ以前は、生成された robots.txt がすべてのクローラーにサイト全体へのアクセスを禁じていたため、Google はページを取得できず、noindex タグを一度も目にしませんでした。ほかのサイトからリンクされている URL は、クロールされないまま Google のインデックスに残ることがあり、Search Console ではこれが「robots.txt によりブロックされましたが、インデックスに登録しました」として報告されます。この矛盾についてはこのステータスの解説ページで説明しています。5.3 以降、このチェックボックスは robots.txt には手を加えず、meta タグだけに頼っています。現在のサイトで Disallow: / が見つかった場合、それは実ファイルの robots.txt、プラグイン、またはホスティング会社によるもので、このチェックボックスが原因になることはありません。

本番サイトでこの設定がオンになってしまう理由

よくあるのは、正しく非公開にしていたステージングサイトのデータベースを、公開時にそのままコピーするパターンです。移行プラグイン、ホスティング会社の「本番環境へ反映」機能、手作業によるエクスポートとインポートは、いずれもオプションテーブルを移動させるため、blog_public も一緒に移ります。目に見える変化は、どの訪問者も読まないページの head 内の1行だけです。

sequenceDiagram
    participant S as ステージングサイト
    participant P as 本番サイト
    participant G as Googlebot
    S->>S: チェックあり、blog_public は 0
    S->>P: 公開時にデータベースをコピー
    P->>P: blog_public は 0 のまま
    G->>P: ホームページと投稿を再クロール
    P-->>G: noindex, nofollow 付きの HTML
    G->>G: 再クロールしたページを順に検索結果から削除

2026年5月から10月にかけてSEOReportが監査した外部ウェブサイト45サイトのうち、HTML または X-Robots-Tag ヘッダーで noindex を指定したホームページを返していたサイトはありませんでした。この規模のサンプルでは、このミスがどの程度よくあるかまでは言えず、日常的に起きるものではないとしか言えません。ただし、起きた場合はすべての公開ページに一斉に影響するため、公開時のチェックリストには必ず入れておくべき項目です。

ダッシュボードの外から設定を確認する方法

重要なのは、ページキャッシュや CDN を経由したあとに、ログインしていない訪問者が受け取る HTML です。Google が取得するのはそれだからです。example.com をご自身のドメインに置き換え、最初の2つのコマンドはホームページだけでなく2〜3件の投稿でも実行してください。-L オプションはリダイレクトをたどるため、www なしのドメインから www へ、あるいは HTTPS への転送があっても最終的なページを確認できます。

# 1. The robots meta tag in the served HTML
curl -sL https://example.com/ | grep -io "<meta[^>]*name=.robots[^>]*>"

# 2. Any noindex sent as an HTTP header instead
curl -sL -o /dev/null -D - https://example.com/ | grep -i "x-robots-tag"

# 3. What robots.txt actually serves
curl -sL https://example.com/robots.txt

# 4. Whether the core sitemap is switched off
curl -sL -o /dev/null -w "%{http_code}\n" https://example.com/wp-sitemap.xml

1つ目の結果に noindex があり、4つ目が 404 を返すなら、この設定が原因と考えられます。SEO プラグインはコアのサイトマップを独自のものに置き換えることがあるため、404 だけでは何も証明できません。2つ目の結果に noindex がある場合、それはサーバー、ホスティング会社、CDN、またはプラグインによるヘッダーのルールで、チェックボックスでは消せません。

WordPress の管理画面からなら、ダッシュボードの「検索エンジンでの表示を無効にしています」という行を見るのが最も手早い確認方法です。コマンドラインが使える場合は、wp option get blog_public を実行すると、チェックが入っていれば 0、外れていれば 1 が表示されます。

flowchart TD
    A["公開中の HTML に robots meta の noindex があるか"] -->|"ある"| B["blog_public は 0 か"]
    A -->|"ない"| C["X-Robots-Tag ヘッダーに noindex があるか"]
    C -->|"ある"| D["サーバー、ホスティング、CDN のルールを削除"]
    C -->|"ない"| E["公開中のページはインデックス可能：再クロールをリクエスト"]
    B -->|"はい"| F["チェックを外し、キャッシュを削除"]
    B -->|"いいえ"| G["プラグインかテーマが noindex を追加：その設定を確認"]
    F --> H["ホームページと投稿の公開中の HTML に問題はないか"]
    G --> H
    H -->|"ある"| I["キャッシュが古い HTML を返している：キャッシュを削除"]
    I --> H
    H -->|"ない"| J["URL 検査でライブテスト、その後「修正を検証」"]

Search Console での表れ方

Google がページを再クロールしてタグを見つけるたびに、そのページはページ インデックス登録レポートの「未登録」側に移り、理由として「URL に noindex が指定されています」が表示されます。2026年10月に確認した Google のページ インデックス登録レポートのドキュメントには、Google がインデックスに登録しようとした際に noindex の指定が見つかったため、そのページは登録されなかったと説明されています。Google はページごとに異なるタイミングで再クロールするため、この移行は徐々に進みます。このステータスのほかの原因や、意図どおりであるケースについては、「URL に noindex が指定されています」の解説をご覧ください。

URL 検査では両方の状態を確認できます。デフォルトの表示は Google が最後にインデックスに登録したバージョンについてのもので、「インデックス登録を許可？」の項目に、そのバージョンがインデックス登録を禁止していたかどうかが表示されます。「公開 URL をテスト」は現時点のページを取得します。修正後はライブテストの結果を信頼してください。インデックス登録済みのバージョンの表示は、Google が再クロールするまで変わりません。

1日目からチェックを入れたまま公開したサイトでは、レポートに表示される URL 自体がごくわずかなことがあります。コアのサイトマップが無効になっているうえ、nofollow によって各ページのリンクをたどらないよう Google に求めているため、Google がページを発見する手がかりがほとんどないからです。

状況を変えるプラグインとサーバーのルール

SEO プラグインは robots タグを独自に管理します。2026年10月に、広く使われている2つのプラグイン、Yoast SEO と Rank Math のソースコードを確認しました。どちらもチェックボックスがオンの間は noindex を強制し、管理画面に警告を表示します。どちらのプラグインを使っていても、対処法はチェックボックスを外すことです。

一方で、同じプラグインが、個別の投稿、投稿タイプ、アーカイブに対する独自の設定によって、チェックボックスを外したあとも noindex を残すことがあります。ほかのプラグインやテーマも、同じ WordPress の robots フィルターを通じて指定を追加できます。たとえば、公開後も有効のまま残った「近日公開」やメンテナンスモードのプラグインです。blog_public が 1 なのに公開中の HTML に noindex が残っている場合は、こうした設定を確認してください。

ステージング環境から持ち込まれる残骸がほかにも2つあります。Disallow: / を含む実ファイルの robots.txt は、WordPress が生成するものより優先されます。公開後は実際に配信されているファイルを改めて確認してください。サイトを非公開にしている間にプラグインで robots.txt のルールを保存していた場合は特に注意が必要です。また、X-Robots-Tag: noindex を追加するヘッダーのルールは meta タグと同じように機能しますが、ページのソースには現れません。外部からの確認で両方を読むのはそのためです。ファイルを1行ずつ読み解く方法は、robots.txt とクロールアクセスのガイドで説明しています。

復旧の手順と所要期間

1. チェックボックスを外して保存します。 または wp option update blog_public 1 を実行します。
2. すべてのキャッシュを削除します。 ページキャッシュのプラグイン、ホスティング会社のキャッシュ、CDN です。キャッシュされたページは、有効期限が切れるまで古い head を返し続けます。
3. 外部からの確認をやり直します。 ホームページと数件の投稿で確認し、/wp-sitemap.xml またはプラグインのサイトマップが 200 を返すようになったことも確かめます。
4. Search Console の「サイトマップ」レポートでサイトマップを送信します。 これで Google は再クロールすべき URL の完全な一覧を得られます。問題のないサイトマップに含めるべき内容は、XML サイトマップのガイドで説明しています。
5. URL 検査でライブテストを実行します。 ホームページと特に重要なページで実行し、その数ページについて「インデックス登録をリクエスト」を使います。このツールには URL ごとのリクエスト数の上限があり、Google のドキュメントによると、同じ URL を繰り返しリクエストしてもクロールは早まりません。
6. ページ インデックス登録レポートで「URL に noindex が指定されています」を開き、「修正を検証」を選択します。

あとは待つだけです。2026年10月に確認した Google の再クロールに関するドキュメントによると、クロールには数日から数週間かかることがあり、noindex に関するドキュメントには、ページによっては再訪問まで数か月かかることがあると記されています。ページ インデックス登録レポートのドキュメントによると、検証には通常最大で2週間ほどかかり、場合によってはそれよりはるかに長くかかります。インデックスに登録するかどうかは、最終的には Google の判断です。URL 検査のドキュメントにも、リクエストしてもページがインデックスに登録されるとは限らないと明記されています。

次の公開で同じことを起こさないために

ステージング環境は、チェックボックスに頼らず、サーバーやホスティング会社の HTTP 認証によるパスワードで保護してください。ログインが必要なら、すべての訪問者とクローラーを止められます。パスワードで保護したステージング環境ではチェックボックスを外したままにします。Google はログインが必要なページを読めないので、チェックを入れても意味がなく、本番環境にデータベースをコピーしても noindex が持ち込まれません。そのうえで、公開時のチェックリストに1行追加します。本番公開後、そしてデータベースの移行や復元を行うたびに、本番ドメインで外部からの確認を実行する、という項目です。

SEOReportの完全な診断では、ホームページの robots meta タグと X-Robots-Tag ヘッダー、そしてサイトマップに記載された各ページの robots meta タグを読み取り、検索エンジンにインデックス登録しないよう指示しているページを1つずつ挙げます。この設定で必ず発生するホームページの noindex は重大な検出事項として報告されるため、設定によってサイトマップが無効になっていても見逃しません。所有者やホスティングが頻繁に変わるサイトでは、REST API で週次モニタリングを設定すれば、サイトが定期的に再監査され、新たな重大な検出事項が見つかったときにメールで通知されます。サイトが自らページを隠してしまう、より広いパターンについては、インデックス可能性の矛盾に関するデータとページのインデックス可能性のガイドで取り上げています。

よくある質問

この設定で AI クローラーはブロックされますか？

いいえ。robots.txt のルールは追加されず、AI クローラーのアクセスは通常 robots.txt で制御するものです。ただし、Google 自身の AI 機能には影響します。2026年10月に確認した Google の AI 機能に関するドキュメントによると、AI による概要や AI モードで参照リンクとして表示されるには、ページがインデックスに登録されている必要があります。そのため、noindex が付いたページはそこからも外れます。このチェックボックスは AI に関するポリシーではなく、検索インデックスへの登録に関するリクエストとして扱ってください。AI クローラーへの方針を意図的に決める方法は、robots.txt で AI クローラーを扱うための判断表で解説しています。

何週間も前にチェックを外したのに、まだ「URL に noindex が指定されています」と表示されるのはなぜですか？

Search Console には、Google が各ページを最後にクロールしたときの状態が表示されます。まず「公開 URL をテスト」を実行してください。ライブテストでまだ noindex が見つかる場合は、キャッシュ、プラグイン、またはヘッダーのルールがそれを返しています。ライブテストで問題がなければ、そのページは再クロールを待っている状態なので、「修正を検証」とサイトマップの送信が次の適切な手順です。

本番サイトのリニューアル中にチェックを入れても大丈夫ですか？

いいえ。この設定は本番サイトに適用され、リニューアル中に Google が再クロールしたページはすべて検索結果から外れます。リニューアルは、パスワードで保護したステージング環境で進めてください。