现在不少站点是用前端框架搭出来的，页面在浏览器里看着正常，但右键查看源代码，body 里可能只有一个空的 div。蜘蛛第一次拿到的，往往就是这份原始 HTML。如果正文、链接、标题信息全靠脚本执行之后才出现，就等于把发现内容的门槛抬高了。这篇自查不讨论哪种技术方案更好，只关注一件事：蜘蛛实际拿到的页面里，有没有你要它看到的东西。
先确认蜘蛛看到的是什么
不要只在浏览器里看效果，那看到的是脚本执行后的 DOM，不是服务器返回的原始内容。几个低成本的动作可以先做起来：
- 查看源代码：右键选“查看网页源代码”，而不是“检查元素”。前者是服务器返回体，后者是渲染结果，两者经常差别很大。
- 命令行取页面：用 curl 拉一份 HTML，例如 curl -s https://example.com/page | head -50，看 title、正文关键词、主要内链有没有出现在返回体里。
- 抓取调试工具：各家搜索平台一般都有 URL 检查或抓取测试，可以对照抓取到的 HTML 与渲染后的结果。
- 关闭 JavaScript：浏览器禁用 JS 后刷新，没有脚本时剩下什么内容，一眼就能看出来。
几种渲染方式，风险点不一样
服务端渲染
服务器直接把完整 HTML 返回，蜘蛛拿到的就是你想给它的内容。要注意的是服务端多做一层渲染，首字节时间会变长，缓存和并发能力要跟上，否则抓取速度会明显变慢。
预渲染
对不常变的内容提前生成静态 HTML，再由前端接管交互。要确保预渲染版本和线上实际内容一致，别出现过期快照被蜘蛛长期保存的情况，内容更新后记得触发重新生成。
纯客户端渲染
原始 HTML 近乎空壳，正文、列表、内链都要等接口返回后才能拼出来。搜索引擎虽然也会排队做渲染，但渲染资源有限且有超时，页面层级越深，越容易被跳过。
自查清单
- 关键信息是否在原始 HTML 中：title、meta description、canonical、正文首段、主要小标题。
- 内链是否为真实的 a 标签 href，而不是 onclick 跳转或 div 绑定点击事件。
- 接口是否允许抓取：robots.txt 里被误屏蔽的数据接口路径，会让渲染阶段拿不到数据。
- 渲染是否依赖登录态、地区、cookie 等条件，这些条件蜘蛛通常不具备。
- 懒加载是否把首屏图片地址写在 data-src，而在无脚本时没有可用的 src。
- 分页、标签页、折叠内容是否只在点击之后才插入 DOM。
- 渲染超时：接口慢的时候，脚本还没执行完，抓取就已经结束了。
- 移动端与桌面端是否共用同一套渲染逻辑，避免一端正常、另一端空壳。
从服务器日志里找线索
页面抓取和接口请求通常会分别落在日志里。可以观察同一次访问中，页面 URL 之后有没有跟着对应的数据接口请求；如果只看到页面 URL，或者接口返回 403、500，说明渲染链路在某一步断了。这类问题往往只在特定目录或特定模板上出现，按路径分组统计比整体看更容易定位。
渲染只是让内容对蜘蛛可见，能不能被收录、排到什么位置，仍取决于内容本身和站点整体质量。自查的作用是排除障碍，不是替代内容建设。
相对稳妥的做法
优先保证首屏关键内容由服务端输出；把主要导航、面包屑、正文链接放在 HTML 里；前端路由配合真实可访问的 URL；数据接口对爬虫放开；给渲染结果加一层缓存。调整完之后，用同一批 URL 再跑一次对比，看看原始 HTML 里多出了什么、少了什么，比凭感觉判断靠谱。
渲染方式不是一次性决定的事。站点改版、换框架、新增栏目，都可能悄悄改变蜘蛛看到的内容。把它列进每次上线前的检查项，比等到发现收录下滑再回头排查要省事得多。