Sitemap vs robots.txt

Scrapeless Crawl は、sitemap または他の定義されたソースから発見できる URL からページコンテンツを収集します。

各ファイルは何をするのか？

Sitemap vs robots.txt は、ディスカバリーフォーマットとクロールポリシーファイルを比較します。sitemap は、パブリッシャーがクローラーに発見してほしい URL を特定します。robots.txt ファイルは、準拠する自動クライアントがどのパスをリクエストすべきかに関するルールを伝えます。

この 2 つのファイルは連携して動作できます。robots.txt ファイルは sitemap の場所を告知でき、一方 sitemap はリンクだけでは発見しにくいページを特定できます。どちらのファイルも、ページレスポンスや、その後の検索エンジンの処理の代わりにはなりません。

この Sitemaps XML プロトコル は URL リスト形式と sitemap インデックスを定義します。 Robots Exclusion Protocol はクロールルールの動作を定義します。どちらがより強力な SEO ファイルかという順位付けではなく、異なる責任範囲として理解してください。

Sitemap は選択を強制せずにディスカバリーを助ける

sitemap は、パブリッシャーが提供する候補 URL の在庫一覧をクローラーに与えます。これは、新しいページ、大規模なコレクション、内部リンクが限られたリソースに有用です。クローラーは、サイト上のすべてのインターフェースをたどらなくても、このリストを使ってキューを初期化できます。

リストはサイトの意図された公開在庫を反映すべきです。リダイレクト、削除済みページ、重複バリアント、あるいは同じサイトがクロールをブロックしている URL を含む sitemap は、不要な作業と混乱したシグナルを生みます。sitemap 生成は、カノニカル URL ポリシーと結びついた公開業務として扱ってください。

sitemap インデックスを使うと、パブリッシャーは複数の sitemap ファイルを整理できます。収集側は、インデックスと通常の URL セットを区別し、適切なエントリを処理しなければなりません。不正な参照によって無限ループが発生しないよう、すでに訪問した sitemap の場所を追跡してください。

更新情報が提供される場合は、意味のあるソース変更を表すべきです。単にスケジュールジョブが内容の同じファイルを再生成したからといって、更新日時だけを進めるべきではありません。どのリソースを優先し検証するかは、あくまで消費側が決定します。

robots.txt は特定のクライアントとパスにルールを適用する

robots.txt は、自動クライアントの識別子ごとにルールをグループ化し、リソースリクエストにパスマッチングを適用します。これは対象オリジンのルートパスに配置する必要があり、そのスコープはクロール対象のホストとスキームに対して評価しなければなりません。1 つのオリジン上のファイルが、すべてのサブドメインに対するポリシーを定義していると想定してはいけません。

パスパターンには慎重なテストが必要です。広すぎるルールは有用なセクションまで意図せず含めてしまう一方で、狭すぎるルールはバリエーションを見落とす可能性があります。該当するルート群から代表的なURLをテストし、テキストを目視だけで確認するのは避けてください。

ルールは、どのユーザーエージェントグループが適用されるかにも依存します。汎用グループと名前付きグループでは、クライアントごとに異なる結果を生むことがあります。ファイルを単純な部分文字列のブラックリストとして扱うのではなく、意図されたプロトコル動作を実装したパーサーを使用してください。

アプリケーションの認可は分離して管理してください。robots のルールは自動クライアント向けの公開された読み取り可能な指示です。機密文書には認証とアクセス制御が必要であり、robots.txt に機密パス名を書いてしまうと、保護にならないどころかその場所を明かしてしまうことがあります。

クロールブロックとインデックス削除は別物

クロールをブロックしても、そのURLを検索結果から確実に削除できるわけではありません。検索エンジンは、ページを取得できない場合でも、他のシグナルからそのURLの存在を知り得ます。「 Google robots.txt limitations 」は、クロール除外とインデックス制御を別々に検討すべき理由を説明しています。

ページ上のインデックス制御指示は、クローラーに取得されて初めて処理されます。もしクローラーがそのページの取得を禁止されていると、そこに置いた指示が一度も見られない可能性があります。コントロールを選ぶ前に、目的がクロール頻度の低減なのか、コンテンツのインデックス削除なのか、あるいはアクセス保護なのかを明確にしてください。

サイトマップは、disallow ルールを上書きするものではありません。ブロックされたURLを列挙しても、準拠クライアントに取得権限を与えることにはなりません。同様に、URLをサイトマップから削除しても、それが発見不可能・削除済みであることを意味しません。リンクや過去の観測から依然として露出し得ます。

インシデント対応では、望ましい結果とファイル編集を分けて考えます。サイトマップ項目の削除、robots ルールの変更、サーバー側のアクセス制限、インデックス削除リクエストは、それぞれ異なるアクションです。編集だけで完了と見なすのではなく、適切な検証を通じて結果の状態を確認してください。

実サイトに対してファイルを監査する

有用な監査とは、公開されているURLやクロールルールを実際のレスポンスと比較することです。ファイルの存在確認は出発点にすぎません。監査では、別の正規URLにリダイレクトされるサイトマップ上のURLや、広すぎるルールによって除外されてしまっている想定のランディングページなどの矛盾を明らかにする必要があります。

1. 関連するオリジンを特定し、それぞれの robots ファイルを取得します。
2. 宣言されたソースや配信システムからサイトマップの場所を特定します。
3. URL集合やインデックスを、再帰の深さを制限しながらパースします。
4. 選択した各ページを、適用されるクロールルールに照らして評価します。
5. レスポンスステータス、最終的なURL、そして正規化の意図を確認します。
6. 除外・失敗・検証済みコンテンツを分けて記録します。

意味のある違いを正規化で消さないでください。末尾のスラッシュ、言語プレフィックス、クエリパラメータは、そのサイトのURLポリシーの一部である場合があります。監査でどのようにレコードをグルーピングしたかをレビュアーが理解できるよう、正規化されたIDと並行して元のURLを保持してください。

簡潔な照合作業では、URLが「列挙されたか」「許可されたか」「要求されたか」「リダイレクトされたか」「受理されたか」を示すことができます。これらは別々の事実です。意図的に除外されたページを取得失敗として数えるべきではなく、正常に取得できたページを、検索エンジンの証拠なしにインデックス済みと呼ぶべきでもありません。

サイトマップからコンテンツ収集へ

ポリシーとURLチェックの後、サイトマップはコンテンツパイプラインの種になります。受け入れられたURL集合を収集レイヤーに渡し、返ってきたコンテンツが意図した目的に合致しているか検証します。発見されたURLのリストは、まだ完成した文書コーパスではありません。

Scrapeless Crawl は、そのワークフロー向けにページコンテンツ収集を提供できます。自分の記録には、元のサイトマップ位置、要求したURL、最終URL、観測コンテキストを保持してください。これらのフィールドは、なぜその文書が存在し、どのソースエントリから生成されたのかを説明するのに役立ちます。

「 sitemap-driven collection overview 」は、発見からコンテンツへの引き継ぎを詳しく解説しています。スコープ外および重複作業を除外した後に Scrapeless pricing でコストを見積もり、未フィルタのURL数をベースに予算を立てるのは避けてください。

後で比較できるよう、発見入力を保持しておいてください。もし次のサイトマップから文書が消えた場合、それが意図的な非公開化なのか、別の正規URLへ移動したのか、あるいは配信エラーによる脱落なのかを判断する必要があります。現在のファイルからの不在だけでは、これらの結果を区別できません。

矛盾する公開シグナルを解消する

サイトマップ監査では、矛盾するシグナルを個々の具体例で説明するべきです。たとえば、想定されるランディングページがサイトマップには載っているのに、広範な disallow ルールの対象になっているケースを考えてみます。準拠するクローラーは、そのURLを発見できても取得はできません。このページをサイトマップから削除すれば、そのインベントリからは矛盾が見えなくなりますが、望ましいクロール動作を確立したことにはなりません。

サイト所有者と公開の意図を確認し、そのうえで該当するルールか、公開インベントリのどちらかを修正してください。もし列挙されたページが別のページにリダイレクトされるのであれば、移行を確認したうえで、サイトマップを意図された正規宛先に合わせてください。レポートでなぜURLが変わったのか説明できるよう、元の観測結果も保持しておきます。

デプロイ後に、実際のファイルとページレスポンスを再確認してください。ソーステンプレートが正しくても、ビルドやキャッシュが更新されていなければ、公開物は古いままの可能性があります。完成した監査は、観測されたWebサイトの状態を記述し、未解決の公開ギャップは提案中の修正とは切り離して扱うべきです。

結論

サイトマップはリソースの発見を助け、robots.txt はクロールルールを伝えます。実際のページ在庫と整合する形で両方を利用し、クロールとインデックス、アクセス保護を分けて考えてください。意図した変更が効くべきレイヤーで結果を検証しましょう。