网站不被收录原因：入口页面正常但深层链路失效时怎样定位断点
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ed3682859c6b.html
📄
网站不被收录原因：入口页面正常但深层链路失效时怎样定位断点
先给结论：入口页正常只说明抓取与索引链路在入口处是通的，深层页面失效通常断在“发现—抓取—渲染—索引”四段中的后三段的某一处。要定位断点，不能只看首页或栏目页的状态，而要从入口页出发，沿着一条真实存在的内链路径逐跳核对，找到第一个“上一层正常、下一层异常”的节点，那就是断点所在层。
为什么入口正常不等于深层链路正常
入口页面（首页、主栏目页）往往是被外部链接和站点地图反复推送的对象，抓取频率高、渲染优先级高，所以它的状态容易保持正常。深层页面依赖站内链接被发现，如果中间某一跳的链接形态、渲染方式或可抓取性发生变化，深层页面就会从“可发现”变成“不可发现”，但入口页本身不会有任何异常表现。这就是直觉与结果相反的原因：你检查的页面没问题，出问题的页面你还没检查到。
两个成立的解释：链接未被发现，还是被发现但抓取失败
深层链路失效至少有两种成立解释，它们的修复动作完全不同。
- 解释一：发现链断裂。入口到深层之间的某一跳链接不再可被抓取，例如中间层用JavaScript在交互后才插入链接、链接被包裹在需要点击才展开的组件里、或中间层本身返回了错误状态。深层页面从未进入待抓取队列。
- 解释二：发现链存在，但抓取或渲染失败。链接在HTML里可被抓到，但深层URL返回超时、5xx、被robots.txt拦截，或内容依赖渲染而渲染资源被阻断。页面进了队列却没有形成可用版本。
这两种解释的差别在于：前者断点在“链接是否可被抓到”，后者断点在“抓到之后能否处理”。只看入口页正常这一条证据，无法区分。
能区分两种解释的证据
要区分，需要沿一条具体路径逐跳取证，而不是全站扫描。做法是：从入口页选一个目标深层URL，记录入口到目标之间的每一跳，然后对每一跳分别检查三件事——该跳页面是否返回200、该跳页面HTML源码里是否存在指向下一跳的可抓取链接、下一跳URL本身是否可被抓取与渲染。
判断规则可以这样用：
- 如果某一跳的HTML源码里找不到指向下一跳的链接，而该链接只在渲染后出现，则断点偏向解释一，问题在发现链。
- 如果每一跳的HTML里都有链接，但下一跳URL返回非200或被robots.txt拦截，则断点偏向解释二，问题在抓取。
- 如果URL返回200、链接也存在，但抓取到的版本内容为空或与可见内容不一致，则断点在渲染，需要单独核对渲染资源是否被阻断。
这里要注意一个反常现象：如果站点地图里收录了这些深层URL，但抓取量仍然很低，不能单独证明“站点地图无效”或“链接没问题”。站点地图只提供发现线索，不保证被抓取；抓取量低还可能是因为URL数量远超抓取预算、入口页优先级更高、或这些URL被判定为低价值。要先把“发现”和“抓取”分开验证，再下结论。
一个注明假设的短例子
假设某站入口页A正常，栏目页B正常，目标深层页C不被收录。逐跳检查发现：A的HTML里有指向B的普通链接；B的HTML里指向C的链接由前端脚本在滚动到底部后插入。此时断点在发现链，因为抓取工具在B的初始HTML里看不到C。动作：把B到C的链接改为服务端输出或初始HTML可见。结果：C重新进入可发现状态，下一步应观察C是否被抓取，而不是直接期待收录——被抓取之后还有渲染和索引两道关。
反过来，如果B的HTML里本来就有C的链接，但C返回超时，那么断点在抓取，应优先排查C所在服务器的响应与拦截规则，而不是去改B的链接结构。两个例子的第一步动作不同，正是因为区分证据不同。
定位后怎样决定下一步
找到断点层之后，下一步动作取决于断点类型。发现链断裂，修链接形态并确认初始HTML可被抓到；抓取失败，修状态码、超时与拦截规则；渲染失败，核对渲染所需资源是否可被抓取。每次只改一处，改完后沿同一条路径重新逐跳核对，确认“上一层正常、下一层也正常”的边界是否向前推进。如果改完仍然失效，说明断点不止一处，需要继续沿路径向后找下一个异常节点，而不是回到入口页重复检查。整个过程中，robots.txt的抓取限制只能影响抓取，不等于可靠的索引移除手段，用它来解释深层不收录时要格外谨慎。
