まずやること（最短ルート）
- URL検査で「インデックス登録を許可しますか？」の項目を確認
- ページソースで meta robots を確認（noindex, nofollow）
- robots.txt と X-Robots-Tag（ヘッダー）も確認
- 修正後、代表URLから優先的に再クロール依頼
背景・判断のポイント
ブロック系は原因が明確なぶん、直せば改善が早い領域です。ただし「どこで付与されているか」を間違えると、数百〜数万URLが巻き込まれる事故になります。
noindexはHTMLのmetaだけでなく、CDN/ホスティング/アプリのレスポンスヘッダー（X-Robots-Tag）でも付与できます。片方だけ見て安心しないのがポイントです。
robots.txtはクロール制御であり、インデックス制御とは別概念です。誤ってクロールを止めると、状況確認（URL検査）自体が難しくなることがあります。
症状の例（あるある）
- URL検査で「インデックス登録を許可しますか？」が「いいえ」になっている
- ページソースに `noindex` が含まれる、またはHTTPヘッダーに `X-Robots-Tag: noindex` が付いている
- robots.txtに該当パスがDisallowされている（意図せず広く巻き込んでいる）
よくある原因
- ステージング用の noindex が本番に残った
- テンプレ/共通レイアウトで meta robots を誤って付与
- robots.txt のパス指定が広すぎる（/ を巻き込む）
- CDN/ホスティングのヘッダーで X-Robots-Tag が付いている
確認方法
- ページソース: `<meta name="robots" content="...">`
- robots.txt: Disallow の対象パス（前方一致/ワイルドカード含む）
- HTTPヘッダー: `X-Robots-Tag` の有無（curlでも確認可能）
チェックリスト（確認漏れ防止）
- meta robots（`noindex`/`nofollow`）がページ単位かテンプレ単位か
- X-Robots-Tag がアプリ/サーバー/CDNのどこで付与されているか
- robots.txt のDisallowが「想定URLだけ」を対象にしているか（`/` を巻き込んでいないか）
- ステージング判定の条件が正しいか（ホスト名/環境変数/ベーシック認証など）
- 修正後にURL検査で「インデックス登録を許可しますか？」が「はい」になるか
- 重要ディレクトリ（/chapter, /glossary, /playbook など）をスポットチェックできているか
対処
- noindex を外し、robots.txt のDisallowを最小化
- ステージング判定（環境変数/ホスト名）で noindex を自動切替にする
- 対象URL群が多い場合は、テンプレ側で一括修正する
やってはいけない（悪化しやすい手）
- robots.txtで塞いだまま、noindex解除だけをして終える（クロールできず反映が遅れる）
- 応急処置で直した後に、テンプレ/共通設定へ反映せず再発する
- 一部URLだけ直して安心し、同テンプレ配下の他URLが残る
再発防止
- リリース前チェックに「meta robots / robots.txt / canonical」を必ず入れる
- 環境ごとのSEO設定をコードで固定し、人の手運用を減らす
よくある質問（Q&A）
noindexを外したら、どのくらいで戻りますか？
再クロールされて評価が再計算される必要があるため、即日で戻ることもあれば数日〜数週間かかることもあります。重要ページは修正後にURL検査で再クロールをリクエストし、内部リンクも強めて発見を早めましょう。
robots.txtでブロックするのとnoindexの違いは？
robots.txtは「クロールしていいか」、noindexは「インデックスしていいか」です。クロール自体を止めると、ページ内容やnoindex解除の確認が難しくなるので、運用方針を決めて使い分けます。
X-Robots-Tagって何ですか？
HTTPレスポンスヘッダーでnoindexなどを指定できる仕組みです。HTMLのmetaを見ても原因が見つからない時は、ヘッダー側の付与を疑ってください。