网站不收录：入口页面正常但深层链路失效时怎样定位断点
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5fee46837370.html
📄
网站不收录：入口页面正常但深层链路失效时怎样定位断点
先给结论：入口正常而深层不收录，断点通常不在首页本身，而在“入口到深层页”的某一段链路。定位方法不是继续反复提交入口，而是把这条链路切成可验证的几段，逐段找第一个不再延续的位置。常见断点集中在三类位置：链接路径中断、抓取被拦、内容无法独立成立。
先分清两种解释：链路断在发现阶段，还是断在抓取与索引阶段
同一个现象背后至少有两种成立条件不同的解释，区分它们决定了下一步该修什么。
解释一：深层页没有被发现。入口页可访问，但通往深层页的链接是脚本生成的、被折叠隐藏的、或需要多步交互才出现，抓取端沿入口往下走时拿不到可跟随的链接。此时深层页从未进入待抓取队列，表现是日志里几乎看不到对深层 URL 的请求。
解释二：深层页被发现了，但抓取或索引被拦。链接能跟随，请求也发生了，但返回的是错误状态、被 robots.txt 限制、被登录或地域条件挡住，或者页面主体内容依赖某段失效的旧接口而渲染为空。此时表现是日志里有请求，但状态码异常或抓取后不进入索引。
这两种解释的修复动作完全不同：前者要修链接的可发现性，后者要修响应与内容本身。先判断属于哪一种，能避免在错误方向反复提交。
用能区分解释的证据缩小范围
不要只看“收没收录”这个结果，要看链路中间的过程证据。以下证据组合能有效区分上面两种解释：
- 抓取日志中的请求记录。深层 URL 是否出现过请求、请求频率、返回状态码。完全没有请求，偏向解释一；有请求但状态异常，偏向解释二。
- 入口到深层的链接是否可跟随。用禁用脚本的方式查看入口页，确认深层链接是否仍以可点击的
<a href>形式存在。若链接只在交互后才出现，抓取端很可能跟不到。 - 深层页的独立可访问性。直接请求深层 URL，看是否返回正常内容，还是被重定向、被拦截或返回空壳。
- 站点地图与实际链接的一致性。站点地图里列了深层 URL，不代表它会被抓取或收录；站点地图只是提交线索，不能替代可跟随的链接路径。
把这几项对照起来，通常能定位到第一个“链路不再延续”的位置。
按链路顺序做一次断点定位
可以按下面顺序逐段验证，遇到第一个不通过的位置就停下处理，而不是一次改多处：
- 入口页是否可达。确认入口返回正常，这是已知前提。
- 入口到深层的链接是否存在且可跟随。检查是否为静态可跟随链接，是否需要交互或脚本才出现。
- 深层 URL 是否被抓取。看日志中是否有对应请求。
- 抓取时返回什么。检查状态码、重定向链、是否被 robots.txt 限制。
- 抓取到的内容是否成立。确认主体内容不依赖已失效的旧接口或旧系统。
假设一个场景：某栏目入口页正常，但列表中的文章链接由前端脚本在滚动后加载，日志里几乎看不到文章 URL 的请求。按上面顺序检查，第 2 步不通过，断点就在“链接不可跟随”。此时把关键链接改为服务端可输出的可跟随形式，再观察日志中是否开始出现请求，就能验证判断是否正确。
退出旧内容、旧系统或旧合作关系时，先保留仍然有效的部分
这类断点常出现在旧内容、旧系统或旧合作关系需要退出的阶段。此时不要整段删除，而是先区分哪些深层页仍然有价值、哪些确实要下线。
对仍要保留的深层页，先保证它们从入口有可跟随的路径，再确认抓取时返回正常内容。对确实要下线的页面，处理方式要分清：
- 用 robots.txt 限制抓取，不等于可靠的索引移除。它只阻止后续抓取，已收录的结果可能仍会存在一段时间。
- 需要移除时，用明确的移除手段并核查实际状态，不要假设限制抓取就等于下线完成。
- 保留有价值的深层页时，优先修复通往它们的链接路径，而不是只把它们列进站点地图。
一个实际动作及其影响：先给保留的深层页补上从入口可跟随的静态链接，再观察日志中是否出现对它们的请求。如果请求开始出现且返回正常，说明断点在发现阶段并已修复，下一步转为观察索引状态；如果请求仍不出现，说明问题可能在上游的入口结构或抓取限制，需要回到第 2、4 步继续排查。
几个容易被误判的信号
定位时要注意，某些现象不能单独证明处理正确：
- 某段时间请求量归零，可能是抓取调度变化、服务器波动或缓存影响，不一定是链路被切断。
- 站点地图被读取，不代表其中的 URL 会被抓取或收录。
- 启用 HTTPS 不代表页面安全无漏洞，也不直接决定收录或排名。
- 不同搜索引擎对脚本渲染、站点地图和移除请求的支持情况不同，需要分别核查，不能用一个平台的表现推断另一个。
把链路切成可验证的段、用过程证据区分“没被发现”和“被抓取但没通过”，是这类问题最省返工的定位方式。找到第一个不再延续的位置，再决定是修链接、修响应，还是先处理旧内容的下线。
