2-2 robots.txt と sitemap.xml の書き方

このレッスンで身につくこと

検索エンジンに見つけてもらう「最初の一歩」は、コンテンツの量でも被リンクでもなく、サイトの入り口を整えること です。次の 2 つのファイルを正しく置くだけで、Google のクローラーは効率よくサイトを巡回できるようになります。

• robots.txt — クローラーへの「案内板」。どこを見ていいか、どこは見ないでほしいかを伝える
• sitemap.xml — クローラーへの「目次」。サイトに存在する全ページのリスト

所要時間 — 約 45 分 難易度 — ★★☆☆☆

robots.txt とは — クローラーへの「案内板」

お店に例えて理解する

robots.txt は、サイトのルート（https://example.com/robots.txt）に置く テキストファイル 1 枚 です。役割は「クローラーへの案内板」。リアル店舗に例えると下記のとおりです。

==Google のクローラーはサイトに最初に来たとき、まず /robots.txt を読みます==。ここに書かれた指示に従って、どこを巡回するかを決めます。

何を Disallow すべきか

「全部見せたほうが SEO に良いのでは？」と思うかもしれませんが、逆です。見せる必要のないページを除外する ことで、クローラーは大事なページに集中できます。

逆に、絶対に Disallow してはいけないのは ==/（サイト全体） /blog/ /posts/（記事ページ） /css/ /js/ /images/（スタイルや画像。レンダリングが崩れる）== の 3 つです。

クロールバジェットという考え方

クロールバジェット とは、Google が「1 つのサイトに 1 日にどれくらいクロールするか」の予算です。商品 10 万件の EC で検索結果ページ（/search?q=...）を無制限にクロールさせると、肝心の商品ページがいつまでも巡回されません。robots.txt で検索結果ページを Disallow しておくと、商品ページに予算が集中 します。中小サイト（1,000 ページ以下）では気にする必要はほぼありませんが、管理画面と API は Disallow しておくのが行儀です。

robots.txt の書き方と最低限の設定

構文の基本

robots.txt の構文はとてもシンプルで、覚えることは 4 つだけです。

User-agent: <対象クローラー名>   # 誰に対する指示か
Allow: <パス>                    # 許可するパス
Disallow: <パス>                 # 禁止するパス
Sitemap: <URL>                   # サイトマップの場所

User-agent: * の * は「すべてのクローラー」を意味します。特定のクローラーだけに別ルールを当てたいときは、別のブロックを書きます。

最低限のテンプレート（コピペ用）

ほとんどのサイトはこのテンプレートで OK です。あなたのドメインに合わせて Sitemap の URL だけ書き換えてください。

# robots.txt — 標準テンプレート

User-agent: *
Allow: /
Disallow: /admin/
Disallow: /api/
Disallow: /private/
Disallow: /search

Sitemap: https://example.com/sitemap.xml

これだけで、管理画面と API と検索結果ページを除外しつつ、サイトマップの場所も伝える という最低限の役割が果たせます。

配置場所のルール

robots.txt は必ずサイトのルート に置きます。サブディレクトリに置いても認識されません。

OK   https://example.com/robots.txt
OK   https://blog.example.com/robots.txt  （サブドメイン単位で別ファイル）
NG   https://example.com/docs/robots.txt  （サブディレクトリ × ）

サブドメインごとに別の robots.txt を置けるのは便利な特徴です。本番（www.example.com）とステージング（staging.example.com）で別の設定にしておけば、ステージング環境を誤って検索結果に出してしまう事故を防げます。

Claude Code に robots.txt を書いてもらう

設定方針を日本語で伝えれば、Claude Code が一発で生成します。

> robots.txt を作って。サイトは example.com で、
  /admin/ /api/ /search は除外したい。sitemap.xml も指定してね。

プロジェクトのフレームワーク（Next.js / Astro / React Router など）に応じて、正しい配置先 も Claude が自動で判断します。「public/ の下に置けばビルド時にルートに配信される」といった現代フレームワーク特有の置き場所も把握しています。

AI クローラー対応（GPTBot, ClaudeBot, PerplexityBot）

なぜ AI クローラー対応が必要か

2024 年以降の大きな変化 は、Google 以外に「AI クローラー」と呼ばれる新種のクローラーが急増したことです。ChatGPT・Claude・Perplexity などの AI サービスは、Web を独自にクロールして学習データや検索結果ソースに使います。

判断ポイントは 学習データに使われていいか と AI 検索の回答ソースに使われたいか の 2 軸。学習はイヤだけど引用はされたい、という選択もできます。

3 つの典型パターン

パターン A — 全 AI クローラーをブロック（情報を絞りたい企業向け）

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: PerplexityBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: CCBot
Disallow: /

パターン B — 全 AI クローラーを許可（SEO/AIO どちらも狙う公開サイト向け）。robots.txt に何も書かなければデフォルトで Allow です。

パターン C — ブログだけ AI に許可、商品ページは除外（B2C EC の典型）。各 AI クローラーに対して Allow: /blog/ と Disallow: / を組み合わせて書きます。

Claude Code に AI クローラー設定を任せる

> robots.txt に AI クローラー対応を追加して。
  /blog/ は GPTBot ClaudeBot PerplexityBot に許可、それ以外はブロック。

Claude Code は主要な AI クローラー名を把握しているので丸投げで問題ありません。心配なら生成後に「OpenAI / Anthropic / Perplexity 公式の最新情報と一致してる？」と聞き返すと、参照リンク付きで答えてくれます。

sitemap.xml とは — クローラーへの「目次」

サイトマップが必要な理由

サイトマップは、サイト内の全ページのリストを XML 形式で書いたファイルです。レストランのメニュー一覧のように「うちのサイトにはこれだけのページがありますよ」と Google に伝えます。

サイトマップがあると、新しいページが検索結果に出るまでの時間が大幅に短くなります。サイトマップがないと、Google は リンクをたどって ページを発見するしかなく、リンクが少ないページは 1 年経っても気づかれない こともあります。新規サイト・大規模サイト・動的生成のページが多いサイト・孤立ページがあるサイトで特に効きます。

XML サイトマップの構造

中身は次のような XML ファイルで、1 ページ 1 ブロックで書きます。

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2026-05-19</lastmod>
  </url>
  <url>
    <loc>https://example.com/blog/seo-basics</loc>
    <lastmod>2026-05-12</lastmod>
  </url>
</urlset>

タグは <loc>（URL、必須）/ <lastmod>（最終更新日、推奨）/ <changefreq>（更新頻度、任意）/ <priority>（重要度、任意）の 4 つ。==現在の Google は <changefreq> と <priority> をほぼ無視 しているので、実質的に意味があるのは <loc> と <lastmod> の 2 つだけ== と覚えておけば OK です。

サイズと分割ルール

サイトマップ 1 ファイルあたりの上限は 50,000 URL / 50MB（未圧縮） です。超える場合は複数に分割して、それらをまとめる サイトマップインデックス（sitemap-index.xml）を作ります。大規模 EC では「商品」「カテゴリ」「ブログ」「ヘルプ」のようにテーマ別に分割するのが一般的です。中小サイトはこの構造を意識する必要はありません。

サイトマップの自動生成（Claude Code に書かせる）

静的サイトの場合

Astro / Next.js / Nuxt などのフレームワークには、サイトマップを自動生成するプラグインがあります。

> このプロジェクトに sitemap.xml の自動生成を仕込んで。
  ビルド時にすべてのページが含まれるようにしたい。

Claude Code は package.json を読んでフレームワークを判定 → 適切なプラグインを選定（例: @astrojs/sitemap）→ bun add でインストール → 設定ファイルに追加 → ローカルビルドで dist/sitemap-index.xml が生成されるか確認、という手順を自分で組み立てます。

動的サイトの場合

DB から動的にページを生成しているサイト（CMS、EC など）では、DB を直接読んでサイトマップを構築するスクリプトを書きます。> /scripts/generate-sitemap.ts を作って。posts テーブルから published のレコードを全件取り出して /blog/[slug] の URL リストを sitemap.xml として書き出す。lastmod は updated_at から。 のように依頼すれば一発。CI に組み込めばデプロイのたびに最新のサイトマップが生成 される運用が完成します。

サイトマップのチェック

すでに本番にサイトマップがある場合は、> /seo sitemap https://example.com と投げるだけで、サイトマップの存在 / XML の正しさ / URL の重複 / 404 や 301 にリダイレクトされる URL / HTTPS と HTTP の混在 / 上限超過、をまとめて診断してくれます。特に多い問題は 古い URL が残っている ことで、記事を削除したのに sitemap.xml には残っていて Google が毎日 404 を踏む — というケースは中小サイトでもよく見ます。

Google Search Console への登録

サイトマップは「置くだけ」では足りない

サイトマップを作って https://example.com/sitemap.xml に置いただけでは、Google は 気づかない可能性 があります。robots.txt に書いておくか、Google Search Console（GSC） から能動的に送信するのが確実です。

Search Console での送信手順

https://search.google.com/search-console にアクセス → プロパティを追加（ドメイン or URL プレフィックス）→ 所有権の確認（DNS レコード / HTML タグ / ファイルアップロードのいずれか）→ 左メニュー「サイトマップ」→ 「新しいサイトマップの追加」に sitemap.xml を入力して送信。

送信後 24〜48 時間で「成功しました」と表示されれば OK。エラーが出る場合はサイトマップの中身に問題があります。

Search Console から得られる情報

送信後は次のような数字が確認できます。検出された URL 数 / インデックス登録された URL 数 / 除外された URL 数とその理由 / サイトマップ最終読み込み日。検出 100 / インデックス 30 みたいに大きな差がある場合は、コンテンツの質や重複の問題があります。第 3 章のコンテンツ品質編で対策を扱います。

失敗パターン — 本番で踏みたくない罠

ここからは「やってしまうと痛い」失敗パターンを見ていきます。経験者ほどこのセクションに価値を感じます。

失敗 1 — 本番で Disallow: / を書いてしまう

史上最悪のミス。サイト全体を Google から消す、検索流入ゼロ化の魔法です。User-agent: * / Disallow: / を書いた瞬間、全ページが対象になります。これが起きるのは大抵 「ステージングの robots.txt を本番に持ってきてしまった」 ケース。リカバリは設定を直して数日待つだけですが、検索順位が戻るのに数週間かかる ことがあります。

失敗 2 — sitemap.xml の URL が間違っている

サイトマップに書く URL は ==絶対 URL（https:// から始まる完全な URL）== である必要があります。相対パス（/blog/seo）、プロトコルなし（example.com/blog/seo）、HTTPS 運用なのに HTTP で書いたもの — これらは全部 NG です。サブドメインの揺れ（www. の有無）にも注意し、canonical URL（正規 URL）と一致させます。

失敗 3 — Disallow したページをサイトマップに入れる

「見ないで」と言いながら目次には載せる、矛盾した指示です。Search Console で警告が出るだけでなく、Google からの サイトの信頼度 にも影響します。robots.txt で /admin/ を Disallow しているのに、sitemap.xml に https://example.com/admin/dashboard が紛れ込んでいる、というケースが典型例。サイトマップを動的生成にしておけば、機械的に整合させやすくなります。

失敗 4 — noindex と Disallow を併用

noindex メタタグ（HTML 内に書く）と robots.txt の Disallow は、似ているようで動きが違います。

==noindex を効かせたいページは Disallow してはいけません==。クローラーが HTML を読まないと noindex メタタグの存在に気づけないからです。「検索結果から消したい」なら noindex メタタグのみ、「クロールバジェットを節約したい」なら Disallow のみ、と目的で切り分けます。

失敗 5 — 古い URL がサイトマップに残り続ける

半年前に消した記事の URL がサイトマップに残っていて、Google が毎日 404 を踏みに来る — 中小サイトで一番よく見る問題です。Search Console の「サイトマップ」レポートを月 1 で確認するか、サイトマップを動的生成にして DB と常に同期させるのが解決策。Claude Code に > このサイトマップに 404 になる URL が含まれていないかチェックして。 と投げると、各 URL に HEAD リクエストを送って 404 / 301 のリストを返してくれます。

まとめ

このレッスンで押さえてほしいポイントを 6 つ並べます。

1. robots.txt はクローラーへの案内板。管理画面・API・検索結果ページは Disallow、それ以外は Allow が基本
2. ==Disallow: / は破壊魔法==。本番で絶対に書かない。ステージングの設定が紛れ込む事故に注意
3. AI クローラー（GPTBot / ClaudeBot / PerplexityBot） への対応方針を決めておく
4. サイトマップは目次。<loc> と <lastmod> だけ意識すれば OK
5. Search Console に送信 して検出数・インデックス数を毎週確認
6. robots.txt とサイトマップの整合性 を取る。Disallow したページはサイトマップから外す

<Quiz question="robots.txt で「見ないで」と指定したページはサイトマップに入れるべきですか？" options={["入れない — Google が混乱する","入れる — 全ページを含めるべき","どちらでもよい"]} answer={0} />

<Quiz question="本番サイトの robots.txt に絶対に書いてはいけないのは？" options={["Disallow: / （サイト全体を検索結果から消してしまう）","Disallow: /admin/","Sitemap: https://example.com/sitemap.xml"]} answer={0} />

<Quiz question="AI クローラーの代表例として正しい組み合わせは？" options={["GPTBot / ClaudeBot / PerplexityBot","Googlebot / Bingbot / Yahoo Slurp","Chrome / Safari / Firefox"]} answer={0} />

次のレッスン 2-3: モバイル対応とセキュリティ では、Google が評価の基準にしているスマホ表示と HTTPS の話に進みます。