サイトマップは必要か・robots.txtの書き方、個人ブログはほぼ不要

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

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

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

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

サイトマップとは、サイトにあるページ・動画・その他のファイルの情報と、それらの関係を伝えるファイルです。Googleの公式ドキュメントはこの説明のあとに「検索エンジンはこのファイルを読んで、サイトをより効率的にクロールします」と続けています。

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

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

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

個人ブログでほぼ要らないのは、既定値がそうなっているから

公式のサイトマップの解説には、「サイトマップが必要ない場合」として3つが挙がっています。

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

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

ただし公式は、そのすぐ後に「ほとんどの場合、サイトマップがあるとサイトにとって有益です」とも書いています。この記事の結論も「あっても害は無いが、無くても回る」という位置づけで、外しに行く必要はありません。

そして多くの人は、すでに置いています。公式は「WordPress、Wix、BloggerなどのCMSを使用している場合は、CMSがすでにサイトマップを検索エンジンに提供している可能性が高く、何もする必要はありません」と書いています。「サイトマップを作らなければ」と焦る前に、まず自分のサイトの /sitemap.xml をブラウザで開いてみてください。

原文は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 がページに再度アクセスするのが数か月後になる場合があります」ともあるので、外した翌日に消えるとは限りません。

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

原文はGoogle公式「noindexで検索インデックス登録をブロックする」です。

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

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

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

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

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

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

公式は「サイトマップの送信はあくまでヒントであり、Googleがサイトマップをダウンロードすることや、URLのクロールにサイトマップを使用することを保証するものではありません」とも書いています。

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

外部から送る仕組みは、ひとつ無くなりました。2023年6月26日の公式ブログで、認証なしでサイトマップを送るping用のエンドポイントの廃止が告知され、同じページの冒頭に廃止完了が追記されています。「既存のコードやプラグインが問題を起こすことはないが、このエンドポイントを使っても有用なことは何も起きない」とも書かれています。

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

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

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

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

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

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

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

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

User-agent: *
Allow: /

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

公式は同じ形の例に「他のすべてのユーザーエージェントはサイト全体をクロールできます。この記述は省略しても結果は同じです」と注記しています。つまり実質的な中身はSitemapの1行だけで、これは「サイトマップの場所を伝えるためのファイル」になります。

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

• ファイル名はrobots.txt。サイトに置けるのは1つだけ
• サイトのホストのルートに置く。サブディレクトリ(例: /pages/robots.txt)には置けません
• UTF-8のテキストファイルで保存する。ワープロは使わない(全角の引用符などが混ざり、ルールが無効になることがあります)
• 効く範囲はプロトコル・ホスト・ポート単位。example.comのrobots.txtは、m.example.comには効きません
• ルールは大文字と小文字を区別する。公式の例では、disallow: /file.asp は /FILE.asp には適用されません
• Sitemap行は完全な絶対URLで書く。公式は「Googleは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を除く)を返す場合「有効なrobots.txtファイルが存在しないものとして扱う」「クロールの制限が無いものとみなす」と書かれています。全ページをクロールされて構わないサイトなら、この状態で困りません。注意したいのは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つだけ置き、送信の操作は要りません

ここから先は、私が作ったツールの話です。

Search Consoleの「ページ」CSVをZIPのまま入れると、掲載順位4.0〜20.5位・表示回数100回以上のページだけを拾い、改善余地スコア(表示回数 × 順位別の平均CTRとの差)の大きい順に並べるツールを作りました。解凍もファイル選びも要りません。判定と候補3記事の改善余地スコアの確認、そのうち1記事分の診断カードまでは無料で、残りの診断カードが2,980円(税込)の買い切りです。月額課金や自動更新はありません。ログインも不要です。CSVファイルそのものはブラウザの外に出ません(診断カードを出すときに選んだ1ページのURL・数値・入力したキーワードを、「ページタイトルを取得する」を押したときに判定に出たページのURLを最大10件送ります)。

⚠️ ただし、この記事の話題そのものは、このツールでは扱えません。「ページ」CSVには検索結果に表示されたページしか入っていないので、インデックスされていないページも、robots.txtでブロックしているページも、そもそもデータに出てきません。サイトマップやrobots.txtの状態を診断する機能もありません。表示回数が2桁で止まっている段階のブログにも向きません。