用浏览器打开页面，标题、正文、相关推荐一应俱全；把 JavaScript 关掉再刷新，屏幕上可能只剩一行导航和一个转圈的图标。这种差异在前端框架普及之后变得很常见，也是站点运营里容易被忽略的一环。
为什么会出现「两个版本」的页面
蜘蛛抓取页面时，拿到的是服务器返回的原始 HTML。如果正文、内链、图片地址都靠脚本在浏览器里动态生成，那么第一次抓取得到的就只是一份骨架。搜索引擎虽然普遍具备渲染能力，会排队执行页面脚本再抓一次，但这个过程有成本、有延迟，也不是每个页面都能被完整渲染。
结果就是：用户看到的页面没问题，蜘蛛看到的页面却可能缺内容、缺链接，进而影响 URL 发现和内容理解。
先搞清楚你的页面属于哪种渲染方式
- 静态生成：构建时就把 HTML 生成好，蜘蛛拿到什么、用户看到什么，基本一致，最省心。
- 服务端渲染（SSR）：每次请求在服务器拼好 HTML 再返回，首屏内容通常完整，需要关注服务器压力与缓存策略。
- 客户端渲染（CSR）：HTML 里基本是空容器，内容由浏览器执行脚本后填充，抓取风险最高。
- 混合与动态渲染：部分内容服务端输出，部分由脚本补齐，需要逐块确认。
大部分站点并不是单一模式，往往首页是 SSR、列表页是 CSR、详情页又是另一种。自查时要按模板类型分别看，而不是抽查一个页面就下结论。
自查清单：确认关键内容真的能被读到
- 关掉 JavaScript 打开页面。浏览器开发者工具里可以禁用 JS，或者用命令行工具直接请求 URL，看返回的原始 HTML 里有没有正文、标题和主要内链。
- 看首屏关键内容是否在 HTML 中。文章正文、商品信息、栏目名称这类决定页面主题的内容，最好在原始 HTML 里就能看到，而不是等脚本执行完才出现。
- 检查内链是不是脚本生成的。如果导航、相关阅读、分页链接都由 JS 渲染，蜘蛛可能读不到这些链接，URL 发现效率会明显下降。
- 确认 JS 和 CSS 文件没有被 robots.txt 挡住。渲染依赖这些资源，挡住它们等于让渲染直接失败。
- 检查接口请求是否被拦。部分站点会屏蔽接口路径，如果页面内容靠接口返回，这条规则要重新评估。
- 观察渲染等待时间。脚本执行时间过长、依赖多个第三方请求时，渲染可能中途超时，留下不完整的页面。
- 避免「点了才出现」的内容。折叠区块、标签页切换、滚动到底才加载的模块，对用户是体验，对蜘蛛可能是空白。
几个务实的处理方向
不是所有页面都必须做服务端渲染，但决定页面主题和层级关系的部分，值得优先保证。
- 核心内容优先服务端输出：标题、正文、主要内链、面包屑放进原始 HTML，收益最直接。
- 谨慎使用懒加载：图片和次要模块可以延迟，正文和链接不建议。
- 保留无脚本兜底：可以用 noscript 标签提供基础内容或链接，至少让蜘蛛知道页面讲了什么。
- 控制第三方脚本数量：统计、客服、广告脚本过多会拖慢渲染，也增加渲染失败的概率。
- 改版时同步验证：换了前端框架后，抓取表现往往要过一段时间才反映出来，别等索引掉了才回头查。
怎么持续确认没有退化
单次自查只能说明当下，站点运营更需要一个轻量的观察习惯：
- 按模板类型各挑一两个代表页面，定期用无 JS 方式请求一次，对比原始 HTML 是否还包含关键内容。
- 结合服务器日志看蜘蛛请求的返回状态和抓取量变化。如果某个目录的抓取量突然下降，先怀疑渲染问题或资源被屏蔽。
- 上线新栏目、换主题、加新脚本时，把「原始 HTML 自查」写进发布清单，成本很低，但能挡掉不少问题。
渲染方式的差别不会立刻体现在报表上，它更像一种慢慢积累的损耗：内容还在，链接还在，但蜘蛛能读到的部分越来越少。定期用最笨的方式看一遍页面，往往比事后排查索引问题省事得多。
站点运营不需要人人都懂前端框架，但至少要能回答一个问题：把脚本关掉之后，这个页面还剩多少信息。这个问题答得清楚，很多抓取和收录上的困惑也就有了方向。