增量爬取

简而言之：增量爬取仅重新抓取自上次运行以来可能发生变化的页面，而不是每次都重新爬取整个网站。它既能保持数据新鲜，又能大幅减少请求量。

增量爬取将爬取视为一个持续进行的过程，而不是一次性事件。首次运行会建立基准。此后的每次运行都专注于发生的变化：新增页面、更新页面和已消失的页面。如果一个网站每次运行之间只有 2% 的内容发生变化，那么完整重新爬取会将 98% 的资源用于确认没有任何变化。

变更检测方法：

1. 条件请求：发送 If-Modified-Since 或 If-None-Match，让服务器返回 304 Not Modified，几乎不消耗带宽。
2. 内容哈希：对每个页面的有效内容计算哈希值，并与上次爬取时存储的哈希值进行比较。
3. 站点地图 lastmod：读取网站 XML 站点地图中的 lastmod 字段，仅重新爬取时间戳更新的条目。
4. 订阅源监控：轮询用于发布新内容通知的 RSS 或 JSON 订阅源，其成本远低于通过爬取来发现新内容。
5. 结构信号：监控列表页和分页中的新条目，而不是重新访问每个详情页。

条件请求：

GET /products/4417 HTTP/1.1
Host: example.com
If-None-Match: "a3f8c21b9"
If-Modified-Since: Tue, 15 Sep 2026 09:14:00 GMT

HTTP/1.1 304 Not Modified
ETag: "a3f8c21b9"

304 响应不包含响应正文。爬虫工具只需承担请求头的开销，就能得知页面未发生变化，通常仅需几百字节，而一个页面可能有 200 KB。对于包含 100,000 个大多为静态页面的目录而言，这意味着完整重新爬取需要 20 GB，而使用条件请求仅需 30 MB。

其局限在于支持情况并不一致。许多网站不发送 ETag，还有一些网站发送的值会在每次请求时发生变化，无论内容是否改变，这会使该机制对这些目标完全失效。

内容哈希：

当服务器无法提供帮助时，爬虫可以在获取内容后计算哈希值，自行判断是否发生变化。这种方式无法节省带宽，因为无论如何都必须获取页面，但它可以避免不必要的重复处理、存储写入和下游管道任务。

难点在于决定对什么内容计算哈希。对原始 HTML 计算哈希几乎会在每次抓取时产生不同的值，因为时间戳、会话令牌、轮换广告和浏览计数器都会发生变化，而这些变化与用户真正关心的内容无关。有效的哈希计算应针对提取的字段，而不是标记内容：例如产品标题、价格和描述，而不是包含这些信息的整个页面。

重新爬取频率：

固定间隔只是起点，而不是终点。自适应调度的效果更好：跟踪每个 URL 实际发生变化的频率，然后缩短易变页面的爬取间隔，并延长稳定页面的间隔。一个连续 30 次爬取都完全相同的页面，无需像每天都会变化的页面那样频繁检查。

检测删除：

增量爬取能够自然处理新增和更新的页面，因为这两类页面都可以通过常规发现流程呈现。已移除的页面则更难处理，因为缺失本身不会产生信号。

页面可能返回 404 或 410，这种情况明确无误。它也可能返回 200 并显示“已不可用”消息，重定向到分类页面，或者只是不再被其他页面链接，但仍可通过直接 URL 访问。只有第一种情况无需明确重新访问即可检测。

常见做法是定期执行完整扫描，频率低于增量爬取，访问每个已知 URL，并标记所有缺失或无法访问的页面。对于大多数目录，每天执行增量爬取并每月进行完整扫描，是一种合理的默认方案。

状态要求：

增量爬取需要持久化状态，而一次性爬取不需要。爬虫工具至少必须为每个 URL 存储上次爬取时间戳、上次 ETag 或 Last-Modified 值、内容哈希、观测到的变化频率，以及连续失败次数。

正是这种状态将增量爬虫与定期完整爬虫区分开来。没有它，每次运行都会从零开始，效率优势也会完全消失。

Bright Data 的网页抓取工具 API和数据集会在内部维护此状态，并按计划提供更新后的记录，因此无需自行构建和运营变更跟踪基础设施。