Sitemap 与 robots.txt

Scrapeless Crawl 从可以通过 sitemap 或其他已定义来源发现的 URL 收集页面内容。

每个文件的作用是什么？

“Sitemap 与 robots.txt”比较的是一种用于发现的格式与一个抓取策略文件。sitemap 标识发布者希望使用者发现的 URL；robots.txt 文件传达符合规范的自动化客户端应该请求哪些路径的规则。

这两个文件可以协同工作。robots.txt 文件可以声明 sitemap 的位置，而 sitemap 可以标明通过链接难以发现的页面。两种文件都不能替代页面响应或搜索引擎后续的处理。

该 Sitemaps XML protocol 定义了 URL 列表格式和 sitemap 索引。而 Robots Exclusion Protocol 定义了抓取规则行为。应将它们视为不同的职责，而不是把某一个当成更强大的 SEO 文件。

Sitemap 有助于发现但不会强迫选择

sitemap 为爬虫提供了发布者给出的候选 URL 清单，这对新页面、大型内容集合以及内部链接有限的资源非常有用。使用者可以用该列表来初始化抓取队列，而无需遍历站点上的每个界面。

该列表应反映站点预期的公共资源清单。包含重定向、已删除页面、重复变体，或被同一站点阻止抓取的 URL 的 sitemap 会制造不必要的工作和混乱的信号。应把 sitemap 生成视为与规范 URL 策略相结合的发布责任。

sitemap 索引让发布者可以组织多个 sitemap 文件。采集程序应区分索引与普通 URL 集合，并处理适当的条目。跟踪已访问过的 sitemap 位置，以免格式错误的引用导致无限循环。

在提供修改信息时，应体现源内容的实际变更；不应仅仅因为定时任务重新生成了内容完全相同的文件就更新该信息。使用者仍然会自行决定如何优先处理并验证被公开的资源。

robots.txt 将规则应用到特定客户端和路径

robots.txt 按自动化客户端身份对规则进行分组，并通过路径匹配应用到资源请求。它应位于相关源站的根路径位置，其作用范围需要针对被抓取的主机和协议进行评估。不要假设一个源站上的文件就定义了所有子域的策略。

路径模式需要经过仔细测试。过于宽泛的规则可能会无意中包含有用的部分，而过于狭窄的规则则可能遗漏变体。应针对受影响的路由族测试具有代表性的 URL，而不是仅凭目测审查文本。

将以下文本从英语翻译为中文。 规则： 1. 只输出翻译后的文本——不要添加任何解释，也不要使用额外的包裹代码块。 2. 完全保留 Markdown/HTML 结构（标题、列表、链接、表格）不变。 3. 保留任意占位符标记（例如 @@CODEBLOCK_0@@ 或 @@INLINECODE_0@@）原样不动；绝对不要翻译、重排、合并或重新格式化它们。 4. 不要添加或删除 ``` 代码块，也不要把普通文本包裹进代码块中。 规则还取决于适用的 user-agent 组。通用组和具名组可以对不同客户端产生不同的结果。请使用一个实现预期协议行为的解析器，而不是把文件当作简单的子字符串黑名单来处理。

将应用授权与其分开处理。Robots 规则是对自动化客户端公开可读的指令。敏感文档需要身份验证和访问控制；在 robots.txt 中列出机密路径的名称会暴露其位置，而无法保护其中的内容。

抓取阻止与索引移除不同

阻止爬取并不能可靠地将 URL 从搜索结果中移除。即使搜索引擎无法抓取页面，它仍然可以通过其他信号获知该 URL 的存在。 Google robots.txt 限制 解释为什么必须将抓取排除和索引控制分别考虑。

页面上的索引指令必须被看到才能被处理。如果爬虫被禁止抓取该页面，它可能永远无法看到你放置在那里的指令。在选择控制方式之前，请先确定目标是减少抓取、将内容从索引中移除，还是保护访问权限。

站点地图并不是对禁止规则的覆盖。列出被屏蔽的 URL 并不会授予遵从规范的客户端获取它的权限。同样，从站点地图中移除某个 URL 并不意味着它不可被发现或已被删除；链接和之前的记录仍然可能将其暴露出来。

对于事件处理，要将期望结果与文件编辑区分开来。删除站点地图条目、更改 robots 规则、服务器端访问限制以及索引移除请求代表不同的操作。通过适当的检查来验证最终状态，而不是仅仅因编辑操作完成就声称任务已完成。

根据实际网站审查文件

一次有用的审核会将已公开的 URL 和抓取规则与实际响应进行比较。文件是否存在只是起点。审核应揭示各种矛盾，例如某个站点地图 URL 被重定向到另一个规范 URL，或者某个期望的落地页被一条范围过大的规则排除在外。

1. 识别相关的源站并获取它们的 robots 文件。
2. 从声明的来源或发布系统中发现站点地图的位置。
3. 使用有界递归解析 URL 集和索引。
4. 根据适用的抓取规则评估每个选定的页面。
5. 检查响应状态、最终 URL 和规范意图。
6. 记录排除项、失败项和已验证内容。

不要使用规范化来抹消有意义的差异。结尾斜杠、语言前缀或查询参数可能是站点 URL 策略的一部分。保留原始 URL，并与任何被规范化的标识一同保存，这样审核人员就能理解审计是如何对记录进行分组的。

一个精简的对账可以说明某个 URL 是否已被列出、允许、请求、重定向以及接受。这些都是相互独立的事实。有意排除的页面不应被计为抓取失败，而成功抓取的页面在没有搜索引擎证据的情况下也不应被称为已收录。

从站点地图到内容收集

网站地图可以在经过策略和 URL 检查后为内容流水线提供初始数据。将通过检查的 URL 集合输入到采集层，然后根据预期用途验证返回的内容。已发现的 URL 列表尚不是完整的文档语料库。

无痕爬取 可以为该工作流提供页面内容集合。在你自己的记录中保留源站点地图位置、请求的 URL、最终 URL，以及观察上下文。这些字段有助于解释为什么文档会存在，以及是由哪个源条目生成的。

The 站点地图驱动的集合概览 扩展了从发现阶段到内容阶段的交接。使用…来估算成本 无爬取方案定价 而是先去除不在范围内的内容和重复工作，而不是从未经筛选的 URL 数量来制定预算。

在后续对比中保留发现到的输入内容。如果某个文档在下一个站点地图中消失，需确定它是被有意下线、移动到另一个规范 URL，还是因发布错误而被遗漏。仅凭当前文件中的缺失无法区分这些结果。

解决相互矛盾的发布信号

站点地图审核应通过具体示例来解释自相矛盾的信号。假设一个目标着陆页出现在站点地图中，但却被一条宽泛的 disallow 规则所覆盖。符合规范的爬虫可以发现该 URL，但无法抓取它。从站点地图中移除该页面只会在该清单中隐藏这一矛盾，却无法实现期望的抓取行为。

在与站点所有者确认发布意图后，更正适用的规则或所宣传的库存。如果列出的页面重定向到替代页面，在核实迁移后，将网站地图与预期的规范目标对齐。保留原始观察结果，以便报告能够解释为何 URL 发生了变化。

部署后重新检查实际文件和页面响应。即使源模板正确，如果构建或缓存未更新，仍可能产生过期的对外输出。完成的审计应描述所观察到的网站状态，并将尚未解决的发布差距与拟议的编辑明确区分开来。

结论

站点地图有助于资源被发现；robots.txt 用于传达抓取规则。将两者与实际页面清单保持一致地使用，并将抓取与索引和访问保护区分开来。在预期更改应生效的层级验证结果。