页面在浏览器里看着完整，抓取到的 HTML 里却只剩一句“请开启 JavaScript”，这是不少站点改为前端渲染后遇到的典型问题。搜索蜘蛛虽然具备一定的渲染能力，但渲染是排在原始 HTML 之后的第二道工序，成本更高，触发条件也更苛刻。把入口和内容都押在渲染之后，等于给抓取人为加了一层不确定的门槛。
先分清两种缺失：入口缺失和内容缺失
排查前先把问题分类，否则容易在错误的方向上反复调整。
- 入口缺失：链接本身不在原始 HTML 中，蜘蛛拿不到 URL，也就谈不上抓取内容。
- 内容缺失：URL 能被发现，但原始 HTML 里没有正文，需要渲染后才出现。
入口缺失比内容缺失更严重。内容缺失最多是渲染环节没跟上，入口缺失则会让整批 URL 长期进不了发现队列。
用原始请求结果做基线
不要只依赖浏览器的“查看源代码”，部分框架在开发模式下会注入调试脚本，和服务端真实返回并不一致。更可靠的做法是发一次不带 Cookie 的普通 GET 请求，把响应体保存下来。
- 用命令行工具请求目标 URL，把原始 HTML 存成文件。
- 在文件里搜索目标链接的路径片段，确认链接是否存在于源码。
- 搜索正文首段的独有词句，确认内容是否在原始响应中。
- 与浏览器渲染后的 DOM 对比，列出差异部分。
常见的入口写法问题
- 用 onclick 或事件监听代替 a 标签的 href。
- href 写成 javascript:void(0) 或 #，真实地址藏在 data 属性里。
- 列表内容由前端请求接口后拼接，首屏 HTML 中没有任何链接。
- 分页和“加载更多”只做滚动触发，没有可抓取的静态分页地址。
内链尽量落在 HTML 里
内链是 URL 发现最稳定的通道。导航、面包屑、相关推荐、分页，这几类链接建议在服务端渲染时直接输出。即便主体内容需要 JS 渲染，链接这一层也值得单独做服务端输出。
如果使用预渲染或同构渲染，要检查预渲染服务是否对蜘蛛和普通用户返回一致的 HTML。部分配置会按 UA 分流，一旦规则写错，蜘蛛拿到的可能是空白壳页。
渲染能力有限，别把它当作默认通路
渲染有超时，有资源加载失败的可能，也会受页面体积影响。把关键内容放到渲染之后，等于把抓取的稳定性交给执行环境。
判断标准很简单：禁用 JavaScript 后打开页面，核心内容和主要链接是否还在。如果不在，说明这部分内容对抓取而言是奢侈品，而不是必需品。
用抓取日志验证修复效果
- 看目标目录的整体抓取请求量是否上升，而不是只盯单个 URL。
- 检查日志中的响应体大小，壳页通常体积很小且高度接近。
- 观察渲染请求与原始请求的比例是否在变化。
修复后不要期待立刻见效，URL 的发现和回访有自己的节奏，一般按周观察趋势更合适。重点看方向：原始 HTML 中的链接数、正文文本量、日志里的抓取覆盖是否在稳步增加。
小结
JS 渲染不是不能用，而是不该成为唯一通路。把链接放回 HTML，把核心内容保留一份服务端输出，再让渲染去做锦上添花的部分，抓取的确定性会明显提升。