收录：入口页面正常但深层链路失效时怎样定位断点
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a2e91bd9d29f.html
📄
收录：入口页面正常但深层链路失效时怎样定位断点
先给结论：入口页正常只能证明抓取通路没有整体瘫痪，不能证明深层链路可用。定位断点的顺序应是——先确认失效发生在“可发现”还是“可抓取”环节，再沿一条真实链路逐跳验证，而不是从站点地图或日志总量上下结论。
假设情境：三层目录，只有第一层正常
假设某站结构为 /a/（入口）→ /a/b/（中间层）→ /a/b/c-1.html（深层详情）。样本量小时，抽查入口页与少量深层页都正常；规模化后，大量深层页不再出现在收录结果中，而入口页始终稳定。这个反差是本题的起点。
此时常见误判是：入口正常，所以问题在内容质量。但入口正常只说明根路径可访问、可被抓取，深层链路的每一跳都可能独立失效。需要把“正常”拆到跳数上。
第一刀：区分“可发现”与“可抓取”
深层页失效有两类原因，证据不同，处理动作也不同：
- 可发现问题：中间层页面没有被有效发现，或深层链接只存在于 JS 渲染后才出现的 DOM 中。证据是抓取统计里中间层 URL 的抓取频次明显低于入口层，且深层 URL 从未出现在抓取记录中。
- 可抓取问题：深层 URL 已被发现，但抓取被 robots.txt 限制、返回非 200 状态、或响应超时。证据是该 URL 出现在抓取记录中但结果异常。
这两种情况的下一步完全不同：前者要修链接暴露与渲染方式，后者要修服务器与规则。若只看到“深层没收录”就同时改两处，无法判断哪一步真正生效。
第二刀：沿一条链路逐跳验证
不要抽样统计，先取一条确定的链路，按跳记录：
- 入口页
/a/是否返回 200，且 HTML 源码中（非渲染后）存在指向/a/b/的<a href>。 - 中间层
/a/b/是否返回 200，且源码中存在指向具体深层页的链接，而非依赖点击后才请求的接口。 - 深层页
/a/b/c-1.html是否返回 200，是否被 robots.txt 的 Disallow 命中。
如果第 2 跳的链接只存在于渲染后的 DOM，那么对不执行脚本的抓取而言，这一跳就是断点。此时把中间层改为服务端输出链接，再观察深层 URL 是否开始出现在抓取记录中——这是判断该断点是否为真因的直接动作。
第三刀：排除几个常见假信号
以下现象容易被当成“链路断了”，但解释不止一种：
- 站点地图里有深层 URL，但没被抓取：站点地图提交不保证收录，也不保证被抓取。它只提供发现线索，抓取仍受配额、优先级与链接权重影响。
- robots.txt 限制了深层目录：抓取限制不等于索引移除。被限制抓取的 URL 仍可能因外部链接出现在结果中，只是内容可能陈旧。要移除索引应使用对应的移除机制，而不是只加 Disallow。
- 抓取量突然归零：可能是服务器整体不可达、也可能是抓取配额调整或规则误伤。归零本身不能证明某一次改动正确，需要结合状态码分布一起看。
- HTTPS 已启用：HTTPS 不保证无漏洞，也不保证排名。它只解决传输加密，与深层链路是否可达无关。
什么时候不能照搬这套顺序
若站点深层页本身是低频更新、低优先级内容，抓取频次低属于正常现象，逐跳验证会得到“全链路正常但就是不常抓”的结论。此时继续修链路没有收益，应转而判断该层内容是否值得被优先发现。
另外，若中间层由前端路由动态生成，且站点主要依赖客户端渲染，那么“源码中无链接”是预期行为而非断点，需要改用能验证渲染结果的抓取方式，再判断哪一跳真正失效。
把上面三步走完，你会得到一个明确结论：断点在第几跳、属于可发现还是可抓取。这个结论决定下一步是改链接输出、改 robots 规则，还是接受该层抓取频次偏低的现状。
