robots.txt は、検索担当だけが触る設定ではありません。どの URL に Googlebot を向かわせ、どの URL への巡回を抑えるかを決める文書です。言い換えれば、どのページに検索投資を振り向けるかを定める配分表でもあります。売上に効くサービスページ、料金ページ、導入事例、比較記事の再クロールが遅い一方で、検索結果ページや並び替え URL ばかり巡回されているなら、問題は記事数の不足ではなく URL の優先順位です。
Google の robots.txt の概要 でも、robots.txt は主にクローラの巡回を管理するための仕組みであり、検索結果からページを消す方法ではないと整理されています。ここを取り違えると、「出したくないから robots.txt で止める」「重複しているから robots.txt で止める」といった短絡的な判断に流れやすくなります。その結果、重要ページの更新反映まで遅れ、営業機会を逃しかねません。robots.txt は文法より前に、なぜ止めるのかを事業側が説明できる状態にしてから書くべきです。
robots.txtを設定ファイルで終わらせない理由
robots.txt を見直すべきかどうかは、感覚ではなく数値で判断したほうが確実です。少なくとも次の三つに当てはまるなら、単なる設定ファイルの修正ではなく、経営判断の議題として扱う必要があります。
- 料金、サービス詳細、導入事例などの重要ページを更新してから再クロールまで 7日以上 かかっている。
- サーバーログを見ると、Googlebot の取得先のうち 20%以上 が検索結果ページ、絞り込み URL、並び替え URL、プレビュー URL に流れている。
- Search Console の ページのインデックス登録レポート で、「robots.txt によりブロックされました」に重要ディレクトリが混ざっている。
この三つのどれかが起きているなら、まず問うべきなのは「何を書くか」ではなく「何を守るか」です。月間 PV が 10 万未満のサイトでも、CMS の標準機能をそのまま公開すると、検索結果、タグ一覧、印刷用 URL、プレビュー URL、計測パラメータ付き URL が一気に増えます。すると Googlebot は更新してほしいページより、価値の薄い URL を先に取りに行きがちです。新規記事を追加しても反映が鈍いときは、この構造が原因になっている例が少なくありません。
一方で、すべてのサイトが細かな robots.txt 制御を必要とするわけではありません。たとえば、管理 URL が 300 未満 で、月間更新ページ数も 5 本未満、問い合わせ導線も数ページに集中している小規模サイトなら、複雑なルールを増やすより、不要な公開 URL を CMS 側で減らすほうが先です。問題がまだ小さい段階で例外だらけの robots.txt を作るのは避けるべきです。 運用負荷だけが増え、半年後には誰も読めない設定だけが残ります。
JPSM SEO 編集事業部でも、robots.txt の相談は文法チェックから始めません。先に、事業責任者と運用担当で「来期も伸ばしたい URL 群」と「巡回されても成果に結びつかない URL 群」を分けます。この線引きが曖昧なままでは、どれだけ整った記述を書いても、重要ページを守る設計にはなりません。
先に決める四つの制御手段の役割分担と順番
robots.txt を正しく使うには、まず目的ごとに道具を分ける必要があります。Google の公式情報を整理すると、役割分担はかなり明快です。robots.txt の概要、noindex による除外、重複 URL の統合、サイトマップの作成と送信 を混ぜて使うから混乱します。最初に道具を分ければ、設定事故の大半は防げます。
目的 | 最初に選ぶ手段 | 向いている例 | 避けるべき誤用 |
|---|---|---|---|
巡回の無駄を減らす | `robots.txt` | 内部検索結果、無限に増える絞り込み URL、並び替え URL、プレビュー URL | 検索結果から消したいページまで止める |
検索結果から外す | `noindex` | サンクスページ、終了したキャンペーン、公開は必要だが流入不要な案内ページ | 先に robots.txt でブロックする |
重複をまとめる | `rel="canonical"` | 計測パラメータ違い、同一商品の別導線、一覧の代表 URL 統一 | robots.txt を重複整理の代わりに使う |
公開対象を絞る | 認証・アクセス制御 | 会員ページ、契約書、管理画面、ステージング | robots.txt だけで守ろうとする |
この表で特に重要なのは、検索結果から外したいなら、最初に noindex を選ぶという点です。Google の noindex による除外 では、noindex を効かせるにはクローラがページを取得できる必要があると明記されています。つまり、robots.txt で先に止めると noindex を読んでもらえません。公開終了した特設ページや会員向けの案内を検索結果から外したいなら、まず noindex を使うべきです。
重複 URL の扱いも分けて考える必要があります。Google の 重複 URL の統合 では、robots.txt を canonical の代わりに使わないよう案内しています。理由は単純で、robots.txt で止めた URL も、外部リンクなどを手がかりに URL だけインデックスされる場合があるからです。重複をまとめたいなら canonical、巡回だけ減らしたいなら robots.txt。この順番を崩さないことが、判断をぶらさない最短距離になります。
例外があるのは、画像、動画、PDF のような非 HTML ファイルです。Google は robots.txt の概要 で、メディアファイルについては検索結果への表示を抑える用途でも robots.txt を使えると説明しています。ただし、通常の事業サイトで悩みやすいのは HTML ページの制御です。まずは HTML の判断を整理し、それ以外は必要になったときだけ個別に扱うほうが安全です。
守るURLと止めるURLを分ける五つの判断基準
robots.txt の成否は、記述の巧拙ではなく、仕分けの精度で決まります。現場で迷いにくいのは、次の五つの基準で URL を見る方法です。どれか一つでも「守る」に当てはまるなら、原則として robots.txt で止めるべきではありません。
売上や商談に直結するページは止めない
料金、サービス詳細、導入事例、比較ページ、地域別サービスページ、指名検索で着地しやすいブランドページは、原則としてクロールを許可すべきです。直近 90 日の自然検索経由で問い合わせ、資料請求、商談化の補助に入っているなら、現在の流入が小さくても止めてはいけません。営業資料で頻繁に紹介されるページも同じです。
例外は、同じ内容が PDF と HTML の両方で公開されていて、HTML を残したい場合です。このとき見直すべきなのは HTML ではなく、重複側の PDF や派生 URL の扱いです。robots.txt より、canonical や noindex のほうが適しています。
独立した検索意図がある一覧は守る
一覧ページだから止める、という判断は粗すぎます。重要なのは、その一覧に独立した検索意図があるかどうかです。たとえば「製造業向け SFA」「東京 税務顧問」「EC カート 比較」のように、一覧自体に需要があるなら守る側です。逆に、「赤色」「在庫あり」「価格の安い順」「20件表示」のような条件の掛け算で生まれる一覧は、検索意図が独立していないことが少なくありません。一覧かどうかではなく、検索意図が一つの着地点として成立しているかで決めるべきです。
目安として、Search Console の直近 90 日でクリックが 30 未満 でも、今期に伸ばす商材の重点領域なら守ります。反対に、クリックが多少あっても、その URL が内部検索結果や機械的な絞り込みの産物で、今後育てる方針がないなら止める候補です。ここは過去実績より、今後の方針を優先したほうが判断を誤りにくくなります。
更新から三日以内に反映したいページは守る
価格、在庫、導入事例、法改正対応ページ、セミナー告知など、更新後 72 時間以内に再クロールされたいページは守る対象です。ここに Googlebot を寄せたいのに、パラメータ URL や検索結果ページが巡回を奪っているなら、robots.txt の見直しは十分に経営判断になります。
例外は、更新頻度が高くても検索流入を狙っていない会員限定ページです。この場合は「守る」ではなく「公開範囲を絞る」が先です。認証か noindex を選び、robots.txt だけで片づけないようにします。
無限に増えるURLは早い段階で止める
最も優先して止めるべきなのは、価値が低いのに量だけ多い URL です。目安は明快です。一つのページ種別から 20 以上の派生 URL が自動生成されるなら、まず精査対象に入れてください。検索結果、ページネーション、並び替え、フィルタ、プレビュー、計測パラメータ付き URL は典型です。さらに、Googlebot の取得先の 20%以上 がこの種の URL に流れているなら、止める判断を先延ばしにする理由はほとんどありません。
例外は、絞り込みの中に検索需要が明確なものが混ざっている場合です。たとえば「地域名 × サービス名」や「用途別カテゴリ」のように、一覧自体が検索ニーズの受け皿になっているなら、全体を止めるべきではありません。このときは、守る絞り込みと止める絞り込みを分け、必要に応じて canonical と併用します。
そもそも公開範囲が違う情報は認証へ寄せる
契約書、見積書、管理画面、会員限定資料、ステージングは、robots.txt の議題ではありません。公開範囲の議題です。Google の robots.txt の概要 でも、ページを検索結果から隠したいなら password protection など別の方法を選ぶよう案内しています。見せたくない情報を robots.txt に頼って守る判断は避けるべきです。
例外は、公開ページではあるものの、検索流入だけ不要なケースです。サンクスページ、申し込み完了ページ、キャンペーン終了後の案内ページなどは認証まで不要な場合が多くあります。この場合は noindex を使います。
重要ページを守ると決めたなら、内部リンクの設計も同時に見直してください。止めないだけでは評価は集まりません。評価を寄せる導線の組み方は 内部リンク最適化の2026年実務 回遊を増やすだけで終わらない評価配分の考え方 で整理していますし、リンク文言まで詰めるなら アンカーテキスト最適化の最新実務 2025年更新ガイダンスから逆算する内部リンク設計 も合わせて確認すると判断が揃います。
サイト規模別に見る最初のrobots.txt設計方針
同じ robots.txt でも、最初に手を付ける場所はサイト規模で変わります。ここを一律にすると、止めすぎるか、逆に何も変わらないかのどちらかに寄ります。最初の一手は、次のように分けるのが実務的です。
サイトの状態 | 最初に止める対象 | 守るべき対象 | 例外と追加対応 |
|---|---|---|---|
月間 PV 10 万未満、管理 URL 5,000 未満の BtoB | 内部検索、プレビュー、印刷用 URL | サービス、料金、導入事例、比較記事 | 地域別・用途別ページは今後の方針次第で守る |
月間 PV 10 万〜100 万、商品点数 1 万超の EC | 並び替え、フィルタの掛け算、重複する一覧 | 商品詳細、主要カテゴリ、ブランド一覧 | 需要のある絞り込みだけ個別に残す |
月間 PV 100 万超、管理 URL 50 万超の大規模サイト | robots.txt 単体で解決しない | 重要ディレクトリ全体 | ディレクトリ再設計、canonical、サイトマップ、ログ監視を同時に行う |
会員制や資料配布が多いサイト | 公開範囲を見直す | 公開が必要な案内ページ | 会員ページは認証、公開案内だけ noindex |
月間PV10万未満のBtoBは小さく止める
この規模で多い失敗は、カテゴリ配下や `/service/` 配下を広く止めてしまうことです。やるべきことは逆で、最初は小さく止めることです。内部検索、プレビュー、印刷、タグ一覧のように、止めても商談への影響が薄い URL から着手してください。サービス詳細、料金、導入事例は将来の自然検索の核になりやすいため、最初から触らないほうが安全です。
商品点数の多いECは掛け算URLを優先する
商品詳細を止めるのではなく、絞り込みや並び替えの掛け算で増える一覧を先に疑うべきです。商品数が 1 万点超、フィルタ軸が 3 つ以上 ある EC では、一覧 URL が雪だるま式に増えます。ここを放置すると、商品詳細の更新より一覧の巡回が優先されやすくなります。EC で最初に止めるべきなのは、売れ筋商品ではなく無限に増える一覧です。
例外は、ブランド名、用途、価格帯などで明確な検索意図がある一覧です。そこは止めずに守り、不要な派生だけを絞るほうが成果につながります。
大規模サイトはrobots.txtだけで済ませない
管理 URL が 50 万超、複数 CMS、複数サブドメイン、多拠点運用という状態なら、robots.txt の修正だけで解決しようとするのは無理があります。サイトマップの作成と送信 では、検索結果に出したい canonical URL をサイトマップに入れるよう案内されています。大規模サイトでは、robots.txt、canonical、サイトマップ、内部リンク、ログ監視を一緒に設計しないと、どこかで矛盾が生じます。
例外として、問題が単一ディレクトリに集中している場合はあります。たとえば検索結果 URL だけが急増しているなら、まずその領域を止めるだけでも効果が出ます。ただし、全体設計を後回しにしないことが前提です。
会員制サイトは検索制御より公開制御を優先する
資料配布、マイページ、契約関連が多い事業では、robots.txt の話を始める前に「誰に見せるべきか」を決める必要があります。公開先を誤ったまま robots.txt で隠そうとすると、将来ほぼ確実に漏れます。会員向けページは認証、公開ページだが検索結果に出したくない案内は noindex。この二段階に分けたほうが安全です。
事故を防ぐrobots.txt記述と例外処理の原則
方針が固まったら、ここで初めて書き方に進みます。Google の robots.txt ファイルの作成と送信 を踏まえると、まず守るべきは次の四つです。ルートに置く、対象クローラを明示する、止める単位を揃える、大文字と小文字を雑に扱わない。 これだけでも事故の確率はかなり下がります。
おすすめは、止める対象を「URL の型」でまとめることです。毎月 URL を一本ずつ足していく運用は続きません。検索結果、プレビュー、印刷用 URL、並び替え、フィルタの掛け算など、増え方が同じものを一つのルールで止めるほうが保守しやすくなります。逆に、広いディレクトリを Disallow し、あとから Allow を何本も足す書き方は避けるべきです。例外のほうが多い設計は、止め方そのものを見直す必要があります。
記述のたたき台は、次のようにシンプルで十分です。
```txt User-agent: Disallow: /search/ Disallow: /preview/ Disallow: /print/ Disallow: /?sort= Disallow: /*?filter= Sitemap: https://www.example.com/sitemap.xml ```
この例で大事なのは、見た目の整い方ではなく、なぜ止めるかを運用担当が口頭で説明できることです。「検索結果なので止める」「プレビューなので止める」「並び替えなので止める」と言えないルールは、将来の改修で壊れます。カテゴリ配下を止める、サービス配下を止めるといった広い指定は、明確な理由がない限り避けたほうがよいでしょう。
さらに、次の六項目は公開前に必ず確認してください。
- robots.txt が本番ドメインのルートにあり、サブドメインごとに必要なファイルが分かれているか。
- `Disallow` に重要ディレクトリが巻き込まれていないか。
- サイトマップの作成と送信 の方針どおり、検索結果に残したい canonical URL だけがサイトマップに入っているか。
- `noindex` を使うページを robots.txt で止めていないか。
- JavaScript や CSS の共通資産を誤って止めていないか。
- 代表 URL を最低 5 本 選び、手動で取得可否を確認したか。
五番目は軽く見ないほうがよい項目です。Google の JavaScript SEO の基本 では、レンダリングに必要なリソースを塞ぐと、Google が内容を正しく把握できない可能性があると案内しています。SPA や JavaScript 依存のテンプレートを使っているなら、JS と CSS を止める判断は原則避けるべきです。例外は、検索評価に関係しないバックオフィス用の静的資産など、公開ページの表示に無関係なものに限られます。
公開後七日で確認するSearch Consoleの見方
robots.txt は公開した瞬間より、その後七日間をどう見るかで差が出ます。Search Console の URL 検査ツール では、その場での検査でインデックス可能性を確認でき、必要に応じてインデックス登録もリクエストできます。ただし、同じ案内の中で「リクエストしても登録は保証されない」「大量の URL はサイトマップ送信が適している」とも説明されています。一件ずつボタンを押して安心する運用は続きません。
公開後七日間は、次の順番で見るのが実務的です。
- 公開当日
重要ページ 2 本、止めたい URL 2 本、重複 URL 1 本の計 5 URL をその場で検査します。重要ページが取得不可なら、その日のうちに修正対象です。
- 1〜2日後
ページのインデックス登録レポート を見て、「robots.txt によりブロックされました」に何が入っているか確認します。`/service/`、`/case/`、`/pricing/` などの重要配下が入っていたら、迷わず戻すべきです。
- 3〜4日後
サイトマップ送信状況を確認します。検索結果に残したい URL だけが入っているか、エラーが出ていないか、canonical と矛盾していないかを見る段階です。
- 5〜7日後
サーバーログで Googlebot の取得先を見ます。止めた URL 群へのアクセス比率が 20% 未満 まで下がっているか、重要ページの取得頻度が上がっているかを確認します。
- 七日目
更新した重要ページの再クロールが 7日以内 に入っていれば、方針は概ね妥当です。入っていないなら、robots.txt だけでなく内部リンク、サイトマップ、テンプレート構造まで戻って見直す必要があります。
この段階で見るべきなのは、「全ページが登録されたか」ではありません。Google の ページのインデックス登録レポート でも、重複や noindex、robots.txt などの理由で除外されるページがあることを前提にしています。見るべきなのは、守るべきページが落ちていないか、止めたいページの巡回が減っているか、この二点です。
Search Console の読み方に不安があるなら、確認手順は Googleインデックス登録を早めたいときの実務手順。Search Consoleを道具として使い切る にまとめています。robots.txt だけを単独で見ず、Search Console とログを並べて判断したほうが、対処の優先順位がぶれません。
次の一週間で実行する社内判断の進め方
ここまでの話を一言でまとめるなら、robots.txt は「止めたい URL の一覧」ではなく、「どの URL に検索投資を寄せるかを決める文書」です。書き方から入ると、止めてはいけないページまで止めてしまいます。先に決めるべきなのは、守る URL、まとめる URL、検索結果から外す URL、そもそも公開しない URL の四分類です。
次の一週間で進めるなら、順番はこの五つで十分です。
- 現在のサイトマップ、主要ディレクトリ、パラメータ付き URL を一覧化する。
- その一覧を「守る」「まとめる」「外す」「公開しない」の四つに分ける。
- robots.txt で止めるのは「価値が低く、量が多い URL」だけに絞る。
- 重要ページ 5 本を代表 URL として選び、公開当日から七日間追う。
- ログと Search Console を並べ、再クロール日数と Googlebot の取得先比率で効果を判定する。
この順番で進めれば、URL の棚卸しと意思決定が先に固まるため、設定文の議論が短くなります。逆に、記述の細部から入り、守る URL を後で考える進め方は避けるべきです。止める理由を説明できないまま公開され、重要ページの評価更新が遅れるからです。
今日やるべき最初の一手は単純です。サービス、料金、導入事例、比較記事、検索結果、絞り込み URL の六種類だけを抜き出し、止めるか守るかを一行ずつ決めてください。 そこまで決まれば、robots.txt はもう技術担当だけの作業ではなく、事業側の優先順位を反映した運用文書に変わります。JPSM SEO 編集事業部でも、実務支援に入るときはこの棚卸しから着手します。設定を書く前に URL の役割を固めたほうが、修正回数が減り、公開後の判断も速くなるためです。