一个有效的机器人.txt文件并不一定意味着一个网站可以被爬行者访问.
当一个网页应用程序防火墙,CDN,主机配置,速率限制,或者其他送出层返回一个HTTP错误,如403紫禁或429"太多"请求时,请求仍然可能失败.
端到端爬行者测试通过检查爬行者请求真实页面时会发生什么,然后将结果与服务器侧证据进行比较来弥补这一缺口.
这是一种有益的业务做法,而不是新公布的标准作业程序框架。
中心思想是直截了当的:机器人.txt通讯爬行指令,但并不能保证服务于一页的基础设施会允许请求通过.
对网站所有者来说,实际目标是在仅依靠SEO仪表板的爬行报告之前,先找到阻止访问的特定层.
Google的机器人.txt文档解释了Google如何解释机器人.txt,并处理文件无法到达或HTTP回复影响访问的情况.
这种指导很重要,因为爬行者的访问是由机器人规则和HTTP行为形成的 爬行者在请求一个站点时遇到。
机器人 . txt 是一个指令文件,而不是一个端到端访问测试机器人.txt是一个重要的控制点.
它可以告诉符合要求的爬行者哪些路径不应该被爬行.
然而,它与决定HTTP请求能否达到一页的系统分开运行.
一个站点可以有一个显然允许的机器人.txt文件,而一个安全或传送层在返回有用内容前会屏蔽请求.
当可爬行性被视为一个序列时,这种区分变得更加明确:爬行者必须在适当情况下检索机器人.txt,请求目标URL,得到可接受的响应,并能够访问预定内容.
任何阶段的失败都可能影响实际结果。
检查 它能显示什么 它不能建立 在自己的机器人.txt审查 所声明的爬行指令允许还是不允许路径 安全、 CDN 或主机层是否成功返回页面 直接 URL 获取 HTTP 响应、 重定向和该测试请求的可访问响应内容 请求是否与每个条件中的每个爬行者一样得到处理 服务器和边缘日志 收到请求,服务基础设施如何回应 除非可用的日志细节能识别出一个块的原因 直接测试应该补充而不是取代一个机器人.txt的审查.
它可以揭示URL是否返回成功响应,出乎意料地重定向,或者在交付点产生出错.
测试只应在网站和基础设施上进行。
为何403和429回复值得关注 A403回复表示服务器或中介拒绝了请求.
一份429份答复表明,请求者受费率限制。
两者均可由机器人外.txt的规则产生,包括WAF,CDN配置,主机级保护,或流量控制.
这些答复并不自动确定负责系统。
爬行者可能会被网络边缘,应用安全规则所阻断,或者被源服务器所阻断.
这就是为什么基于浏览器的检查可能是不够的:为人类用户加载的页面可能对达到不同规则或阈值的请求产生不同的结果.
测试爬行器访问的实用程序 有效的调查将URL级别的症状与生成它的基础设施层联系起来.
从有代表性的页面开始,而不仅仅是主页。
包含重要到站点发现的关键页面,如重要类别,服务,产品,或相关文章URL等.
1.
审查预定的机器人.txt规则,确认可访问的机器人.txt,其指令与预定的爬行政策相匹配.
这确立了政策层,但不应将其作为可检索页面的最后证据。
继续把审查的重点放在雷克上