解决收录失败，入口正常但深层链路失效怎样定位断点
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /243298236f0a.html
📄
解决收录失败，入口正常但深层链路失效怎样定位断点
入口页面能被抓取、能出现在结果里，不代表从入口到深层页的整条链路是通的。定位断点的核心不是再提交一次入口，而是把“入口→列表/分页→详情”拆成可分别观察的跳转节点，找出哪一个节点之后深层页不再被正常发现或抓取。个别样本能收录、规模化后出现例外，正是这类断点的典型信号。
先分清两种条件：断在发现环节还是断在抓取环节
两种条件的处理顺序完全不同，先判错方向会浪费大量时间。
- 发现环节断点：深层页没有被入口有效指向，或指向方式对爬虫不可见。表现是入口本身抓取正常，但深层页从未出现在抓取日志中。
- 抓取环节断点：深层页已被发现，但抓取请求被拒、被重定向到无效目标，或返回非正常状态。表现是日志里有请求记录，但没有成功取回内容。
区分依据是抓取日志中是否出现过深层 URL 的请求记录。出现过而结果异常，偏抓取环节；完全没出现过，偏发现环节。这一判断直接决定下一步是改链接结构还是查响应状态。
发现环节：逐层验证入口到深层的可达性
常见断点是入口页的链接由脚本在交互后才生成，或分页只保留首屏、深层列表被折叠。此时入口可抓取，但爬虫沿链接走不下去。
- 取一个入口页，屏蔽脚本后查看源码，确认指向下一层的链接是否存在于初始 HTML 中。
- 沿列表页逐页检查分页链接是否可点、是否指向真实 URL，而不是仅触发脚本加载。
- 在详情页确认面包屑或返回链接能指回上一层，避免形成只有进没有出的孤岛。
实际动作：若第二步发现分页链接缺失，把分页改为静态可抓取的 URL 列表后重新观察日志。结果是深层页是否开始出现请求记录——出现则断点在发现环节已修复，可进入抓取环节核查；仍不出现则说明还有更上层的阻断。
抓取环节：看状态码、重定向链和抓取限制
已发现的深层页抓取失败，通常落在三类原因上，需要分别取证。
- 状态码异常：深层页返回 4xx 或 5xx。注意 robots.txt 的抓取限制与索引移除是两回事，前者只影响抓取，不等于页面已被可靠移除。
- 重定向链过长或指向失效：入口到深层经过多次跳转，中途某一跳落到错误目标，导致最终内容取不到。
- 抓取限制：robots.txt 或页面级限制挡住了深层路径，而入口路径未被挡，于是呈现“入口正常、深层失效”。
动作：对同一深层 URL 分别记录首次请求状态、重定向每一跳的目标和最终状态。若最终状态正常但内容为空，问题在渲染或返回体，而非可达性。这一步把抓取环节的断点收窄到具体一跳。
规模化后出现例外的边界：样本成立不等于全站成立
单个深层页能收录，不能推出同类页面都能收录。规模扩大后，分页深度、链接数量、生成方式的变化都可能引入新断点。可用的边界判断是：把深层页按“层级深度”和“入口类型”分组，分别抽样，而不是只抽最容易收录的那一组。
假设某站点入口页正常，第 2 层列表页可抓取，但第 4 层以后的详情页请求记录明显减少。这只能说明该分组下断点集中在深层，不能直接推断是分页机制的问题——也可能是抓取预算分配、链接权重衰减或生成时机差异。需要回到日志确认减少是从哪一跳开始，再决定改链接还是改生成策略。
定位完成后的动作与复查
确定断点层级后，动作应只针对该层，避免同时改动多处导致无法归因。修复发现环节后，复查深层 URL 是否进入抓取日志；修复抓取环节后，复查目标 URL 的最终状态与内容是否可取。站点地图提交不保证收录，HTTPS 也不保证页面无漏洞或必然被抓取，二者都不能替代对链路本身的验证。复查时若请求量回升，仍需确认回升的是有效内容抓取，而非无效请求，否则可能只是把断点从一层推到了另一层。
