robots.txtとは? — クローラー制御の基本ファイル
robots.txtとは、Webサイトのルートディレクトリに配置するテキストファイルで、検索エンジンのクローラー(ボット)に対してクロールの許可・拒否を指示するためのファイルです。正式には「Robots Exclusion Protocol(ロボット排除プロトコル)」と呼ばれる仕様に基づいています。
たとえば、あなたのサイトが https://example.com であれば、robots.txtは以下のURLに配置します。
https://example.com/robots.txt
クローラーはWebサイトにアクセスする際、まずこのファイルを読みに行きます。そこに書かれた指示に従い、クロールすべきページとクロールを避けるべきページを判断します。
robots.txtが必要な理由
robots.txtを適切に設定する主な理由は以下の3つです。
- クロールバジェットの最適化:検索エンジンが1つのサイトに割り当てるクロールの回数(クロールバジェット)には限りがあります。重要でないページへのクロールを制限し、重要なページを優先的にクロールさせることで、インデックス効率を高められます。
- 不要なページのクロール防止:管理画面、検索結果ページ、重複コンテンツのあるURLなど、インデックスする必要のないページへのクロールを防ぎます。
- サーバー負荷の軽減:大量のクロールによるサーバーへの負荷を軽減できます。特にページ数の多いサイトでは重要な考慮事項です。
ただし、robots.txtには重要な注意点があります。robots.txtはクロールの「お願い」であり、強制力はありません。Googleなどの主要な検索エンジンのクローラーはrobots.txtの指示に従いますが、悪意のあるボットは無視する可能性があります。また、robots.txtでクロールをブロックしても、外部サイトからのリンクなどにより、ページがインデックスされる可能性はゼロではありません。ページを完全に検索結果から除外するには、meta robotsタグのnoindexを使う必要があります。
robots.txtの公式仕様は、Googleが公開しているrobots.txtの仕様ドキュメントで確認できます。基本的な仕組みを理解したうえで、次のセクションで具体的な構文を学んでいきましょう。
robots.txtの基本構文 — 4つのディレクティブ
robots.txtの記述は、いくつかのディレクティブ(指示文)の組み合わせで成り立っています。ここでは、最も重要な4つのディレクティブを解説します。
1. User-agent(対象クローラーの指定)
User-agentは、どのクローラーに対する指示かを指定するディレクティブです。すべてのクローラーを対象にする場合はワイルドカード(*)を使います。
# すべてのクローラーに対する指示
User-agent: *
# Googlebotのみに対する指示
User-agent: Googlebot
# Bingbotのみに対する指示
User-agent: Bingbot
特定のクローラーに個別の指示を与えたい場合は、それぞれのUser-agentブロックを記述します。特定のクローラー向けの指示がある場合、そのクローラーはUser-agent: *の指示を無視し、自分専用のブロックの指示に従います。
2. Disallow(クロール拒否)
Disallowは、クロールを拒否するパスを指定するディレクティブです。
# /admin/ 以下のすべてのページをクロール拒否
User-agent: *
Disallow: /admin/
# 特定のファイルをクロール拒否
User-agent: *
Disallow: /private/secret-page.html
# サイト全体をクロール拒否(開発環境などで使用)
User-agent: *
Disallow: /
Disallow:の値を空にすると、「拒否するものはない=すべてクロール可」という意味になります。
# すべてのクロールを許可
User-agent: *
Disallow:
3. Allow(クロール許可)
Allowは、Disallowで拒否したディレクトリの中で、特定のパスだけクロールを許可するために使います。Googleの拡張仕様で、Googlebot・Bingbotなど主要なクローラーが対応しています。
# /private/ 以下は基本的にクロール拒否、ただし /private/public-page.html は許可
User-agent: *
Disallow: /private/
Allow: /private/public-page.html
AllowとDisallowが競合する場合、Googleはより具体的な(パスが長い)方の指示を優先します。パスの長さが同じ場合はAllowが優先されます。
4. Sitemap(サイトマップの場所を指定)
Sitemapは、XMLサイトマップの場所をクローラーに伝えるディレクティブです。これはどのUser-agentブロックにも属さず、ファイルの末尾に独立して記述するのが一般的です。
Sitemap: https://example.com/sitemap.xml
複数のサイトマップがある場合は、それぞれを別の行に記述します。
Sitemap: https://example.com/sitemap.xml
Sitemap: https://example.com/sitemap-news.xml
ディレクティブ一覧表
| ディレクティブ | 役割 | 記述例 | 必須/任意 |
|---|---|---|---|
User-agent |
対象クローラーを指定 | User-agent: * |
必須 |
Disallow |
クロールを拒否するパスを指定 | Disallow: /admin/ |
必須(User-agentごとに最低1つ) |
Allow |
Disallowの例外として許可するパスを指定 | Allow: /admin/public/ |
任意 |
Sitemap |
XMLサイトマップのURLを指定 | Sitemap: https://example.com/sitemap.xml |
任意(推奨) |
パターンマッチングの記法
robots.txtでは、より柔軟なパス指定のためにワイルドカードと特殊文字を使えます。
*(アスタリスク):任意の文字列にマッチします。Disallow: /*.pdf$のように使います。$(ドル記号):URLの終端を意味します。Disallow: /*.pdf$は.pdfで終わるURLのみをブロックします(.pdf?query=1はブロックしません)。
# すべてのPDFファイルへのクロールを拒否
User-agent: *
Disallow: /*.pdf$
# パラメータ付きURLをクロール拒否
User-agent: *
Disallow: /*?*
# 特定の拡張子を持つファイルをクロール拒否
User-agent: *
Disallow: /*.xml$
Disallow: /*.json$
構文の基本を押さえたところで、実際にコピペで使えるテンプレートを見ていきましょう。サイトの種類別に最適化されたテンプレートを用意しました。
robots.txtのテンプレート集
ここでは、サイトの種類に応じたrobots.txtのテンプレートを紹介します。いずれもコピペして、自分のサイトのドメインやパスに書き換えるだけで使えます。
一般的なWebサイト用テンプレート
コーポレートサイトやブログなど、一般的なWebサイト向けの基本的なテンプレートです。
# ===========================================
# robots.txt — 一般的なWebサイト用テンプレート
# ===========================================
# すべてのクローラーに対する基本設定
User-agent: *
Disallow: /admin/
Disallow: /cgi-bin/
Disallow: /tmp/
Disallow: /search?
Disallow: /404.html
Disallow: /*?utm_*
Disallow: /*?ref=*
Allow: /
# AIクローラーの制御(必要に応じてコメントアウトを外す)
# User-agent: GPTBot
# Disallow: /
# User-agent: PerplexityBot
# Disallow: /
# サイトマップの場所
Sitemap: https://example.com/sitemap.xml
このテンプレートでは以下を設定しています。
- 管理ディレクトリ(
/admin/)やCGI実行ディレクトリ(/cgi-bin/)へのクロールを拒否 - サイト内検索結果ページ(
/search?)のクロールを拒否 - UTMパラメータやリファラーパラメータ付きURLのクロールを拒否(重複コンテンツ対策)
- 404ページのクロールを拒否
- それ以外のすべてのページのクロールを許可
WordPress用テンプレート
WordPressサイトでは、管理画面やプラグインのディレクトリなど、クロールが不要な領域が複数あります。以下のテンプレートはWordPressの標準的なディレクトリ構造に最適化しています。
# ===========================================
# robots.txt — WordPress用テンプレート
# ===========================================
# すべてのクローラーに対する基本設定
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/cache/
Disallow: /wp-json/
Disallow: /feed/
Disallow: /comments/feed/
Disallow: /trackback/
Disallow: /?s=
Disallow: /search/
Disallow: /*?replytocom=*
Disallow: /tag/*/feed/
Disallow: /tag/*/page/
Disallow: /author/*/feed/
Disallow: /*?utm_*
Disallow: /readme.html
Disallow: /license.txt
# 画像やメディアファイルはクロール許可
Allow: /wp-content/uploads/
# AIクローラーの制御(必要に応じてコメントアウトを外す)
# User-agent: GPTBot
# Disallow: /
# User-agent: PerplexityBot
# Disallow: /
# サイトマップの場所(Yoast SEOなどのプラグインが生成)
Sitemap: https://example.com/sitemap_index.xml
WordPressの場合、以下のポイントに注意してください。
/wp-admin/をブロックしつつ、admin-ajax.phpは許可:WordPressのフロントエンドで使用されるAjax処理が正常に動作するために必要です。/wp-includes/のブロック:WordPressのコアファイルへの不要なクロールを防ぎます。/wp-content/uploads/の許可:画像やメディアファイルはGoogle画像検索などからのトラフィックを獲得するため、クロールを許可します。- フィードやトラックバックのブロック:RSSフィードやトラックバックURLは重複コンテンツになりやすいため、ブロックするのが一般的です。
readme.htmlとlicense.txtのブロック:WordPressのバージョン情報が含まれるファイルは、セキュリティの観点からクロールをブロックします。
なお、WordPressのSEOプラグイン(Yoast SEO、All in One SEOなど)は自動的にrobots.txtを生成する機能を持っている場合があります。プラグインの設定と手動のrobots.txtが競合しないよう注意してください。SEO内部対策全般については、SEO内部対策の解説記事もあわせてご確認ください。
Next.js用テンプレート(静的生成)
Next.jsでは、App Routerを使用してrobots.tsファイルからrobots.txtを動的に生成するのが一般的です。以下は、Next.jsプロジェクトで使用するTypeScriptベースのテンプレートです。
// src/app/robots.ts
import type { MetadataRoute } from 'next';
export default function robots(): MetadataRoute.Robots {
const baseUrl = 'https://example.com';
return {
rules: [
{
userAgent: '*',
allow: '/',
disallow: [
'/api/',
'/_next/',
'/admin/',
'/search?',
],
},
// AIクローラーをブロックする場合
// {
// userAgent: 'GPTBot',
// disallow: '/',
// },
// {
// userAgent: 'PerplexityBot',
// disallow: '/',
// },
],
sitemap: `${baseUrl}/sitemap.xml`,
};
}
このコードをビルドすると、以下のようなrobots.txtが自動生成されます。
User-agent: *
Allow: /
Disallow: /api/
Disallow: /_next/
Disallow: /admin/
Disallow: /search?
Sitemap: https://example.com/sitemap.xml
Next.jsでrobots.txtを実装する際のポイントは以下のとおりです。
/api/ルートのブロック:Next.jsのAPIルートはクロール不要なため、ブロックします。/_next/のブロック:Next.jsの内部アセットディレクトリへのクロールを防ぎます。- 環境変数でドメインを管理:本番環境と開発環境でドメインが異なる場合は、
process.env.NEXT_PUBLIC_BASE_URLなどの環境変数を使うと便利です。 - 静的生成(SSG)との相性:ビルド時にrobots.txtが生成されるため、デプロイのたびに最新の状態が反映されます。
テクニカルSEOの実装全般については、テクニカルSEOの実践ガイドやテクニカルSEOとは何かを解説した記事も参考にしてください。また、当サイトのテクニカルSEOに関する教材でも詳しく解説しています。
AIクローラーの制御 — GPTBot・PerplexityBotの設定(2026年最新)
2026年現在、ChatGPTやPerplexityなどのAIサービスが普及し、それらのサービスがWebサイトの情報を収集するためのAIクローラーへの対応が、サイト運営者にとって重要なテーマとなっています。
AIクローラーは、検索エンジンのクローラーとは異なる目的でWebサイトにアクセスします。検索エンジンのクローラーがインデックス作成を目的としているのに対し、AIクローラーはLLM(大規模言語モデル)の学習データ収集や、AIによる回答生成のための情報取得を目的としています。
主要なAIクローラー一覧
| クローラー名(User-agent) | 運営元 | 用途 | robots.txt準拠 |
|---|---|---|---|
GPTBot |
OpenAI | ChatGPT・GPT系モデルの学習データ収集 | 準拠 |
ChatGPT-User |
OpenAI | ChatGPTのブラウジング機能でのリアルタイム情報取得 | 準拠 |
OAI-SearchBot |
OpenAI | ChatGPT Search(AI検索)でのリアルタイム情報取得 | 準拠 |
PerplexityBot |
Perplexity AI | Perplexityの回答生成のための情報取得 | 準拠 |
ClaudeBot |
Anthropic | Claudeの学習データ収集 | 準拠 |
Amazonbot |
Amazon | Alexa・Amazon検索向けの情報収集 | 準拠 |
Bytespider |
ByteDance | TikTokなどの関連サービス向け情報収集 | 準拠 |
meta-externalagent |
Meta | Meta AI(Llama系モデル)の学習データ収集 | 準拠 |
Google-Extended |
Gemini(旧Bard)の学習データ収集 | 準拠 |
AIクローラーをブロックする設定例
AIクローラーによるコンテンツの学習利用を望まない場合は、robots.txtで明示的にブロックできます。
# ===========================================
# AIクローラーのブロック設定
# ===========================================
# OpenAIのクローラー(学習用)をブロック
User-agent: GPTBot
Disallow: /
# OpenAIのクローラー(ChatGPTブラウジング用)をブロック
User-agent: ChatGPT-User
Disallow: /
# OpenAIのクローラー(ChatGPT Search用)をブロック
User-agent: OAI-SearchBot
Disallow: /
# Perplexityのクローラーをブロック
User-agent: PerplexityBot
Disallow: /
# Anthropicのクローラーをブロック
User-agent: ClaudeBot
Disallow: /
# GoogleのAI学習用クローラーをブロック(通常の検索クロールには影響なし)
User-agent: Google-Extended
Disallow: /
# MetaのAI学習用クローラーをブロック
User-agent: meta-externalagent
Disallow: /
# ByteDanceのクローラーをブロック
User-agent: Bytespider
Disallow: /
AIクローラーを部分的に許可する設定例
一方で、AI検索からのトラフィック獲得を見据え、AIクローラーを戦略的に許可するケースも増えています。たとえば、学習用のクローラーはブロックしつつ、リアルタイム回答生成用のクローラーは許可するという使い分けが可能です。
# ===========================================
# AIクローラーの選択的制御
# ===========================================
# GPTBotの学習用クロールはブロック
User-agent: GPTBot
Disallow: /
# ChatGPTのブラウジング機能は許可(AI検索からの流入を獲得)
User-agent: ChatGPT-User
Disallow:
# ChatGPT Searchは許可
User-agent: OAI-SearchBot
Disallow:
# Perplexityは許可(AI検索からの流入を獲得)
User-agent: PerplexityBot
Disallow:
# Google-Extendedの学習用クロールはブロック(通常検索には影響なし)
User-agent: Google-Extended
Disallow: /
この設定では、AIモデルの学習にコンテンツが使われることは防ぎつつ、AI検索サービスがリアルタイムであなたのサイトの情報を参照し、ユーザーに回答として提示することは許可しています。AI検索経由でのトラフィックを獲得しつつ、コンテンツの無断学習は防ぐという、バランスの取れたアプローチです。
llms.txtについて
robots.txtとは別に、AIモデル向けに情報を提供するためのllms.txtという新しい仕様も登場しています。llms.txtはAIがサイトの情報を効率的に理解するための構造化ドキュメントで、robots.txtのようなアクセス制御ではなく、積極的な情報提供を目的としています。AIとの共存を前提としたSEO戦略について詳しくは、LLMOとは何かを解説した記事もご覧ください。
robots.txtのよくあるミスと修正例(Before/After)
robots.txtは記述ミスが起きやすく、小さな間違いがSEOに大きな影響を及ぼすことがあります。ここでは、実務でよく見かける5つのミスパターンと、その修正例をBefore/After形式で紹介します。
ミス1:サイト全体を誤ってブロックしてしまう
最も致命的なミスの1つです。開発環境のrobots.txtをそのまま本番環境にデプロイしてしまうケースで頻発します。
Before(NG)
# 開発環境用の設定をそのまま本番に使ってしまった
User-agent: *
Disallow: /
After(OK)
# 本番環境ではすべてのクロールを許可
User-agent: *
Disallow:
Sitemap: https://example.com/sitemap.xml
解説:Disallow: /はサイト全体のクロールを拒否する設定です。本番環境でこの設定にすると、すべてのページがインデックスから消えてしまいます。開発環境・ステージング環境と本番環境でrobots.txtの内容を分けて管理しましょう。CIやデプロイツールで環境ごとに自動切り替えする仕組みを導入するのがベストプラクティスです。
ミス2:ワイルドカードUser-agentと個別指定の優先順位を誤解
Before(NG)
# Googlebotにだけ特別な設定をしたいが、書き方が間違っている
User-agent: *
Disallow: /private/
Disallow: /admin/
User-agent: Googlebot
Disallow: /admin/
# /private/ は Googlebot にも適用されると思い込んでいる
After(OK)
# Googlebot用ブロックに必要なDisallowをすべて明記
User-agent: Googlebot
Disallow: /admin/
Disallow: /private/
# その他のクローラー
User-agent: *
Disallow: /private/
Disallow: /admin/
解説:Googlebotは自分専用のUser-agent: Googlebotブロックがある場合、User-agent: *のブロックは完全に無視します。つまり、Before例では、Googlebotには/admin/のみがブロックされ、/private/はブロックされません。Googlebotに適用したいルールはすべてGooglebot専用ブロックに記述する必要があります。
ミス3:Disallowのパス末尾のスラッシュ忘れ
Before(NG)
# /admin ディレクトリをブロックしたいが、末尾にスラッシュがない
User-agent: *
Disallow: /admin
After(OK)
# ディレクトリをブロックする場合は末尾にスラッシュをつける
User-agent: *
Disallow: /admin/
解説:Disallow: /adminは/adminから始まるすべてのURLにマッチします。つまり、/administrator/や/admin-panel/など、意図しないページまでブロックされる可能性があります。一方、Disallow: /admin/は/admin/ディレクトリ配下のみをブロックします。ディレクトリ単位でブロックする場合は、末尾のスラッシュを忘れずにつけましょう。
ミス4:CSSやJavaScriptをブロックしてしまう
Before(NG)
# wp-content全体をブロック → CSSやJSも含めてブロックされる
User-agent: *
Disallow: /wp-content/
After(OK)
# プラグインとキャッシュのみブロックし、テーマとアップロードは許可
User-agent: *
Disallow: /wp-content/plugins/
Disallow: /wp-content/cache/
Allow: /wp-content/themes/
Allow: /wp-content/uploads/
解説:Googleはページをレンダリングしてコンテンツを評価するため、CSSやJavaScriptファイルへのアクセスが必要です。/wp-content/全体をブロックすると、テーマのCSSやJSファイルもクロールできなくなり、Googleがページを正しくレンダリングできず、SEO評価に悪影響を及ぼします。Google Search Consoleの「URL検査」でレンダリング結果を確認し、CSSやJSが正しく読み込まれているか確認しましょう。
ミス5:robots.txtの配置場所が間違っている
Before(NG)
# 以下の場所に配置している場合、クローラーは認識しない
https://example.com/blog/robots.txt
https://example.com/pages/robots.txt
https://www.example.com/Robots.txt ← ファイル名は大文字・小文字を区別する
After(OK)
# 正しくはドメインのルートに配置
https://example.com/robots.txt
解説:robots.txtは必ずドメインのルートディレクトリに配置する必要があります。サブディレクトリに配置してもクローラーは認識しません。また、ファイル名はrobots.txt(すべて小文字)でなければなりません。Robots.txtやROBOTS.TXTは認識されないので注意してください。さらに、サブドメインを使用している場合は、各サブドメインごとにrobots.txtが必要です(blog.example.com/robots.txtとshop.example.com/robots.txtは別のファイルです)。
robots.txtの検証方法
robots.txtを作成・変更したら、必ず検証してから本番環境にデプロイしましょう。ここでは代表的な検証方法を紹介します。
Google Search Consoleでのテスト
Google Search Consoleには、robots.txtの構文を検証する機能があります。以下の手順でテストできます。
- Google Search Consoleにログインし、対象のプロパティを選択します。
- 左メニューの「設定」>「クロール」>「robots.txtレポート」を開きます。
- 現在のrobots.txtの内容が表示されます。構文エラーがあれば警告が表示されます。
- 特定のURLがブロックされているかを確認するには、URL検査ツールで対象URLを入力します。
また、旧来のrobots.txtテスターツールも参考になります。
本番公開前の確認ポイント
robots.txtを本番に反映する前に、以下の点を確認しましょう。
- ブラウザで直接アクセスして確認:デプロイ後に
https://あなたのドメイン/robots.txtにアクセスし、期待した内容が表示されることを確認します。 - 文字コードの確認:robots.txtはUTF-8で保存してください。BOM(Byte Order Mark)は付けないことを推奨します。
- HTTPステータスコードの確認:robots.txtは200(OK)のステータスコードで返される必要があります。404を返す場合、クローラーは「制限なし」と解釈します。5xxエラーの場合、Googleはクロールを一時的に制限する場合があります。
- ファイルサイズの確認:Googleはrobots.txtのうち最大500KiBまでを処理します。ファイルサイズが大きくなりすぎないよう注意してください。
- キャッシュの考慮:Googleはrobots.txtを最大24時間キャッシュします。変更した後、反映までにタイムラグがあることを理解しておきましょう。
- 構文チェック:行頭のスペースや余分な空行が意図しない動作を引き起こすことがあります。各行の先頭にスペースが入っていないか確認しましょう。
以下のコマンドで、ターミナルからrobots.txtのHTTPステータスコードと内容を確認できます。
# robots.txtのHTTPステータスと内容を確認
curl -I https://example.com/robots.txt
curl https://example.com/robots.txt
robots.txtとmeta robotsの使い分け
クローラーの制御方法にはrobots.txtのほかに、HTMLの<meta>タグで指定するmeta robotsがあります。どちらもクローラーの動作を制御しますが、用途と効果が異なります。それぞれの特徴を比較表で整理しました。
| 比較項目 | robots.txt | meta robots |
|---|---|---|
| 設置場所 | ドメインのルートにテキストファイルとして配置 | 各HTMLページの<head>タグ内に記述 |
| 制御対象 | クロール(ページへのアクセス自体) | インデックス登録、リンクの追跡、スニペット表示など |
| 粒度 | ディレクトリ・ファイル単位(パス指定) | ページ単位 |
| noindex | 対応していない(クロールは制御できるが、インデックスの削除は保証されない) | <meta name="robots" content="noindex">でインデックスから除外可能 |
| nofollow | 対応していない | <meta name="robots" content="nofollow">でリンクの追跡を停止可能 |
| 強制力 | あくまで「お願い」。悪意あるボットには無効 | 主要な検索エンジンは遵守。ただし悪意あるボットには無効 |
| SEOへの影響 | クロール効率に影響。PageRankの流れは止められない | インデックスの有無に直接影響 |
| よくある使い分け | 大量の不要URLのクロールを一括ブロック | 個別ページのインデックスを細かく制御 |
使い分けの基本方針
- 「ページをインデックスから外したい」場合:
meta robotsのnoindexを使います。robots.txtでクロールをブロックすると、クローラーがnoindexを読みに行けないため、かえって意図した通りに動かないことがあります。 - 「クロールバジェットを節約したい」場合:robots.txtでディレクトリごとブロックするのが効率的です。大量の不要ページ(パラメータ付きURL、タグページの深い階層など)がある場合に有効です。
- 「画像やPDFなど、HTMLでないファイルを制御したい」場合:meta robotsはHTML内にしか記述できないため、robots.txtを使います。
重要な注意点として、robots.txtでクロールをブロックしているページにmeta robotsでnoindexを指定しても、クローラーがそのページにアクセスできないため、noindexの指示は認識されません。ページをインデックスから確実に除外するには、robots.txtでクロールを許可したうえで、meta robotsでnoindexを指定する必要があります。
robots.txtチェックリスト
robots.txtを作成・更新する際に活用できるチェックリストです。新規作成時だけでなく、定期的な見直し時にも使ってください。
基本設定チェック
- robots.txtがドメインのルートに配置されているか(
https://ドメイン/robots.txtでアクセスできるか) - ファイル名が
robots.txt(すべて小文字)になっているか - 文字コードがUTF-8になっているか(BOMなし推奨)
- HTTPステータスコード200で返されているか
- ファイルサイズが500KiB以下か
構文チェック
- すべてのルールブロックに
User-agentが指定されているか - 各
User-agentブロックに最低1つのDisallow(またはAllow)があるか -
Sitemapの値が完全なURL(https://始まり)で記述されているか - ディレクティブ名のスペルミスがないか(
Useragent→User-agentなど) - 行頭に不要なスペースやタブが入っていないか
- ディレクティブ名の後にコロンとスペースが入っているか(
Disallow: /admin/)
クロール制御チェック
- 本番環境で
Disallow: /(サイト全体ブロック)になっていないか - CSS・JavaScriptファイルがブロックされていないか(レンダリングに支障なし)
- 重要なページ(トップページ、カテゴリページ、主要記事)がブロックされていないか
- 画像ディレクトリのクロールが許可されているか(画像検索対策)
- パラメータ付きURLの重複クロールが制御されているか
- 管理画面・ログインページがブロックされているか
AIクローラー関連チェック
- AIクローラー(GPTBot、PerplexityBot等)への対応方針が決まっているか
- 学習用クローラーとリアルタイム検索用クローラーを区別して制御しているか
- AIクローラーの設定が自社のコンテンツ戦略と整合しているか
運用チェック
- Google Search Consoleで構文エラーがないことを確認したか
- XMLサイトマップのURLが正しく記述されているか
- 開発環境・ステージング環境と本番環境でrobots.txtが適切に切り替わるか
- robots.txtの変更をチーム内で共有・レビューする仕組みがあるか
- 定期的(四半期に1回程度)にrobots.txtを見直す予定があるか
まとめ
robots.txtは、Webサイトのクローラー制御における最も基本的な設定ファイルです。正しく設定することでクロールバジェットを最適化し、SEO効果を最大化できます。本記事の要点を振り返りましょう。
- 基本構文は4つのディレクティブ:
User-agent、Disallow、Allow、Sitemapを正しく使い分けることが基本です。 - テンプレートを活用する:一般サイト、WordPress、Next.jsなど、環境に応じた最適なテンプレートを出発点にしましょう。
- AIクローラーへの対応が必須に:2026年現在、GPTBot、PerplexityBot、ClaudeBotなどのAIクローラーへの対応方針を明確に持つことが重要です。学習用クローラーとリアルタイム検索用クローラーを区別し、自社のコンテンツ戦略に合わせた設定を行いましょう。
- よくあるミスを回避する:サイト全体ブロック、CSS/JSのブロック、パスの記述ミスなど、よくある間違いを事前に把握しておくことで、トラブルを未然に防げます。
- meta robotsとの使い分けを理解する:robots.txtはクロール制御、meta robotsはインデックス制御という役割の違いを理解し、目的に応じて適切に使い分けましょう。
- 検証と定期的な見直しを欠かさない:Google Search Consoleでの検証、チェックリストによる定期見直しを実施し、設定が意図通りに機能しているか確認しましょう。
robots.txtの設定は、テクニカルSEOの中でも最も基礎的かつ重要な施策です。まずは本記事のテンプレートをベースに自サイトのrobots.txtを見直し、チェックリストを使って抜け漏れがないか確認してみてください。
テクニカルSEOの全体像をさらに深く学びたい方は、テクニカルSEOの基本解説や、当サイトのテクニカルSEO教材もあわせてご活用ください。また、AIクローラーへの対応を含むこれからのSEO戦略については、LLMOの解説記事やSEO内部対策ガイドも参考になるでしょう。