すべてのウェブサイトにrobots.txtファイルが必要ですか？

厳密には必須ではありませんが、ベストプラクティスです。robots.txtファイルがない場合、検索エンジンはデフォルトでサイト全体をクロールします。robots.txtを使うと、管理者ページ、内部検索結果、重複コンテンツなどのクロールされるページを制御できます。

robots.txtでページが検索結果に表示されないようにできますか？

いいえ。robots.txtはクロールを防ぐものであり、インデックス登録を防ぐものではありません。ページがrobots.txtでブロックされていても、別のインデックス済みページからリンクされていれば、Googleは説明なしにそのURLを検索結果に表示する場合があります。ページが検索結果に表示されないようにするには、noindexメタタグまたはX-Robots-Tagヘッダーを使用してください。

robots.txtで誤ってGooglebotをブロックするとどうなりますか？

GoogleがブロックされたURLのクロールを停止します。それらのページが以前インデックスされていた場合、Googleのキャッシュが古くなるにつれて、検索結果から除去される可能性があります。Google Search ConsoleのURL検査ツールで、どのページがクロールされているかを確認してください。

robots.txtの正しい場所はどこですか？

robots.txtはドメインのルートに置く必要があります。例：https://yourdomain.com/robots.txt。そのドメインのURLにのみ適用されます。example.comのrobots.txtはsubdomain.example.comのクロールを制御しません。

robots.txtファイルをテストするにはどうすればいいですか？

Google Search Consoleのrobots.txtテスターツール（設定 > クロール > robots.txtテスター）を使用してください。URLを入力すると、現在のrobots.txtがGooglebotのクロールを許可しているかブロックしているかを確認できます。

robots.txtジェネレーター：2分でサイトに最適なファイルを作成する

robots.txtは、一度作成されると忘れられがちなファイルのひとつです。小規模なコンテンツサイトなら通常は問題ありません。しかし、管理者パネル、公開されたままのステージングパス、内部検索結果ページ、または重複コンテンツがあるサイトでは、設定を誤った（または存在しない）robots.txtが数ヶ月間にわたって静かにSEO問題を引き起こす可能性があります。

このガイドでは、robots.txtが実際に何をするのか、何をしないのか（混乱の一般的な原因）、そして一般的なウェブサイトタイプに適した正しいファイルの書き方を説明します。構文を暗記せずにrobots.txtジェネレーターを使えば、簡単に作成できます。

robots.txtが実際にすること

robots.txtは、ドメインのルートに置くプレーンテキストファイルで、ウェブクローラーにどのURLをクロールすべきか、すべきでないかを伝えます。重要な単語は「クロール」であり、「インデックス」ではありません。

ファイルはhttps://yourdomain.com/robots.txtに置かれます。Googlebot、Bingbot、その他のクローラーがサイトを訪れる際、最初に行うのがこのファイルの取得です。見つけた内容に基づいて、どのURLを辿るかを決定します。

最小限のrobots.txtはこのようになります：

User-agent: *
Allow: /

これはすべてのクローラーがすべてをクロールできることを意味します。robots.txtがない場合と機能的に同じです。

制限的なものはこのようになります：

User-agent: *
Disallow: /admin/
Disallow: /internal/
Disallow: /api/

すべてのディレクティブは、1つ以上のUser-agentグループに適用されるDisallowまたはAllow行です。

クロールとインデックスの違い（これは重要です）

多くの開発者は、robots.txtでURLをブロックするとGoogleの検索結果から削除されると思っています。そうではなく、これが実際の問題を引き起こします。

URLをブロックしたときに実際に起こること：

GooglebotはそのURLのクロールを停止します。そのページからのリンクを辿らず、コンテンツを読みません。
しかし、他のインデックス済みページがブロックされたURLにリンクしていれば、GoogleはそのURLが存在することを発見できます。
Googleは「このページに関する情報はありません」のような一般的な説明と共に、そのURLを検索結果に表示する場合があります。

したがって、検索結果から完全に除外したいページがある場合、Disallowだけでは不十分です。noindexディレクティブが必要です。しかし問題があります。ページがクロールからブロックされると、Googlebotはnoindexタグを読んで適用することができません。

これは困った状況を作ります。noindexを使うには、ページをクロールさせる必要があります。

基本原則：

SEOに重要でないページ（ステージングパス、内部API、重複フィルターページ）でクロール予算を無駄にしないよう、robots.txt Disallowを使います。
特定のページが検索結果に表示されないようにするには、noindexメタタグを使います。
本当に機密性の高いページ（管理者パネル、プライベートコンテンツ）には、robots.txtではなく実際の認証を使います。

User-Agent：特定のボットのターゲティング

User-agentフィールドを使うと、すべてのクローラーまたは特定のクローラーをターゲットにできます。

User-agent: *

アスタリスクは「他に指定されていないすべてのクローラー」を意味します。ほとんどのrobots.txtファイルは、一般的なルールにこれを使います。

特定のボットもターゲットにできます：

User-agent: Googlebot
Disallow: /no-google/

User-agent: Bingbot
Disallow: /no-bing/

User-agent: *
Disallow: /admin/

ルールはuser-agentグループごとに適用されます。GooglebotはGooglebotブロックに従います。一致するブロックがない場合、*ブロックにフォールバックします。

特に管理したいクローラー：

Googlebot — Googleのメインウェブクローラー
Googlebot-Image — Google専用の画像クローラー
Bingbot — Microsoft Bing
GPTBot — OpenAIの学習クローラー（コンテンツサイトにとって新しい懸念事項）
anthropic-ai — Anthropicの学習クローラー
AhrefsBot、SemrushBot、MJ12bot — SEOおよび分析ツール

AI学習クローラーを特にブロックしたい場合：

User-agent: GPTBot
Disallow: /

User-agent: anthropic-ai
Disallow: /

User-agent: *
Allow: /

これは増加しています。実際にサイトに重要かどうかは別の問題ですが、構文は正しいです。

よくあるDisallowパターン

一般的な状況に適した正しいパターンです：

ディレクトリ全体をブロック

User-agent: *
Disallow: /admin/

末尾のスラッシュが重要です。/admin/は/admin/settings、/admin/usersなどをブロックします。スラッシュなしで/adminとすると、/administratorや/admin-loginというページもブロックしてしまう可能性があります。おそらく望む結果ではないでしょう。

特定のファイルをブロック

User-agent: *
Disallow: /private-page.html

URLクエリパラメータのブロック（フィルターページ）

ECサイトでは、多くのフィルター組み合わせで同じ商品にアクセスできることがよくあります：/products?color=red&size=L&sort=price。これが重複コンテンツを生み出します。ブロックしましょう：

User-agent: *
Disallow: /*?

これはクエリ文字列を持つすべてのURLをブロックします。注意が必要です。重要なページがクエリ文字列を使用している場合（一部のSPAがそうです）、それらもブロックされます。より的を絞ったアプローチ：

User-agent: *
Disallow: /products/*?

これは/products/配下のクエリ文字列URLのみをブロックします。

ブロックされたディレクトリ内の特定パスを許可

ディレクトリのほとんどをブロックしつつ、1つのパスは許可したい場合：

User-agent: *
Disallow: /account/
Allow: /account/signup

user-agentブロック内の順序が重要です。ほとんどのクローラーは最も具体的に一致するルールを適用します。

Sitemapディレクティブ

robots.txtにサイトマップURLを含めるべきです：

User-agent: *
Disallow: /admin/

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

Sitemapディレクティブは最後に、すべてのuser-agentブロックの外に置きます。これは単なる礼儀ではありません。Googleはこれを使って重要なページのクロールを見つけ、優先順位をつけます。

画像やビデオサイトマップを持つ大規模サイトで複数のサイトマップがある場合：

Sitemap: https://yourdomain.com/sitemap.xml
Sitemap: https://yourdomain.com/sitemap-images.xml

Google Search Consoleでサイトマップを直接送信することをお勧めしますが、robots.txtに含めることでファイルを読むすべてのクローラーが自動的に発見できます。

Crawl-Delay：注意して使用

一部のクローラーはCrawl-delayディレクティブをサポートしています：

User-agent: *
Crawl-delay: 10

これはボットにリクエスト間に10秒待つよう伝えます。元々、クローラーが小規模サーバーに過負荷をかけるのを防ぐために使われていました。

問題は、Googlebotがこれを無視することです。GoogleはCrawl-delayをサポートしていないと明示的に述べています。Googlebotのクロール速度を下げたい場合は、Google Search Consoleのクロール速度設定で行う必要があります。

BingbotなどのボットはCrawl-delayをサポートしているので全く無意味ではありませんが、Google向けにはno-opです。レート制限に頼らないでください。

SEOを損なうよくあるミス

CSSとJavaScriptファイルのブロック

かつてはよくある助言でした。「帯域幅を節約するためにボットがスクリプトとスタイルシートをクロールしないようにしなさい。」これは悪い慣行です。Googleはページを正しく評価するためにレンダリングが必要で、レンダリングにはCSSとJavaScriptが必要です。これらをブロックすると：

# これをしないでください
User-agent: *
Disallow: /wp-content/
Disallow: /assets/
Disallow: /*.css$
Disallow: /*.js$

Googleがページが実際にどのように見えるかを確認できず、ランキングに影響する可能性があります。クローラーが静的アセットにアクセスできるようにしてください。

ステージングおよび開発環境の見落とし

ステージング環境がstaging.yourdomain.comまたはyourdomain.com/staging/でアクセス可能な場合、次のいずれかを確認してください：

認証の背後にある（推奨）
robots.txtでブロックされている

Googleにインデックスされたステージングコンテンツは重複コンテンツの問題を引き起こします。これは動きの速いサイトでよく見られる見落としです。

機密コンテンツの保護にrobots.txtを使用

これは繰り返す価値があります。robots.txtはアクセス制御ではありません。ファイルは公開されています。誰でもyourdomain.com/robots.txtを訪れて、隠そうとしたパスを正確に確認できます。それらのパスが興味深ければ、人々は直接アクセスするでしょう。本当に機密性の高いものにはサーバーサイド認証を使用してください。

誤ったサイトマップのブロック

# これは誤ってサイトマップをブロックします
User-agent: *
Disallow: /
Allow: /public/

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

この例では、/sitemap.xmlはAllow: /public/例外と一致しないため、Disallow: /によってブロックされます。ファイルのsitemapディレクティブはサイトマップURLを自動的にブロック解除しません。Allow: /sitemap.xmlを明示的に追加する必要があります。

誤った場所

robots.txtはドメインルートに置く必要があります。yourdomain.com/robots.txtは機能します。yourdomain.com/blog/robots.txtは何もしません。クローラーはそこを見ません。

また、yourdomain.comのrobots.txtはsubdomain.yourdomain.comには影響しません。そこでのクロールを制御したい場合、各サブドメインに独自のrobots.txtが必要です。

一般的なサイトタイプのrobots.txt例

標準コンテンツまたはマーケティングサイト

User-agent: *
Allow: /

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

隠すものがなく、重複コンテンツの問題もない場合はシンプルに保ちましょう。

WordPressサイト

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

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

Allow: /wp-admin/admin-ajax.phpが重要です。一部のテーマとプラグインは、Googlebotが正しいレンダリングのためにアクセスする必要があるフロントエンド機能にこのエンドポイントを使用しています。

フィルターページのあるECサイト

User-agent: *
Disallow: /cart/
Disallow: /checkout/
Disallow: /account/
Disallow: /search?
Disallow: /products/*?sort=
Disallow: /products/*?page=

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

カートと決済ページはインデックスされるべきではありません。アカウントページはユーザー固有のコンテンツです。フィルター・ソートURLの組み合わせは重複コンテンツを生み出します。

APIルートのあるNext.jsまたはSPA

User-agent: *
Disallow: /api/
Disallow: /_next/
Allow: /_next/static/
Allow: /_next/image

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

APIルートをブロックします。Next.jsの内部パスをブロックしますが、レンダラーが必要とする静的アセットと画像最適化エンドポイントは除外します。

robots.txtのテスト

ファイルが正しいと思わず、確認してください。

Google Search Consoleにはrobots.txtテスターがあります（設定 > robots.txt）。URLパスを入力すると、現在のrobots.txtに基づいてGooglebotが許可されているかブロックされているかを教えてくれます。Googleがファイルを最後に取得した内容も表示されます。

Search ConsoleのURL検査ツールを使うと個別のURLを確認し、Googleがアクセスしてレンダリングできるかを確認できます。

さまざまなSEOスイートのrobots.txtチェッカーなどのサードパーティツールは構文を検証し、複数のuser-agentをテストできます。SEOメタジェネレーターとOGイメージジェネレーターは、サイトの全体的なSEO設定の作業をする際の有用なツールです。

robots.txtに変更を加えた後、URL検査ツールを使ってGoogleに再取得を要求できます。変更は通常数日以内に反映されます。

robots.txtの生成

robots.txtを手書きするのは複雑ではありませんが、構文をわずかに間違えやすいです。スラッシュの欠落、間違った場所のディレクティブ、意図したものをカバーしないuser-agentブロックなどがあります。

robots.txtジェネレーターを使えば、設定するボットを選択し、ブロックするパスを指定し、サイトマップURLを追加して、クリーンで有効な出力を得ることができます。構文を調べるより速く、重要なページのクロールカバレッジを失わせるタイポの可能性を減らします。

生成後、ファイルをウェブサーバーのルートに置き、yourdomain.com/robots.txtでアクセスできることを確認してください。ほとんどのフレームワークで：

Next.js：public/robots.txtを追加するか、App Routerのrobots.tsルートを使用
Gatsby：static/robots.txtに置く
Hugo：static/robots.txtに置く
通常のHTMLサイト：ウェブサーバーが提供するルートディレクトリに置く

Next.js App Routerユーザーは、プログラムで生成することもできます：

// app/robots.ts
import { MetadataRoute } from 'next'

export default function robots(): MetadataRoute.Robots {
  return {
    rules: {
      userAgent: '*',
      allow: '/',
      disallow: ['/admin/', '/api/'],
    },
    sitemap: 'https://yourdomain.com/sitemap.xml',
  }
}

このアプローチは、ルールが環境変数に依存する可能性があるサイト（例：ステージングですべてのクローラーをブロック）には好ましいです。

robots.txtはシンプルですが、その周辺の誤解、特にクロールとインデックスの区別は、実際に、時にはデバッグが難しいSEO問題を引き起こします。ファイルを一度正しく設定し、Search Consoleでテストすれば、本当に忘れても大丈夫です。