搜索引擎收录入口：入口页面正常但深层链路失效时怎样定位断点
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6eb209e47c3a.html
📄
搜索引擎收录入口：入口页面正常但深层链路失效时怎样定位断点
先给结论：入口页正常而深层页不收录，最常见的原因不是入口本身，而是从入口到深层页之间的某一段链路被切断或被替换了。定位方法不是继续盯入口页，而是沿点击路径逐段验证“可发现、可抓取、可渲染、可索引”四个环节，找到第一处实际断开的位置。
这类问题经常在团队里出现分歧：运营说“入口能打开”，开发说“日志里没有请求”，SEO说“收录就是掉了”。三方说的其实不是同一件事。把分歧转成可核对的项目，是定位断点的前提。
先区分两种解释：链路真的断了，还是只对某类访问者断了
当入口页正常、深层页不收录时，通常存在两种成立条件不同的解释。
解释一：链路物理断开。入口页里的链接指向了错误的地址、被脚本动态生成而爬虫执行失败、或者中间跳转指向了失效目标。此时任何访问者沿真实路径都到不了深层页，属于硬断点。
解释二：链路只对特定访问者失效。入口页和深层页都正常，但中间环节对爬虫做了区分处理，比如依赖登录态、依赖特定 User-Agent 才渲染链接、或跳转链中夹了一次需要交互的确认。此时人手动点击能到达，自动抓取到不了，属于软断点。
这两种解释对应的修复动作完全不同。前者要改链接或渲染方式，后者要改访问控制或跳转逻辑。分不清就会反复改错地方。
用一组可区分证据判断是哪一种
不要凭感觉归类，用下面几组证据交叉核对，能明显区分两种解释。
- 抓取日志与真实点击的差异。如果日志里完全没有对深层页的请求，而人工点击能到达，偏向软断点；如果日志里出现了对错误地址的请求，偏向硬断点。
- 链接是否存在于初始响应中。查看入口页返回的原始 HTML，看深层页链接是否直接写在里面。如果链接只由脚本在浏览器端插入，爬虫未必执行，这属于可发现性断点。
- 中间跳转的类型。逐段记录从入口到深层页经过的每一次跳转，看是否存在需要交互、需要 Cookie 或返回临时状态的环节。
- 换一个入口复测。如果从站点地图或其他入口能到达同一深层页，说明深层页本身可被抓取，问题出在这条特定链路上。
需要提醒的是，抓取量归零或某项统计下降，不能单独证明断点就在这一层。它也可能是抓取预算调整、站点整体改版或外部链接变化的连带结果。要结合上面几组证据一起看。
一个假设例子：沿路径逐段核对
假设某站点入口页 A 能正常打开，深层页 C 长期不收录，中间经过页面 B。可按下面顺序核对，每一步的结果决定下一步动作。
- 取 A 的原始响应，确认指向 B 的链接是否直接写在 HTML 中。若链接由脚本生成，先解决可发现问题，再谈后续。
- 若链接存在，请求 B，记录返回状态和跳转目标。若 B 返回临时跳转或需要交互，说明断点在这一跳。
- 若 B 正常且包含指向 C 的链接，再直接请求 C，确认 C 是否返回正常内容、是否被 robots.txt 限制、是否要求登录。
- 若以上都正常，再检查 C 的可见内容是否依赖脚本渲染，以及渲染后的正文是否与预期一致。
这个例子里，通常第一处异常出现的位置就是断点。假设前三步都通过、第四步失败，那么问题在于内容可见性而非链路可达性，下一步应转向渲染与内容呈现的核对，而不是继续改链接。
要注意，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。它们只能作为辅助证据，不能单独用来判断断点位置。
把分歧转成可核对的项目
团队争论往往源于各自观察的层面不同。可以把问题拆成一张核对表，让每个角色只回答自己能看到的部分。
- 运营：人工点击路径中，哪一步开始出现异常？
- 开发：入口页初始响应里，目标链接是否存在？中间跳转返回什么状态？
- SEO：抓取日志中，请求落在哪一段，是否出现错误地址或空请求？
三项对齐后，断点通常只有一个位置能被三方同时确认。此时再决定修复动作，并复测同一条路径，确认异常是否消失。若修复后仍不收录，说明还存在第二处断点，需要重新走一遍核对流程，而不是直接归因于入口页。
不同搜索引擎对脚本渲染、跳转和访问控制的支持情况需分别核查，同一站点在不同引擎下的断点位置可能并不相同。
定位完成后的下一步
找到断点只是第一步。真正影响后续的是：修复动作是否针对断点本身，以及复测是否覆盖了原始路径。若断点在可发现性，修复后应确认链接进入初始响应；若断点在访问控制，修复后应确认自动抓取能到达深层页。只有复测结果与断点位置对应，才能判断处理是否到位，也才能决定是继续排查下一段，还是转入收录观察阶段。
