很多站点改版之后，页面在浏览器里看着没问题，但抓取回来的 HTML 里几乎什么都没有：标题在，正文空，链接和图片全靠脚本在浏览器里现拼。对用户来说体验可能还行，对搜索蜘蛛来说，它拿到的就是一只空壳。这篇整理一套渲染方式自查的流程，确认“蜘蛛看到的”和“用户看到的”是不是同一份内容。
先分清三种常见的渲染方式
- 服务端渲染：请求到达服务器时就把完整 HTML 拼好返回，正文、链接、列表都在源码里。
- 客户端渲染：返回一个几乎空的 HTML 加一段脚本，内容由浏览器执行 JS 后再填充。
- 混合渲染：首屏由服务端输出，后续交互交给前端接管；或者部分区块静态、部分区块异步加载。
三种方式本身没有绝对好坏，问题出在“内容只存在于脚本执行之后”。蜘蛛的渲染资源有限，越依赖 JS、层级越深、外部请求越多，被完整执行的概率就越低。
自查：蜘蛛到底看到了什么
- 用浏览器的“查看网页源代码”，而不是“检查元素”。前者是原始响应，后者是渲染后的 DOM，两者经常对不上。
- 在命令行里用 curl 抓取目标地址，把返回内容存成文件再看，正文是否为空一目了然。
- 关闭浏览器 JS 后打开页面，能读到多少内容，就是保守估计下的可见量。
- 对照站长平台里的抓取与渲染诊断，看蜘蛛拿到的 HTML 快照和你看到的是否一致。
- 抽查多类模板：列表页、详情页、聚合页、站内搜索页，别只测首页。
哪些位置最容易出问题
- 正文由接口异步拉取，源码里只有一个空容器。
- 翻页和“加载更多”只改状态不改 URL，蜘蛛没有可跟随的地址。
- 导航和面包屑由 JS 注入，源码里找不到可爬的链接。
- 图片懒加载用脚本替换 src，源码里 src 为空或只是占位图。
- 首屏第三方脚本过多，渲染时间被拖长，蜘蛛抓了一半就放弃。
判断标准很简单：把 JS 全关掉，核心内容还在不在。不在，就说明这份内容对蜘蛛来说是不稳定的。
可以怎么处理
不需要整个站点推翻重做，按性价比排序处理即可。
- 把列表页、详情页这类需要被抓的模板改成服务端渲染或预渲染；交互复杂的后台、个人中心可以保持原样。
- 关键导航、面包屑、分页链接用真实的 a 标签输出，不要只挂点击事件。
- 分页和“加载更多”给出可直达的 URL，让翻页成为可发现的地址而不是一次性状态。
- 图片懒加载保留占位的同时，尽量让源码里存在可读的 src 与 alt。
- 减少首屏无谓的第三方脚本，给渲染留出时间预算。
排查节奏
渲染方式一旦定下来，后面很难频繁改动，所以建议放在改版或上新模板之前做一次。上线之后每隔一段时间抽查一轮，重点看新栏目、新模板有没有沿用旧写法。把“关闭 JS 后能否读到核心内容”当成一条固定验收项，比事后回头补要省力得多。
渲染自查解决的是“内容能不能被看到”，它不保证被收录，也不直接决定排名好坏，但它是后续所有优化能不能生效的前提。