検索可視性の4層 — なぜ1か所直しても直らないのか

このファイルは SKILL.md の Step 1 の根拠と、切り分けの順序をまとめたもの。 「検索避けのチェックを外したのに検索に出ない」の原因は、ほぼここに入っている。

前提: 4層は独立している

層1を直すと層2が直ることがあるが、層3と層4は別系統なので連動しない。 だから4回、別々に見る。

一次情報で確認できる仕様

WordPress公式（Settings Reading screen）

検索避け（Discourage search engines from indexing this site）を有効にしたときの挙動:

• 5.3以降: <meta name='robots' content='noindex,nofollow' /> を <head> に出力する。 ただし公式の記述は "(if wp_head is used)" と条件付き。 → wp_head を呼ばない自作テーマ、静的HTML化、フルページキャッシュの下では、 設定と実際の出力が一致しない。設定値ではなく出力を見る理由がこれ。
• 5.2以前: 仮想 robots.txt が User-agent: * / Disallow: / を返した。 公式の注記は "The above only works if WordPress is installed in the site root and no robots.txt exists." → 物理 robots.txt があると、WordPressは robots.txt を制御していない。 制作中に置いた物理ファイルは、管理画面のチェックを外しても消えない。 サブディレクトリ設置の場合も仮想robots.txtは効かない。
• 公式の注記: "Neither of these options blocks access to your site — it is up to search engines to honor your request." → 検索避けはアクセス制限ではない。ステージングの秘匿には Basic認証やIP制限を使う。

出典: https://wordpress.org/documentation/article/settings-reading-screen/

Google公式（Block indexing）

• noindex は metaタグと X-Robots-Tag ヘッダーの2通りで認識される。 ヘッダー版はHTML以外（PDF、画像）にも効く。
• 決定的な注意点: "For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file... If the page is blocked by a robots.txt file or the crawler can't access the page, the crawler will never see the noindex rule, and the page can still appear in search results."

出典: https://developers.google.com/search/docs/crawling-indexing/block-indexing

ここから出る2つの結論

1. robots.txt で Disallow: / したまま noindex を外しても、外したことが伝わらない。 クローラーがページを取得できないので、metaの変更を認識できない。 → robots.txt を先に開ける。次にnoindexを外す。順序が逆だと反映が遅れる。
2. Disallow: / + noindex の併用は、秘匿としても最悪の組み合わせ。 noindexが読まれないため、URLだけが検索結果に残ることがある。 秘匿したいならアクセス制限、消したいならクロール可能な状態でnoindex。

切り分けの順序

上から順に。1つ直したら、キャッシュを消してから次を見る。

U=https://example.com

# ① クロールできるか（ここが閉じていると以降の判定が無意味）
curl -s  "$U/robots.txt"

# ② ヘッダー（サーバー / CDN 由来。WordPressの設定では直らない）
curl -sI "$U/" | grep -i -E 'x-robots-tag|x-cache|cf-cache-status|age:'

# ③ HTMLの出力（設定値ではなく出力）
curl -s  "$U/" | grep -i -o '<meta[^>]*robots[^>]*>'

# ④ WordPressの設定値
wp option get blog_public          # 1 であること

③にnoindexが出ているときの出所の特定

順に消していく。推測で「プラグインだと思います」と言わない。

1. wp option get blog_public が 0 → 本体。管理画面のチェックを外す。
2. SEOプラグインの設定。4か所を別々に見る。
   • サイト全体の設定
   • 投稿タイプ別（post / page / カスタム投稿）
   • タクソノミー別（カテゴリー、タグ、著者、日付アーカイブ）
   • 個別ページのメタボックス（そのページだけnoindexが一番見つけにくい）
3. テーマの functions.php / header.php に直書き → grep -rn "noindex" wp-content/themes/<active-theme>/
4. プラグイン全体 → grep -rn "noindex" wp-content/plugins/ | grep -v -E '\.min\.|/vendor/'
5. どれでもない → キャッシュが古い。キャッシュとCDNを消してから再確認。

②にnoindexが出ているときの出所

WordPressの中を探しても見つからない。外を見る。

• .htaccess の Header set X-Robots-Tag "noindex"（制作中に足したものが残る）
• Nginx の add_header
• CDN / WAF のレスポンスヘッダー書き換えルール
• ホスティング事業者の「ステージング環境」機能が自動で付けている → ステージング機能で作った環境をそのまま本番にすると、これが付いてくる。

④が1なのに③にnoindexが出る典型

• フルページキャッシュが、検索避けON時のHTMLを保持している
• CDNのエッジキャッシュ（age: が大きい）
• サーバー側の静的HTML化プラグイン

この場合、設定は正しい。キャッシュを消すのが修正。 設定をいじり続けると、正しい設定を壊す。

公開後の確認

• site:example.com で検索して0件でも、公開直後は正常。インデックスには時間がかかる。 「出ない」と「出るはずがない状態になっている」を混同しない。判定に使うのは4層の値。
• Search Console のURL検査で「クロール済み - インデックス未登録」「noindex タグにより除外されました」 が出るかを確認する。登録と申請は利用者が行う。
• robots.txt を開けた場合、反映はGoogle側の再クロール待ち。即時ではない。

この4層で拾えないもの

• canonical が別ホストを指している（SKILL.md Step 3）
• hreflang の相互参照ミス
• パスワード保護された個別ページ
• 認証やCookieでコンテンツが変わる構成
• JavaScript描画に依存し、クローラーが本文を取得できない構成

これらは別の理由で検索に出ないので、4層がすべて正常でも解決しない。 4層は「検索に出ない原因のうち、最も多く、最も安く潰せるもの」であって、全部ではない。