百度收录：入口页面正常但深层链路失效时怎样定位断点
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2225ecc03161.html
📄
百度收录：入口页面正常但深层链路失效时怎样定位断点
先接受一个前提：入口页面能被百度收录，只能说明这条链路的起点可访问，不能证明从入口到深层页面的跳转、渲染和抓取路径都成立。定位断点的核心动作，是把“入口→中间页→目标页”拆成可分别验证的三段，再用日志和抓取结果判断断在哪一段，而不是继续对目标页重复提交。
先分清两种失效模式，再决定排查方向
深层链路失效通常落在两种模式里，处理顺序完全不同。
- 链路断裂型：入口页可抓取，但中间页返回404、301指向错误或需要登录，百度根本走不到目标页。特征是入口页有抓取记录，目标页长期没有抓取记录。
- 链路可达但内容不可用型：中间页能抓，目标页也能返回200，但正文由脚本延迟加载，百度拿到的HTML里没有有效内容。特征是目标页有抓取记录，但抓取到的正文为空或只有框架。
区分依据不是页面在浏览器里看起来是否正常，而是服务器日志里目标页有没有被抓取记录、抓取到的响应体里有没有正文。浏览器正常渲染只证明用户路径通，不证明百度路径通。
选择依据：看目标页是否有抓取记录
假设入口页为 /list，中间页为 /list/page-2，目标页为 /item/123。先查服务器日志中 /item/123 是否出现过百度蜘蛛的请求。
若目标页完全没有抓取记录，断点在链路可达性上。此时应依次检查：中间页是否返回200、分页链接是否为可抓取的 <a href>、是否被robots.txt误拦、是否依赖点击后才由脚本拼出链接。发现中间页链接由JavaScript事件绑定生成时，把它改成静态可抓取的超链接，再观察目标页是否开始出现抓取记录。这一步的结果决定下一步：如果改完后目标页仍未被抓取，问题可能不在前端链接，而在中间页本身未被百度纳入抓取队列。
若目标页有抓取记录但正文缺失，断点在内容呈现上。此时应抓取百度看到的原始HTML，确认正文是否在初始响应中。若正文由接口异步填充，可考虑服务端渲染或预渲染关键内容，再复查抓取到的HTML。若改完后正文出现但目标页仍未收录，说明断点已从渲染转移到索引判断，需要另查重复内容和页面身份。
一个可执行的断点定位动作
不要从入口页开始逐页点，而是从目标页反向验证。具体动作：
- 取目标页URL，在日志中检索其被抓取的时间、状态码和响应大小。
- 若状态码为200但响应大小明显小于浏览器渲染后的体积，标记为内容不可用型。
- 若目标页无记录，回到中间页，检查其返回码和出链是否为静态超链接。
- 确认中间页可抓后，再检查入口页到中间页的出链是否同样可抓。
这个顺序的意义在于，它把“入口页正常”这个已知条件排除掉，避免在已经成立的环节上反复提交。每完成一步，下一步的检查对象就缩小一层。
例外与容易误判的情况
有些现象看起来像链路失效，实际另有解释。目标页抓取量为零，可能是该页刚发布、百度尚未调度，也可能是中间页被robots.txt限制，还可能是站点整体抓取频率下降。单凭抓取量为零不能证明链接结构有问题。
另外，robots.txt的抓取限制不等于可靠的索引移除，它只阻止抓取，不保证已收录页面被移除。站点地图提交不保证收录，入口页正常也不保证深层页被调度。若中间页依赖登录态或地域跳转，百度拿到的可能是跳转页而非目标内容，这类情况需要单独构造可公开访问的路径来验证。
把断点定位到具体一段后，再决定是修链接、改渲染还是处理页面身份。修复动作完成后，用同一组日志字段复查目标页是否出现抓取记录和完整正文，以此判断断点是否真正前移，而不是只看入口页是否仍然正常。
