robots.txtとサイトマップ

どちらのファイルもクローラーにURLについて何かを伝えますが、一般に思われている働きはしません。一方は取得の許可を与えず、もう一方は検討用の一覧を差し出します。

許可と除外は別のこと

robots.txtが行うのはURLの取得許可を与えないことだけで、それ以上ではありません。Googleは、これがページを検索結果から締め出す仕組みではないと明言しています。この二つはたえず混同され、その混同がはっきりと目に見える特定の失敗を生みます。

他サイトからリンクされているブロック済みURLは、それでも索引に載ることがあります。誰かがリンクしているのでGoogleはそのアドレスの存在を知っていますが、中身を見ることができません。そのため説明文がまったくない状態で掲載されうるのです。ページは検索結果に公開されているのに、その見え方をこちらが制御できない——両方の悪いところが揃った状態です。

ファイルの読み方と書き方

このファイルはホストのルートに置かれ、そのホストとプロトコルにのみ適用されます。ルールはユーザーエージェントごとにグループ化され、クローラーは自分に最も適合する一つのグループだけに従います。適合しうるすべてのグループではありません。グループ内での競合は、記述順ではなくより具体的なルールによってGoogleが解決します。

robots.txt

User-agent: *
Disallow: /admin/
Disallow: /*.pdf$
Allow: /admin/public/

User-agent: Googlebot
Disallow: /drafts/

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

この例の二点が混乱のほとんどを占めます。Allow行は上のDisallowより具体的なので、/admin/public/は取得可能なままです。そしてGooglebot用のグループが存在した時点で、Googlebotはそのグループだけに従います。ワイルドカードのグループはもう適用されないため、ここでは/admin/がGooglebotから取得可能になります。書き手の意図とはまず一致しません。

パスをブロックしても、すでに索引にあるURLは消えません。今後の取得が止まるだけです。
Sitemap行はどのユーザーエージェント・グループにも属さず、ファイル内のどこに置いても構いません。
robots.txt自体が5xxを返すと、クローラーがホスト全体への取得を控えることがあります。信頼できる場所から配信してください。

robots規則が遠く離れた場所で害をなすとき

最も高くつくrobots.txtの誤りは、ブロックするつもりだったページではありません。ページがレンダリングに必要とするリソースです。検索エンジンはインデックス登録の前にページをレンダリングし、その過程でスクリプト、スタイル、APIの応答を読み込みます。

スクリプトのパスやAPIのルートをブロックしても、クローラーはHTMLを問題なく取得します。そのうえでほぼ空のページをレンダリングし、ほぼ空のページを索引に登録します。どのレポートにもページがブロックされたとは出ません。ブロックされたのはページではなく、ページが必要としていたものだからです。

サイトマップは提案であって順番待ちではない

サイトマップは、リンクが最も弱いところでこそ発見を助けます。大規模サイト、被リンクの少ない開設直後のサイト、自然なリンクテキストを持たないメディア中心のサイトです。Googleは、URLを載せてもクロールもインデックス登録も保証しないと明言しています。

Google自身の案内では、小規模で内部リンクの整ったサイトはそもそも不要かもしれないとされています。クローラーがリンクをたどってすべて見つけられるからです。内部リンクのほうがうまく解ける問題のためにサイトマップの仕組みを作り込む前に、この点は真剣に受け止める価値があります。

上限	値
1ファイルあたりのURL数	5万
1ファイルの非圧縮サイズ	50MB
いずれかを超える場合	分割し、サイトマップインデックスから各ファイルを参照する

読まれるタグ、無視されるタグ、疑われるタグ

サイトマップの労力が最も無駄になるのがここです。よく使われる四つのタグのうち二つはまったく何もせず、三つ目はこちらに不利にはたらくことがあります。

タグ	Googleの扱い
loc	読む——URLそのもの
lastmod	一貫して検証可能に正しい場合にのみ使う
changefreq	無視する
priority	無視する

痛いのはlastmodに付いた条件です。ビルドがすべてのURLにデプロイ時刻を押していると、どの値も同時に誤りであり、しかも容易に反証できます。ページは変わっていないのに変わったと言っており、検索エンジンにはそれが分かるからです。フィールドを信用しなくなれば使わなくなり、結果としてlastmodを送らない場合より不利になります。本文の実際の変更のときだけ出力し、でっち上げるくらいなら省いてください。

sitemap.xml

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/guides/indexing/</loc>
    <lastmod>2026-06-14</lastmod>
  </url>
</urlset>

正しい道具を選ぶ

この領域のほとんどの疑問は、似て見えて実際には別物の三つの仕事を切り分けた時点で解けます。

目的	道具	理由
不要なURLにクロールを費やさない	robots.txt	取得そのものを止められる
ページを検索結果から外す	noindex、または認証	指示を読ませるために取得が要る
ページを見つけてもらう	内部リンク、その次にサイトマップ	リンクは文脈を運ぶが、サイトマップの項目は運ばない

自分のサイトで試す

よくある質問

disallowとnoindexは併用できますか。

いいえ。その組み合わせこそ典型的な誤りです。robots.txtでURLを止めると、クローラーはページを取得せずnoindexも見ません。クロールを許可したうえでnoindexを返すか、認証の内側に置いてください。

そもそもサイトマップは必要ですか。

常に必要とは限りません。Googleは、小規模で内部リンクの整ったサイトはリンクをたどって発見できるとしています。大規模サイト、被リンクの少ない開設直後、メディアが多い場合に価値が出ます。

ブロックしたページがGoogleに出続けるのはなぜですか。

robots.txtが止めたのは取得であって、インデックス登録ではないからです。他サイトがそのURLにリンクしているためGoogleは存在を知っていますが中身は見えず、説明文なしの掲載になります。クロールを許可してnoindexを返せば正しく削除できます。

priorityとchangefreqは設定すべきですか。

いいえ。Googleはどちらも無視します。その手間はlastmodを正確に保つことか、内部リンクに向けたほうが報われます。

robots.txtがエラーを返すとどうなりますか。

5xxの場合、すべて許可とみなさずホストへの取得を控えることがあります。robots.txtは、サイト本体と同等以上に信頼できる基盤から配信してください。

続けて読むページがインデックスされない理由続けて読む内部リンク