为什么先看“渲染后还剩什么”

不少站点改版后用了前端框架或异步接口，浏览器里看起来一切正常，但搜索蜘蛛拿到的原始 HTML 里，正文位置可能只有一层空壳。抓取预算被消耗在“没有内容的页面”上，URL 发现速度也会跟着变慢。这类问题通常不报错，所以更需要主动自查。

第一步：关掉 JS 看源码

最直接的验证方式，是在禁用 JavaScript 的情况下访问几个代表性页面，或者直接查看网页源代码，确认下面这些内容是否存在于原始 HTML 中：

• 主标题与正文首段
• 核心内链，例如列表页、详情页、栏目入口
• canonical 标签以及分页的上一页、下一页关系
• 结构化数据里的关键字段

如果这些内容都要等脚本执行完才出现，就要评估搜索引擎能否顺利执行你的脚本。

第二步：确认脚本执行的代价

主流搜索引擎会执行 JS，但通常排在 HTML 解析之后，并且受时间延迟与配额限制。渲染队列积压时，页面可能长期停留在“待渲染”状态。常见影响因素包括：

• 脚本体积大、依赖多，首屏渲染耗时越长越不友好
• 第三方统计、广告、客服脚本阻塞主线程
• 接口返回慢，或需要登录态才能拿到数据
• 关键路径被 robots.txt 拦住，脚本或接口抓不到

把 robots.txt 里被屏蔽的 JS、CSS、接口路径列为重点排查对象，相当一部分渲染失败就是从这里开始的。

第三步：按三层做清单核对

内容层

• 标题、正文、发布时间、作者是否服务端渲染或预渲染
• 列表页的分页与筛选结果是否具备可抓取的链接结构
• 图片懒加载是否保留占位与 alt，避免出现空白图

链接层

• 导航、面包屑、相关阅读是否使用真实 a 标签，而不是纯 JS 跳转
• 点击事件绑定的元素是否同时提供了 href
• 前端路由是否配置了可被直接访问的静态路径

元信息层

• title、description、canonical 是否由服务端输出，避免渲染后再用脚本改写导致不一致
• hreflang 与分页标记是否随首屏一起返回

第四步：做一张源码与渲染对照表

挑 10 到 20 个有代表性的页面，首页、栏目页、详情页、分页第二页、带筛选参数的页面各取几个，把“源码中可见的内容”和“渲染后可见的内容”分别记下来。差异集中在哪一类页面、哪一类模块，那里就是优先修复的位置。这样比全站推倒重来更省成本，也更容易验证改动是否有效。

第五步：常见修复顺序

1. 关键内容改为服务端渲染或预渲染，至少保证首屏可读。
2. 脚本改为异步加载，减少主线程阻塞，压缩首屏渲染时间。
3. 列表与导航改为服务端输出的真实链接，避免纯 JS 分页。
4. 给详情页接口加缓存，降低渲染超时或失败的概率。
5. 修复后结合抓取日志观察目标 URL 的访问次数与状态码变化。

什么时候需要重跑一遍

模板改版、引入新的前端框架、更换 CDN、上线大型活动页，这几种情况都应该重跑一次清单。把每次的对照结果记录下来，既能看出趋势，也方便出问题时定位到具体改动。渲染自查不是一次性动作，更像上线前的一个固定开关，做顺了通常十几分钟就能走完。