越来越多的站点由前端框架驱动，页面要等浏览器跑完 JavaScript 才算完整。对用户来说这没什么问题，但对搜索蜘蛛来说，中间多了一道门槛：如果渲染环节出问题，它拿到的可能只是一个空壳 HTML，正文、链接、发布时间、价格全都不在里面。
先分清三种“看到的页面”
排查之前得先统一口径。同一个 URL 至少存在三种形态：
- 原始 HTML：服务器直接返回的源码，右键“查看网页源代码”看到的内容。
- 渲染后的 DOM：浏览器执行完 JS 之后的结构，开发者工具 Elements 面板里看到的通常是这个。
- 蜘蛛实际抓到的版本：取决于它的渲染能力和渲染时机，可能接近第一种，也可能接近第二种，还可能介于两者之间。
很多误会都来自拿第二种去判断第一种：开发者工具里明明有内容，源码里却空空如也。
自查清单
1. 用源码视图，而不是元素视图
打开一个典型内容页，右键选择“查看网页源代码”，然后在页面里搜索一段正文文字。搜不到，说明内容靠 JS 注入，属于典型的客户端渲染场景。栏目页、详情页、分页、面包屑都要分别检查一遍。
2. 关掉 JS 再看一遍
浏览器禁用 JavaScript 后重新加载页面。如果只剩下导航和页脚，说明整个主体内容都绑在脚本上。不是所有站点都必须做服务端渲染，但至少要让核心的标题、正文、主要链接在无 JS 情况下可见。
3. 确认数据接口是否被拦
内容通过接口异步拉取时，要检查接口本身是否允许抓取。有些站点在 robots.txt 里屏蔽了 /api/ 之类的路径，或者接口要求特定请求头，结果页面壳能拿到，数据拿不到。
4. 检查 JS 和 CSS 是否可被抓取
渲染依赖脚本资源。如果 robots.txt 屏蔽了 JS、CSS 文件所在目录，或者这些资源返回 403、404，渲染过程就无法完成。这一点很常见，也很容易被忽略。
5. 看渲染触发的时机
不少内容是点击、滚动、切换标签之后才加载的。对用户是交互，对蜘蛛就是一道墙。重要内容尽量在首屏渲染时就出现，不要等滚动到底部或点了“加载更多”才生成。
6. 注意超时与资源体积
渲染是有时间预算的。如果首屏要串行等待三四个接口、加载几个大体积脚本，蜘蛛可能等不到内容出现就结束了。压缩脚本、减少串行请求、把关键内容提前，都能提高渲染完成率。
几个常见的坑
- 懒加载图片但占位地址为空：真实地址放在 data-src 里，脚本没执行就等于没有图片。
- 前端路由缺少服务端响应：单页应用内部跳转正常，但直接访问深层 URL 返回空壳或错误状态。
- 内容藏在弹窗或折叠面板里：默认不展开就不渲染。
- 动态插入的 canonical 或 meta：脚本执行失败时，这些标签直接缺失。
- 测试环境开关误上线：某些渲染降级配置随版本发布到了生产。
排查和修复的先后顺序
- 先定范围：全站是纯客户端渲染，还是只有少数模块依赖 JS。
- 再定优先级：首页、栏目页、核心详情页优先，边角页面可以往后放。
- 然后选方案：服务端渲染、预渲染、静态生成，或者退一步，把关键内容直接写进 HTML。
- 最后做验证：改完后用源码视图复查，并观察一段时间的抓取日志，看渲染相关请求有没有变化。
不要指望“蜘蛛很聪明，它会自己跑 JS”来解决结构问题。能靠 HTML 说清楚的事，尽量不要留给脚本。
JS 渲染自查不是一次性动作。前端框架升级、打包策略调整、第三方脚本引入，都可能悄悄改变页面的最终形态。把它放进改版和上线的检查清单里，比出问题之后再回头翻日志要划算得多。