不少站点改版到前端框架之后，页面在浏览器里看起来一切正常，但把 HTML 源码拉出来，正文、标题、链接全都不在，只有一个空的挂载节点和几行脚本。对访客没有影响，对依赖 HTML 抓取的程序来说，这个页面基本就是一张空白纸。这篇文章说的就是怎么自查这件事。
为什么渲染方式会影响抓取
抓取大致分两步：先拿到 HTML 源码，再决定要不要排队执行页面里的 JavaScript，拿到渲染后的内容。第二步成本高、有延迟，而且不同引擎的执行能力、队列长度、超时时间都不一样。如果页面完全依赖客户端渲染，关键内容在一段时间内可能只以空壳的形式被看到。
这不是收录与否的保证问题，而是内容送达难度的问题。页面能少一层依赖，就少一层不确定性。
怎么判断自己的页面属于哪种情况
最简单的方法不是打开开发者工具看 Elements 面板，那里显示的是渲染后的结果，看不出问题所在。
- 在浏览器里右键查看网页源代码，搜索正文里的一个关键词，看它在不在。
- 用命令行抓一次，例如 curl 页面地址，把输出保存下来再搜索关键词。
- 把 JavaScript 关掉再打开页面，观察首屏是否还有主要内容。
- 用搜索引擎提供的抓取测试工具，对比原始 HTML 与渲染后 HTML 的差异。
常见的几种空白表现
- 正文全部由接口返回后插入，源码里只有加载占位。
- title、description、canonical、h1 由脚本运行时写入，源码里是默认值或者干脆没有。
- 列表页用无限滚动，翻页不是真正的链接，第二页之后的内容很难被逐层跟随。
- 首屏图片用了懒加载，真实地址写在 data-src 上，src 是占位图，抓取时拿不到图片。
- 路由使用 hash 形式，多篇不同内容共用同一个可抓取地址。
- 内链是按钮加点击事件，页面上看得见点得动，但没有可跟随的链接。
一份可以照着做的自查清单
- 对一个典型详情页执行原始抓取，确认正文首段、小标题是否存在于源码中。
- 分别检查首页、栏目页、详情页三类模板，不要只测一个页面。
- 确认 title、h1、canonical 在源码里就已经是最终值，而不是脚本补上的。
- 检查分页与列表入口是否为可点击、可跟随的链接，而不是纯 JS 事件。
- 检查首屏图片的真实地址是否直接出现在 img 标签的 src 中。
- 确认 robots.txt 没有拦截承载内容的 JS、CSS 文件，否则渲染本身就会失败。
- 检查接口请求是否依赖登录态或特殊请求头，抓取时是否返回空数据。
- 检查渲染后页面的内容与 canonical、结构化数据是否一致，避免出现两套内容。
处理顺序建议
如果自查发现问题，不必一次性大改，可以按投入产出排序：
- 先把首屏关键内容服务端输出，比如标题、正文前几段、主要链接，这一步收益最大。
- 把详情页、列表页的分页链接改回真实链接，保证能逐层被跟随。
- 页面路由尽量使用普通路径，避免把内容藏在 hash 后面。
- 短期做不到服务端渲染，可以考虑预渲染或静态生成，先把已发布内容渲染成 HTML。
- 动态渲染只作为过渡方案，注意给用户和抓取程序的内容要保持一致。
给抓取程序看的内容和给用户看的内容必须一致。为爬虫单独准备一套简化页面，短期也许有效，但一旦被识别为伪装，代价远大于收益。
把它放进上线流程
渲染方式的问题往往在改版时集中出现：以前是模板直出，重构后变成前端渲染，页面看起来更现代了，内容却变得难抓。建议在发布清单里加一条：新模板上线前，用原始抓取的方式检查一遍源码，确认关键内容、链接、标题都在里面。这一条检查花不了几分钟，但能省掉后面几周反复排查的时间。