抓取和渲染是两步，第二步不一定发生
用前端框架搭建的站点，经常出现这种情况：浏览器里打开一切正常，查看网页源代码却只有一个空的容器元素和一堆脚本。搜索引擎蜘蛛第一次抓取时拿到的就是这份源码。多数主流搜索引擎具备执行 JavaScript 的能力，但这个执行发生在抓取之后的渲染环节，属于第二步。第一步和第二步之间，存在时间差、资源限制和失败的可能。
也就是说，能被抓取，不等于能被渲染；能被渲染，也不等于渲染结果和你看到的一致。把页面当成“反正搜索引擎会渲染”来处理，风险在于你无法确认第二步是否真的跑成功了。
先确认蜘蛛到底看到了什么
排查这类问题，第一步不是改代码，而是确认现状。几个成本很低的办法：
- 关闭浏览器 JavaScript，或者直接查看网页源代码，看首屏正文是否出现在 HTML 里。如果源码里找不到正文文字，那蜘蛛第一轮看到的大概率也是没有正文的版本。
- 用抓取工具或命令行拉取页面，确认返回的 HTML 与源码一致，排除本地缓存造成的错觉。
- 在搜索引擎站长平台里使用 URL 检查类工具，查看“已抓取的 HTML”与渲染后的截图。这一项能直接回答渲染有没有成功。
- 翻服务器日志，看蜘蛛是否请求了 JS 和 CSS 文件。如果日志里只有 HTML 请求、完全没有静态资源请求，渲染基本不可能顺利完成。
这几步做完，问题通常能定位在发现、抓取还是渲染中的某一环，而不是笼统地归因为不被收录。
几种典型的空壳情形
首屏内容全靠接口拉取
HTML 只负责挂载，标题、正文、价格、列表全部由接口返回后填充。接口一旦需要登录态、签名、特定来源校验，或者对高频请求做了限制，渲染就可能中断，页面在索引侧呈现为一个没有实质内容的页面。
关键的 JS 和 CSS 被 robots.txt 屏蔽
有的站点为了节省抓取资源，把脚本目录、样式目录甚至接口路径一起屏蔽掉。这个动作的本意通常是好的，但结果是渲染环节拿不到必要的资源，页面结构无法成型。除非确认这些资源对页面呈现没有影响，否则不建议屏蔽。
内容藏在交互之后
正文要点击“展开全文”、切换标签页、滚动到底部才加载。渲染工具不会主动去点按钮，这类内容在渲染结果里往往缺失。
渲染超时或报错
第三方脚本过多、接口响应慢、某个 JS 报错中断了后续执行，都会让渲染停在半路。这类问题在本地开发环境不容易复现，但在蜘蛛访问的链路上很常见。
改动的优先级：从确定性最高的做起
- 把首屏关键内容放进 HTML。标题、主正文、核心参数这类决定页面主题的内容，优先由服务端输出。这一步收益最直接，也最不依赖外部条件。
- 保证渲染必需的资源可被抓取。核对 robots.txt，确认 JS、CSS 以及渲染时需要调用的接口没有被误伤。
- 给关键内容加兜底。如果确实无法服务端渲染，至少用预渲染或静态化的方式，为内容页生成一份带正文的 HTML 版本。
- 减少首屏对外部脚本的依赖。统计、客服、营销脚本尽量异步加载，不要阻塞主内容的渲染。
- 用无 JS 环境定期自查。把这一步放进上线前的检查清单，比事后从索引里倒推问题要省事。
不是所有页面都值得投入渲染改造
服务端渲染、预渲染都会增加开发和维护成本，没有必要全站铺开。内容页、商品页、文章详情页这类承担索引任务的页面，优先级最高；登录后的个人中心、后台管理、一次性的活动页，通常不需要为索引做额外处理。取舍的标准很简单：这个页面是否希望出现在搜索结果里，且它的主要内容是否依赖客户端执行。
渲染能力是搜索引擎提供的一种便利，不是一份可以无限依赖的保证。页面越少依赖 JavaScript 才能呈现，抓取与索引之间的不确定性就越小。
如果你在日志里看到蜘蛛频繁访问 HTML 却几乎不请求静态资源，或者 URL 检查工具里渲染后依然空白，可以先从空壳这个方向查起，而不是急着调整别的东西。