不少站点把正文、列表和分页都交给前端脚本生成，页面在浏览器里看起来完整，但蜘蛛第一次取回的 HTML 可能只有一个空容器。抓取阶段看到的版本和用户看到的版本不一致，后续的 URL 发现、内链传递都会受到影响。核对这件事的重点，是判断蜘蛛在渲染之前拿到了什么。
渲染前后是两套页面
抓取通常分两步：先取原始 HTML，再在必要时执行脚本渲染。第一步拿到的是服务器直接返回的内容，第二步才会看到脚本插入的节点。两步之间有时间差，也有资源与执行限制，并不是所有页面都会被完整渲染。
所以判断一个页面的可抓取性，要分别看两个版本：关闭脚本后的源码里有没有正文、有没有链接；渲染之后新增了哪些节点。只对比其中一边，很容易得出错误结论。
哪些内容最容易在渲染前丢失
- 首屏正文：内容通过接口异步获取，源码里只有骨架和占位符。
- 列表页链接：商品、文章列表由脚本循环生成，源码里没有任何 a 标签。
- 分页入口：加载更多是按钮事件，没有可点击的 URL。
- 延迟插入的内链：相关推荐、面包屑在滚动或延时之后才写入 DOM。
- 懒加载资源：图片真实地址写在 data 属性里，src 只是占位图。
服务端输出与前端渲染的取舍
并不是所有内容都必须放到服务端输出。判断标准可以简化成一条：这份内容是否承担 URL 发现和链接传递的职责。列表页的分页链接、详情页的正文与主要内链，属于抓取路径的一部分，放在源码里更稳妥；交互性强、与抓取路径无关的模块，可以留给前端。
如果整站是前端渲染，至少保证首屏关键内容能在原始 HTML 中出现，或者通过预渲染、服务端渲染生成静态结果。样式和脚本的加载顺序可以调整，但正文和链接不应依赖某个接口的返回速度。
按顺序核对
- 用关闭脚本的方式请求目标 URL，保存返回的源码，检查标题、正文段落、主要内链是否存在。
- 打开脚本执行后再对比一次，列出渲染新增的链接与文本，判断哪些属于抓取路径。
- 在服务器日志中筛选蜘蛛请求，观察同一次抓取是否伴随大量静态资源请求，这通常意味着走了渲染流程。
- 抽查渲染后才出现的链接，确认它们能否被单独抓取，避免只有渲染后才存在的影子入口。
- 对列表页、分页、筛选页单独核对，这几类页面最容易在渲染前变成空壳。
常见误区
第一个误区是把渲染当作万能方案：只要浏览器里能看到，就认为蜘蛛也能看到。第二个误区是只检查首页，忽略深层列表页。第三个误区是给所有页面都套上渲染，反而拖慢抓取节奏、占用更多资源，最终能抓到的页面数量可能下降。
核对的目标不是让页面变复杂，而是让抓取路径上的关键内容在第一时间就能被读到。
把渲染前后两个版本放在一起看，问题通常很直观：源码里缺了什么，抓取路径就断在哪里。按上面的顺序逐项核对，再决定哪些内容移到服务端输出、哪些保留在前端，改动会更有针对性。