收录入口：入口页面正常但深层链路失效时怎样定位断点
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d84e37d0fa02.html
📄
收录入口：入口页面正常但深层链路失效时怎样定位断点
先给结论：当收录入口本身能访问、返回正常，而更深的页面或链接层级迟迟没有进入索引时，断点通常不在“入口是否可达”，而在“从入口到深层节点之间，爬虫是否被引导、被允许、被正确解析”。要定位它，不能只看入口状态码，而要沿链路逐跳验证“发现—允许—可解析—可索引”四个环节，哪一跳开始出现只有部分节点通过的现象，断点就在那一跳。
为什么入口正常不等于深层链路正常
入口页面返回 200，只证明这一个 URL 对爬虫可见。它不证明入口上的链接被解析、不证明深层 URL 被加入抓取队列、也不证明深层页面通过了索引判断。常见矛盾是：入口页在索引里，入口页指向的分类页或详情页却没有。此时问题往往出在入口到深层之间的“传递”环节，而不是入口本身。
一个容易被忽略的条件是：入口页可能对用户正常渲染，但链接是脚本运行时才插入的。爬虫拿到初始 HTML 时，链接尚未出现，于是深层节点从未被发现。这种情况下入口状态码永远正常，深层链路却始终断着。
两种解释：没被发现，还是被发现但没通过
深层链路失效，先分成两类互斥解释，能大幅缩小排查面。
- 解释一：深层 URL 从未被发现。入口页的链接没有被解析、被 nofollow、被脚本延迟生成，或站点地图里根本没有这些深层地址。爬虫没有理由去抓它们。
- 解释二：深层 URL 被抓取了，但没通过索引判断。它们进了抓取队列，却因为内容质量、重复、规范化指向别处、返回错误或需要登录等原因被排除。
这两类的处理方向完全不同：前者要修“发现路径”，后者要修“页面本身或索引信号”。如果混在一起查，很容易在入口页反复确认状态码，却始终碰不到真正的断点。
能区分两种解释的证据
关键是拿到“深层 URL 有没有被请求过”的证据，而不是只看最终是否被索引。
- 查服务器访问日志，按深层 URL 路径过滤，看是否存在来自爬虫的请求记录。有请求记录，说明发现环节基本通了，问题偏向解释二。
- 如果完全没有请求记录，再回到入口页，检查链接在初始 HTML 中是否存在、是否带 rel="nofollow"、是否依赖脚本注入。这是解释一的典型证据。
- 若日志显示被抓取但未索引，检查该深层页的返回状态、canonical 指向、robots meta、内容是否与已有页面高度重复。
需要提醒的是：日志里没有请求记录，不能单独证明“爬虫从未发现”。日志可能被轮转、被采样、被过滤，或爬虫请求走了另一台机器。反过来，抓取量归零也不能直接证明处理正确。要结合多个信号交叉判断，而不是把单一现象当结论。
一个假设例子：从入口到详情页的断点定位
假设某站入口页 /list 正常且已被索引，它指向的详情页 /item/123 长期未收录。按上面的方法走一遍：
- 先查日志，发现
/item/路径下没有任何爬虫请求记录——偏向解释一。 - 再取
/list的初始 HTML，发现详情链接由前端脚本在交互后插入，初始源码里没有<a href="/item/123">。 - 结论：断点在“发现”环节。修复动作是把深层链接以可解析的
<a>形式放进初始 HTML，或补进站点地图。 - 动作后的下一步：修复上线后重新观察日志，确认
/item/是否开始出现爬虫请求。若出现请求但仍未索引，说明断点已从“发现”移到“索引判断”，排查方向随之切换到解释二。
这个例子的价值在于：每一步动作都改变了下一步的观察对象，而不是停在入口页反复确认。
几个容易误判的前提
定位断点时，有几个前提必须分清，否则会把正常现象当成故障。
- robots.txt 的抓取限制不等于可靠的索引移除。被 robots 禁止抓取的 URL 仍可能因外部链接被收录，所以不能用它当作“让深层页消失”的手段，也不能据此判断深层页一定不会出现。
- 站点地图不保证收录。把深层 URL 放进站点地图只是提供发现线索，不代表爬虫会抓、更不代表会被索引。它解决的是解释一里的一部分情况，对解释二无效。
- 不同搜索引擎对脚本渲染、站点地图和索引信号的支持情况不同，需分别核查。在一个引擎里能通过的链路，在另一个里未必成立，不能用单引擎结果推断全部。
定位断点的核心动作始终是：先判断深层 URL 有没有被请求，再决定修发现路径还是修索引信号。只要这一步的证据方向明确，后续排查就不会在入口页原地打转。
