検索意図キーワード例（このガイドの対象）
- robots.txt 書き方
- robots.txt disallow 設定
- robots.txt 反映されない
- robots.txt noindex 違い
- Search Console robots.txt テスト
まず結論: robots.txtは「クロールしていいか」で、インデックス制御ではない
robots.txtはクローラーに対するアクセス制御です。検索結果に出す/出さない（インデックス）を直接制御する仕組みではありません。
インデックス制御（noindex）や代表URLの固定（canonical）と混同すると、状況が見えなくなり、復旧が遅れます。
安全な使い方（よくあるパターン）
- クロールさせたくない領域だけを最小で塞ぐ（管理画面、API、内部検索など）
- 重要ページや必要なリソース（CSS/JS）は塞がない（レンダリング確認が難しくなる）
- パターン指定（ワイルドカード等）は広く巻き込まないように慎重に
- 方針が決まっていないページをとりあえず塞ぐ、を避ける（後で事故る）
テスト手順（本番でやる前に確認する）
- Search Consoleのrobots.txtテスター（利用可能な場合）やURL検査で、取得可否を確認する
- 代表URLでクロール可否を確認し、ディレクトリ単位で巻き込みがないか点検する
- 修正後は重要ページから再クロールを促し、影響範囲を観測する
よくある失敗（現場の事故パターン）
- 誤って `/` など広いDisallowを入れて全ページを塞ぐ
- ステージング用の設定を本番に持ち込む
- インデックスから消したいのにrobots.txtで塞いでしまい、状況確認ができない
- パラメータURL増殖を雑にrobotsで塞ぎ、内部リンクと正規化が崩れる
robots.txtチェックリスト（公開前）
- 塞ぐのは“必要最小限”で、意図が説明できる
- 重要ページの取得ができる（URL検査で取得可能）
- 必要リソース（CSS/JS/画像）が塞がれていない
- noindex/canonical/内部リンクと方針が矛盾していない
よくある質問（Q&A）
robots.txtでブロックしたら検索結果から消えますか？
保証されません。クロールできないため、検索エンジンがページを再評価できず、URLだけが残ることもあります。検索結果に出したくない場合はnoindex等の方針を検討します。
robots.txtとnoindexはどっちを使うべき？
目的が違います。クロールを止めたいならrobots.txt、検索結果に出したくないならnoindex（ただしクロールは必要な場合がある）という前提で、方針を決めます。
robots.txtを変えたのに反映されない
キャッシュや再取得のタイミングで遅れることがあります。重要ページで取得可否を確認し、時間経過で再チェックします。