越来越多站点用前端框架搭建，页面在浏览器里看着完整，但交给搜索引擎的原始 HTML 可能只有一个空 div 和一段脚本。蜘蛛并不总是执行 JavaScript，即便执行，也有渲染队列和超时限制。这份自查清单，帮你在上线前后确认一件事：蜘蛛看到的和用户看到的，是不是同一个页面。
蜘蛛看到的和你看到的，可能不是同一个页面
浏览器打开页面，脚本跑完，内容填进来，一切正常。查看源代码，却是空的。搜索引擎抓取通常分两步：先取原始 HTML，再排队渲染。第二步不是必然发生，也可能延迟数天。所以把关键内容只交给客户端渲染，等于把可见性押在一个不确定的环节上。
第一件事：确认抓取结果长什么样
- 用 curl 或“查看网页源代码”看原始 HTML，不要看开发者工具里的 Elements 面板，那里是渲染后的 DOM。
- 用搜索引擎提供的 URL 检查工具，对比“已抓取的 HTML”和“渲染后的 HTML”。
- 在抓取日志里看返回字节数。列表页只有几 KB，而正常情况下应该有几十 KB，往往就是空壳。
关键内容要能脱离脚本存在
标题、正文、内链
页面标题、H1、主体正文、面包屑、主导航链接，尽量由服务端直出。这些是搜索引擎理解页面主题和站点结构的基础，不该依赖脚本执行完毕才出现。
用真链接，而不是点击事件
用 a href 指向真实 URL，不要用 div 加 onclick，也不要用 hash 路由来跳转。蜘蛛跟着 href 走，跟着脚本走不一定。如果用了前端路由，保证直接访问深层 URL 也能返回对应内容，而不是落到 404 或首页。
渲染时机与超时
如果必须客户端渲染，把首屏内容的请求放在最前面，别等用户交互、滚动到底部，或者某个统计脚本返回后才发起。渲染时间过长，蜘蛛可能在超时后放弃，留下一条“已抓取但内容为空”的记录。
图片与懒加载
懒加载优先用原生 loading="lazy"，或至少保证首屏图片不带 lazy。用脚本动态插入 src 的图片，可能永远不出现在抓取结果里。图片本身也别忘补 alt。
预渲染、SSR 与静态化的取舍
- 内容型页面（文章、商品、栏目）优先考虑服务端渲染或静态生成，改动成本一次，收益长期。
- 交互密集的后台页、工具页，客户端渲染问题不大，本来也不需要被抓。
- 预渲染适合页面数量不多、更新不频繁的站点，注意构建后要有机制触发重新生成。
- 无论选哪种方案，保持同一套 URL，别让渲染方案变更顺带改了地址结构。
几个常见误区
- “浏览器能打开就行”——用户能打开，和蜘蛛能拿到，是两回事。
- “提交了站点地图就没事”——地图只告诉地址，不解决内容为空。
- “先上线再说”——空壳页面会被抓取记录，之后再补渲染，还要等下一轮。
可以照做的检查顺序
- 挑 5 到 10 个代表性页面：首页、栏目页、详情页、分页。
- 逐个查看原始 HTML，确认核心文字和内链是否可见。
- 对比渲染前后的 HTML，找出差异最大的模块。
- 检查导航与列表是否为真链接，直接访问深层 URL 能否正常返回。
- 检查懒加载与图片资源是否可抓。
- 在抓取日志和站长工具里复核，记录改动前后抓取体积的变化。
判断标准很简单：把 JavaScript 关掉，页面还剩下多少有用信息？剩下的那部分，才是蜘蛛稳定能拿到的部分。
小结
客户端渲染本身不是错，把关键内容全押在渲染之后才是风险。先让标题、正文、内链这些基础信息在服务端可见，再逐步优化渲染性能和加载顺序，站点结构对蜘蛛来说会清晰得多，排查问题也更容易定位。