差分クロール設計入門：sitemapのlastmodで取得候補を絞る

定期クロールが遅くなったとき、すぐ並列数やプロキシを増やすとは限りません。まず検討したいのは、前回から更新された可能性があるURLだけを取得候補にする設計です。候補抽出にはsitemapのlastmodを利用できますが、欠落や不正確な値を前提にしたフォールバックが必要です。

lastmodは「取得対象を絞る手掛かり」

URLごとのlastmodは任意タグで、W3C Datetime形式またはYYYY-MM-DDで記述できます。仕様ではページが最後に更新された日付を入れるものですが、必須要素はurlset、url、locだけであり、lastmodのないサイトマップも仕様に適合します。任意タグへの対応も検索エンジンごとに異なり得ます。

したがって、実装では前回確認したlastmodをURL単位で保存し、値が新しくなったURLを取得候補にします。初出URL、lastmodがないURL、値を解釈できないURLは別キューに入れ、低頻度の再確認対象とするのが現実的です。これは仕様から導く設計案であり、更新検知を保証するものではありません。

changefreqだけで取得間隔を決めるのは避けるべきです。これは命令ではなくヒントで、記載された頻度どおりにクロールされる保証はありません。`hourly`より低頻度、`yearly`より高頻度になる場合も仕様で想定されています。

大規模サイトではサイトマップ自体も差分取得する

サイトマップインデックスのlastmodは、配下ページではなく各サイトマップファイルの更新時刻を表します。この値を使い、指定日以降に更新されたサイトマップだけを取得する方法は「incremental Sitemap fetching mechanism」として示されています。

設計は次の二段階です。

インデックスで更新されたサイトマップだけを選ぶ
選んだサイトマップ内で、URLごとのlastmodを前回値と比較する

1ファイルに収録できるのは5万URL以下かつ50MB以下で、超える場合は分割してインデックスに列挙します。gzip転送も可能ですが、展開後のサイズは50MB以下という制約があります。巨大ファイルを毎回処理しないことは、通信量だけでなく解析処理の削減にもつながります。

robots.txtを取得処理の前段に置く

サイトマップのURLは、robots.txt内の独立したSitemap:行から見つけられ、複数行も記載できます。この指定はuser-agentグループの外に置けます。一方、robots.txt自体は定期的な再確認が必要です。クローラーは標準的なキャッシュ制御を利用できますが、到達不能時を除き、キャッシュを24時間超使うべきではないとRFC 9309に定められています。

サーバーエラーやネットワークエラーでrobots.txtへ到達できない場合、クローラーは全面的なdisallowを仮定しなければなりません。相手側が不調な局面では取得を止め、再試行間隔を広げる構成にすると、この要件と過負荷回避を両立しやすくなります。

デメリットと向いていない条件

lastmodは任意なので、全URLで更新候補を絞れるとは限りません。また、ページのlastmodとHTTPのIf-Modified-Sinceは別の情報であり、仕様も両者が異なる形で利用され得ると明記しています。サイトマップの値だけで本文未変更を断定する設計には向きません。

今回の検証済み情報だけでは、対象サイトがETagや条件付きリクエストに対応するか、304を正しく返すかまでは判断できません。そのため、まずlastmodを候補選別に使い、対象外URLの定期的な再確認を残すのが安全です。取得時には利用規約、robots.txt、許容されるアクセス頻度を個別に確認し、プロキシ増設は差分化後にも処理能力が不足する場合に検討すると、費用と相手サーバーへの負荷を判断しやすくなります。