サイトマップは必要か・robots.txtの書き方、個人ブログは無くても困りにくい

先に結論を書きます。記事が数十本の個人ブログなら、サイトマップもrobots.txtも、置かないままで困らないことが多いです。CMSが自動で用意している場合は、それも触らなくて大丈夫です。

むしろ手を入れて壊れるのは、robots.txtでブロックしたページにnoindexを入れたときです。この2つは同時にかけると打ち消し合います。

以下、公式ドキュメントの原文と突き合わせながら、なぜそうなるのかを書きます。

サイトマップとrobots.txtは、それぞれ何をするファイルか

サイトマップとは、サイトにあるページ・動画・その他のファイルの情報と、それらの関係を伝えるファイルです。Googleの公式ドキュメントはこの説明のあとに「Google などの検索エンジンは、このファイルを読み込んで、より効率的にクロールを行います。」と続けています。同じ「サイトマップ」という名前でも、記事へのリンクを読者向けに並べた一覧ページ(HTMLサイトマップ)は、このファイルとは別物です。違いと、一覧ページが要るかの決め方はHTMLサイトマップは必要？XMLサイトマップとの違いと、作るかの決め方にまとめました。

robots.txtとは、サイトのどのURLにクローラーがアクセスしてよいかを伝えるファイルです。公式の冒頭には、これは主にサイトへのリクエスト過多を避けるためのもので、「Google にウェブページが表示されないようにするためのメカニズムではありません」と書かれています。

2つは、伝えられることが違います。

右端の列が、この記事の後半につながります。どちらも「検索結果に出す・出さない」を決めるファイルではありません。

同じくサイトのルートに置くファイルとして、AI向けの llms.txt を見かけることもあります。llms.txt が Google 検索では使われないことと、個人ブログで置くかどうかの決め方はllms.txtは必要？に書きました。AIのクローラーをrobots.txtで止めたいときの書き方と、Googlebotを巻き込まないための注意はAIクローラーはrobots.txtで拒否できる？止め方と検索への影響に書きました。

個人ブログで無くても困りにくいのは、既定値がそうなっているから

公式のサイトマップの解説は、「次の場合は、サイトマップが必要ない可能性があります。」として3つを挙げています。言い切りではなく「可能性」です。

• サイトが「小さい」。「小さい」とはおよそ500ページ以下を指し、検索結果に表示させたいページだけを数える、と注記されています
• 内部リンクで網羅されている。ホームページからリンクをたどって重要なページに全部たどり着ける状態です
• 検索結果に出したい動画・画像・ニュース記事が多くない

記事80本のブログは1つ目に収まり、記事一覧やカテゴリから全記事に行けるなら2つ目にも収まります。同じページには「サイトの各ページが適切にリンクされていれば、Google は通常、サイトのほとんどのページを検出できます。」とも書かれています。

ただしこのページは、3つの条件より前に「それでもほとんどの場合、サイトマップを提供することで有益な結果が得られます。」とも書いています。この記事の結論も「あっても害は無いが、無くても回る」という位置づけで、外しに行く必要はありません。

そして多くの人は、すでに置いています。公式は「WordPress、Wix、Blogger などの CMS を使用している場合は、CMS によって検索エンジンが利用できるサイトマップがすでに用意されていることが多く、その場合は何もする必要はありません。」と書いています。「サイトマップを作らなければ」と焦る前に、まず自分のサイトの /sitemap.xml をブラウザで開いてみてください。WordPressでは本体と Yoast SEO でサイトマップのURLが違うので、開く場所と、サイトマップが2系統できていないかの見方はWordPressのSEOプラグインは必要？に書きました。

Wixで、SEO チェックリストからサーチコンソールに接続するとサイトマップが自動で Google に送られる点を含め、検索に出ないときの確かめ方はWixはSEOに弱い？検索に出ない原因と、検索避けの設定の場所に書きました。

原文はGoogle公式「サイトマップについて」にあります。「必要になることがある」場合の条件も、同じページに3つ挙がっています。

robots.txt側はもっと単純です。公式の書き方ガイドには「robots.txt ファイルで特に指定しない限り、ファイルはすべて暗黙的にクロールが許可されます。」とあります。ファイルが無い状態と、「全部クロールしてよい」と書いた状態は、結果が同じです。

仕様書のほうには、もう一段はっきりした記述があります。robots.txtが4xx(429を除く)を返す場合、「Google のクローラーは有効な robots.txt ファイルが存在しないものとみなします。つまり、Google はクロールの制限はないものとみなします。」と書かれています。robots.txtが404で返ることは、事故ではありません。

注意すべきなのは、むしろ5xx(サーバーエラー)のほうです。置くかどうかより、置いたときにサーバーエラーを返さないことのほうが影響が大きいという話は、下のよくある質問に書きました。

robots.txtでブロックすると、noindexが読まれない

ここが、この2つのファイルで最も多い事故です。検索結果から消したいページにnoindexを入れ、同時にrobots.txtでそのURLをブロックすると、noindexは効きません。

公式のnoindexの解説には、「重要」の枠でこう書かれています。

noindex ディレクティブを有効にするためには、robots.txt ファイルでページやリソースをブロックせず、クローラがページにアクセスできるようにする必要があります。robots.txt ファイルでページがブロックされている場合、またはクローラがページにアクセスできない場合、クローラは noindex ルールを認識しません。そのため、たとえばそのページが他のページからリンクされていれば、検索結果に引き続き表示される可能性があります。

構造はこうです。noindexはページの中(metaタグ)かHTTPヘッダーに書かれています。robots.txtはページを取りに行くこと自体を止めます。取りに行かなければ中身は読めないので、中に書いた「載せないでほしい」も読まれません。

実際には、この順で進みます。

1. robots.txtで対象のURLをブロックする
2. Googleはそのページを取得しなくなる
3. ページの中に入れたnoindexは、読まれないまま残る
4. 他のサイトや自サイトからのリンク経由で、URLだけが検索結果に残り続ける

厄介なのは、画面上は「消えていない」としか見えないことです。原因がrobots.txt側にあると気づきにくい。公式のデバッグの節にも「robots.txt ファイルがこの URL を Google ウェブ クローラーからブロックしているため、タグを認識できない、という理由も考えられます。」と挙がっています。

直す順序はブロックを外す → クロールされる → noindexが読まれる → 消えるです。ただし同じ節に「インターネット上でのページの重要性によっては、Googlebot がページに再度アクセスするのが数か月後になる場合があります。」ともあるので、外した翌日に消えるとは限りません。

もうひとつ、公式のnoindexの解説には「robots.txt ファイルで noindex ルールを指定することは、Google ではサポートされていません。」と書かれています。「robots.txtにnoindexと書けばいい」という解説を見かけたら、この一行と突き合わせてください。

原文はGoogle公式「noindex を使用してコンテンツをインデックスから除外する」です。

目的別に整理すると、使う道具は分かれます。

同じ内容が複数のURLから見える、という話は別の手になります。noindexとcanonicalの使い分けはcanonicalタグの使い方に書きました。

やりがちで、効かないこと2つ

サイトマップを何度も送り直す

Search Consoleのヘルプには、正常にクロールされたサイトマップについて「Google は、通常のサイトのクロールとは関係のないペースで、サイトマップを定期的に再クロールします。」と書かれています。

続けて「サイトマップを大幅に変更する場合は、新しいリクエストでサイトマップを再送信することをおすすめします。それ以外の場合は、サイトマップに直ちに処理する必要がある重要な更新がない限り、Google の通常のクロール スケジュールに任せてください。」とあります。再送信が勧められているのは、サイトマップを大幅に変更する場合と、取得に失敗して問題を修正した場合で、登録や順位を促すためではありません。

サイトマップの作り方の公式ガイドも「サイトマップを送信することは、Google にサイトマップの存在を知らせるだけにすぎません。Google がサイトマップをダウンロードする保証も、サイトマップを使用してサイトの URL をクロールする保証もありません。」と書いています。

送信したときに「失敗しました: robots.txt にアクセスできません」と出ることがあります。robots.txtの中身を書き換えても直らない種類のエラーで、原因と直す順番は サイトマップの「robots.txt にアクセスできません」はサーバー側の問題ですにまとめました。

サイトマップを送信する手順と、「成功」「取得できませんでした」「エラーがあります」などのステータスごとの次の一手はサーチコンソールのサイトマップ登録は？ステータス別の次の一手にあります。

外部から送る仕組みは、ひとつ無くなりました。2023年6月26日の公式ブログで、認証なしでサイトマップを送るping用のエンドポイントの廃止が告知され、同じページの冒頭に廃止完了が追記されています。「このエンドポイントを使用する既存のコードやプラグインが Google 検索に問題を引き起こすことはないため、変更を加える必要はありません（ただ、このエンドポイントを使用しても、なにかに役立つことはありません）。」とも書かれています。

同じ記事の後半は、lastmod の使い方と、Googleが priority・changefreq を使っていないことに触れています。サイトマップの中に書くタグの扱いはサイトマップのlastmod・priority・changefreqは必要？にまとめました。

robots.txtでクロールを絞って「クロールバジェットを節約する」

クロールバジェットを扱う公式ガイドは、冒頭で読者を限定しています。挙がっているのは「大規模（重複のないページが 100 万以上）で、コンテンツが中程度に（1 週間に 1 回）更新されるサイト」「中規模以上（重複のないページが 1 万以上）で、コンテンツがかなり頻繁に（毎日）更新されるサイト」「Search Console で URL の大部分が検出- インデックス未登録に分類されるサイト」の3つです。

そのうえで「サイト内で頻繁に更新されるページがそれほど多くない場合や、ページが公開日と同じ日にクロールされると考えられる場合は、このガイドを読む必要はありません。」と書かれています。ここで条件になっているのは規模ではなく、更新の頻度と、公開日と同じ日にクロールされているかどうかです。3つ目の対象読者も規模では書かれていないので、ページ数だけを見て対象外と決めないでください。

節約のつもりでDisallowを増やすと、得られるものよりも失うもののほうが確実です。ブロックしたページのnoindexは読まれなくなり、そのページに置いた内部リンクもたどられなくなります。

クロールの様子をサイト全体で確かめたいときの画面は「クロールの統計情報」は何を見る画面？個人ブログが見る価値があるのはほぼ2つで、個人ブログで見る価値のある場所に絞って書きました。

なお、インデックスされない原因はこれ以外にもあり、robots.txtはそのうちの1つにすぎません。原因の一覧と切り分ける順番はインデックスされない原因は2系統に分かれるにまとめてあります。

それでもrobots.txtを書くなら、最小の形はこれだけ

書くと決めたときの手順は、公式では4つです。ファイルを作る → ルールを書く → サイトのルートにアップロードする → テストする。

個人ブログで置くなら、中身はこれで足ります。

User-agent: *
Allow: /

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

公式の例にも同じ User-agent: * / Allow: / の2行があり、その説明に「他のすべてのユーザー エージェントには、サイト全体のクロールを許可しています。このルールは記載していなくても同じ結果になります。」と注記されています。つまり実質的な中身はSitemapの1行だけで、これは「サイトマップの場所を伝えるためのファイル」になります。

書式で外すと、ファイルごと効かなくなります。公式に並んでいる条件は次のとおりです。

• ファイル名はrobots.txt。サイトに置けるのは1つだけ
• サイトのホストのルートに置く。サブディレクトリ(例: /pages/robots.txt)には置けません
• UTF-8のテキストファイルで保存する。ワープロは使わない(全角の引用符などが混ざり、ルールが無効になることがあります)
• 効く範囲はプロトコル・ホスト・ポート単位。example.comのrobots.txtは、m.example.comには効きません
• ルールは大文字と小文字を区別する。公式の例では、disallow: /file.asp は /FILE.asp には適用されません
• Sitemap行は完全修飾URL(httpsから始まる完全なURL)で書く。公式は「Google は代替 URL（http か https か、www があるかないか）を考慮またはチェックしません。」と書いています

送信は要りません。公式は「robots.txt ファイルをアップロードしてテストしたら、その後は Google のクローラーが自動的に検出して使用を開始します。何もする必要はありません。」と書いています。キャッシュの更新を急ぎたいときだけ、Search Consoleのrobots.txtレポートを使います。

書式の全文はGoogle公式「robots.txt の書き方、設定と送信」にあります。置いたあとに個別のURLがどう扱われているかを見たいなら、URL検査で1本ずつ確かめるのが早いです。手順はサーチコンソールでインデックスを確認する方法に書きました。

よくある質問

サイトマップは何ページから必要になりますか

公式が数字で挙げているのは「必要ない可能性がある」場合の側の目安で、およそ500ページ以下です。このページには「500ページを超えたら必須」とは書かれていません。「必要になることがある」場合の条件として挙がっているのは「サイトのサイズが大きい」「サイトが新しく、外部からのリンクが少ない」「サイトに動画や画像などのリッチメディア コンテンツが多数含まれている、またはサイトが Google ニュースに表示されている」の3つです。ページ数より、内部リンクをたどって全記事にたどり着けるかのほうが実質的な判断材料になります。立ち上げたばかりのブログは、ページ数が少なくても2つ目の条件に当たります。

robots.txtで消したはずのページが、検索結果に残っています

robots.txtは、検索結果から消すためのファイルではありません。公式は「説明テキストの付いたページが他のページから参照されている場合、Google は、クロールせずに URL をインデックスに登録することがあります。」と書き、robots.txtでブロックされたページについて「検索結果にその URL が表示されることはありますが、説明は表示されません。」と説明しています。消したいときはrobots.txtのブロックを外してからnoindexを入れる順序になります。ブロックしたままnoindexを足しても、クローラーはそのnoindexを読めません。

サイトマップを送ったのに、インデックスされません

サイトマップの役目は、URLの存在を知らせるところまでです。公式は「サイトマップによって、サイト上の URL を検索エンジンが検出できますが、必ずしもサイトマップ内のすべての項目がクロールされてインデックスに登録されることが保証されるわけではありません。」と書いています。送信回数を増やしても、渡せる情報は増えません。原因の切り分けはインデックスされない原因は2系統に分かれるにまとめてあります。

robots.txtが無いままで、まずくないですか

Googleの仕様書には、robots.txtが4xx(429を除く)を返す場合「Google のクローラーは有効な robots.txt ファイルが存在しないものとみなします。つまり、Google はクロールの制限はないものとみなします。」と書かれています。全ページをクロールされて構わないサイトなら、この状態で困りません。注意したいのは5xx(サーバーエラー)のほうです。同じ節に「最初の 12 時間はサイトのクロールを停止しますが、robots.txt ファイルについては引き続き取得を試みます。」とあります。置かないのと置いたがサーバーエラーを返すのは、扱いがまったく違います。

まとめ

• サイトマップとは、サイトのページ・動画などの情報とその関係を伝えるファイル。robots.txtとは、どのURLをクロールしてよいかを伝えるファイル。どちらも「検索結果に出す・出さない」を決めるファイルではありません
• 公式がサイトマップが「必要ない可能性がある」場合に挙げているのはおよそ500ページ以下・内部リンクで網羅・メディアやニュースが多くない。個人ブログの多くはここに収まります(ただし「それでもほとんどの場合、サイトマップを提供することで有益な結果が得られます。」とも書かれています)
• robots.txtは無い(4xxで返る)ならクロール制限なしとして扱われる。置くかどうかより、置いたときに5xxを返さないことのほうが影響が大きい
• robots.txtでブロックしたページのnoindexは読まれません。消したいなら、ブロックを外してからnoindexを入れる順序になります
• 再送信とクロール節約は効きません。公式が再送信を勧めているのはサイトマップを大幅に変更する場合(と取得エラーを直したとき)で、クロールバジェットのガイドは100万ページ規模を想定しています(例外は、URLの大部分が「検出 - インデックス未登録」の場合)
• 書くなら最小構成はUser-agent: * / Allow: / / Sitemap:(絶対URL)。サイトのルートにUTF-8で1つだけ置き、送信の操作は要りません

ここから先は、私が作ったツールの話です。サイトマップとrobots.txtを片付けたら、リライトレーダーに記事のURLを入れて、本文の直す点を見てください。Search Consoleのデータを入れると、どの記事から直すかの順番まで出ます。

URLの診断で送るのは入れたURLだけで、本文は保存しません。Search Consoleの「ページ」タブのエクスポートをZIPのまま置くと、掲載順位4.0〜20.5位のページから手を入れる候補を順に並べます。判定と、そのうち1記事分の診断カードまでは無料です。有料は2,980円(税込)の買い切りで3記事分(候補が4件以上のときだけご案内)、生成の期限は購入から90日間で、月額課金はありません。CSVはブラウザの中で読み、送るのは候補ページのURLと、診断カードを出すときの狙いキーワード・順位・表示回数・CTRだけです。

⚠️ URLの診断は本文だけを読み、順位・表示回数・CTRは使いません(それらを使うのはSearch Consoleのデータを入れたときです)。サイトマップやrobots.txtの状態を診断する機能はありません。