搜索引擎抓取规则：入口页面正常但深层链路失效时怎样定位断点
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5c27682756d6.html
📄
搜索引擎抓取规则：入口页面正常但深层链路失效时怎样定位断点
深层链路失效，通常不是入口页面本身被拒绝抓取，而是从入口到目标页之间的某一段路径没有被爬虫继续走完。最有效的做法是：先选一条最短的入口到目标页路径，逐段检查每一跳的链接是否真实可抓、是否依赖交互、返回状态是否正常，再判断断点落在哪一跳。缺少完整日志或后台权限时，这个最小动作仍然可执行，但只能定位到“哪一跳可疑”，不能直接得出“整站规则配置错误”的结论。
两个常见解释：链接不可达，还是抓取预算被截断
入口页面正常、深层页面不出现，最常见的两种解释是：
- 链路本身不可达。中间层链接由 JavaScript 生成、放在表单或按钮后面、被 robots.txt 屏蔽，或返回 3xx/4xx/5xx，导致爬虫无法沿路径继续。
- 链路可达但没被继续抓取。路径存在且返回 200，但入口页可发现链接过多、层级过深，或站点长期输出大量低价值 URL，使爬虫在有限预算下优先抓取其他部分。
这两种解释的处理方向完全不同：前者要修链接和规则，后者要收敛可发现 URL 的数量和层级。如果只凭“深层页没被抓”就改 robots.txt 或加大站点地图，很可能改错地方。
能区分两种解释的证据：逐跳状态与可发现性
区分它们的关键证据是“每一跳是否独立可发现且可返回”。可以按下面的顺序取证：
- 从入口页出发，手动沿真实用户路径点击到目标页，记录每一跳的 URL。
- 对每一跳 URL 直接请求，记录 HTTP 状态码和最终 URL，确认没有被重定向链吞掉。
- 查看每一跳的 HTML 源码，确认下一跳链接是否以
<a href>形式存在，而不是只在点击后由脚本插入。 - 检查这些 URL 是否被 robots.txt 的 Disallow 规则覆盖，注意规则匹配的是路径前缀还是具体文件。
- 如果条件允许，再用抓取日志确认爬虫实际访问过哪几跳；没有日志时，前三步仍能给出方向性判断。
如果某一跳返回 200 且链接在源码中可见，但爬虫没有继续，问题更偏向抓取预算或优先级；如果某一跳返回 4xx/5xx、需要交互才出现，或被规则屏蔽，断点就在那一跳。
一个假设例子：三层路径中第二跳被规则挡住
假设入口页 /a 正常，目标页是 /a/b/c。手动点击时，/a 上的链接指向 /a/b，而 /a/b 上的链接由脚本在滚动后生成。直接请求 /a/b 返回 200，但源码里没有指向 /a/b/c 的 <a href>。此时断点在第二跳到第三跳：不是入口页被拒，而是第三跳在初始 HTML 中不可发现。下一步应把该链接改为服务端输出或静态可发现形式，而不是去改入口页的规则。反过来，如果 /a/b 源码里有链接但返回 403，则断点在第二跳本身，应先处理该 URL 的可访问性。
缺少日志和权限时，最小动作与不能推出的结论
没有抓取日志、没有搜索后台权限时，仍可执行的最小动作是：用浏览器开发者工具或直接请求，逐跳记录状态码、最终 URL 和源码中是否存在下一跳链接。这个动作能回答“链路是否可发现、是否可返回”，从而把断点缩小到具体一跳。
但它不能直接推出以下结论：
- 不能因为某页没被抓取，就断定是 robots.txt 造成的；规则限制只是可能原因之一，返回状态、链接可发现性和抓取优先级都可能造成同样现象。
- 不能因为站点地图提交了 URL，就认为它一定会被抓取；站点地图只是发现线索，不保证收录或抓取。
- 不能因为启用了 HTTPS，就认为链路安全或抓取正常；HTTPS 与是否被抓取、是否被索引是不同层面的事。
- 不同搜索引擎对脚本渲染、规则匹配的支持并不一致，结论必须分别核查，不能用一个引擎的表现替代另一个。
把断点定位到具体一跳后，下一步应针对该跳做最小修改并重新验证同一路径，而不是同时改动多个规则，否则无法判断是哪项改动起了作用。
