有些页面用浏览器打开一切正常，右键查看源代码却只看到一段空容器。对访客来说没有区别，对抓取来说区别很大：首次返回的 HTML 里既没有正文，也没有链接，后面能不能补上，取决于对方愿不愿意为一个页面执行脚本。
渲染方式为什么会影响抓取
搜索引擎确实具备执行 JavaScript 的能力，但这件事有几个前提：脚本要能顺利加载、渲染有独立队列、渲染结果未必与真实浏览器完全一致。更重要的是渲染是有额度的，站点规模越大，越不可能每个页面都排队等着渲染完成。
如果你的内容发现也依赖页面里的链接，比如栏目页、列表页、聚合页，那么链接没有出现在首次 HTML 中，就会直接影响下一层 URL 的发现效率。入口页的正文如果也是空的，情况会更麻烦。
三步判断页面到底交出了什么
- 查看源代码，而不是审查元素。在页面上右键选“查看网页源代码”，搜索页面里一句正文文字。搜不到，说明正文不在首次返回的 HTML 里；如果连导航链接也搜不到，问题更明显。
- 临时关闭 JavaScript。在浏览器设置里禁用脚本后刷新页面，看还剩多少内容。这不是模拟搜索引擎，只是快速判断内容的兜底能力。
- 用命令行抓一次。命令行工具拿到的就是原始响应，不带任何渲染。对照一下标题、正文首段、主要链接是否齐全。
另外可以借助搜索平台提供的网址检查工具，看“已抓取的 HTML”与实际页面的差别。如果抓取版本里正文是空的，说明问题真实存在，而不是工具误差。
常见的几种渲染方式
- 服务端渲染（SSR）：服务器把 HTML 拼好再返回，正文和链接都在里面，对抓取最友好，代价是服务器压力相对高一些。
- 静态生成（SSG）：构建时生成 HTML，适合更新不频繁的栏目页、帮助文档、案例页。
- 客户端渲染（CSR）：首次返回接近空壳，正文和链接靠脚本补。内容型页面尽量别用这种方式，后台、个人中心之类不需要被抓取的页面则影响不大。
- 预渲染与动态渲染：给抓取方返回渲染好的版本、给访客返回正常版本。属于过渡方案，规则要维护好，避免两套内容不一致。
自查清单
- 列表页、栏目页里的文章链接，是否出现在首次 HTML 中。
- 正文首段、小标题是否能在源代码里搜到。
- 分页与“下一页”是真实链接，还是脚本点击事件。
- 面包屑、站点导航是否依赖脚本生成。
- 页面标题、描述是否由脚本写入，这类内容通常滞后。
- 首屏图片是否有真实的图片地址，而不是等脚本唤醒。
- 关闭 JavaScript 后，页面是否至少保留可读的正文和可点的链接。
- 同一批模板页面抽查两三个，确认不是个别问题。
从哪一步开始改
不必一上来就重写前端。可以先按影响面排序：
- 先处理列表页和栏目页的链接输出，让下一层 URL 能被正常发现。
- 再处理内容页的正文，至少保证首屏内容在服务端输出。
- 标题、描述、面包屑这类结构化信息，优先放在服务端模板里。
- 确因架构原因无法改造的，再考虑预渲染方案，并定期对比两套版本是否一致。
改动之后不要只看浏览器。用同样的三步再验证一遍：源代码、关闭脚本、命令行抓取，确认正文和链接真的回到了 HTML 里。这个过程不需要一次做完，先把最影响发现的页面处理掉，比全站铺开更实际。
渲染方式的调整通常不会立刻带来可见变化，它的价值在于把内容放回可被发现的位置。先把入口修好，再谈其他优化。