很多站点把正文交给前端框架渲染，用户在浏览器里看到的是完整的，但搜索引擎第一次拿到的 HTML 里可能只有骨架。收录和索引建立在这份它实际看到的内容之上，两边对不上，就会出现收录慢、索引里内容残缺、用正文片段搜不到自己的情况。
抓取和渲染是两步，不是一步
搜索引擎通常先按 URL 抓一次原始 HTML，放进处理队列，之后再排队执行渲染——跑 JS、请求接口、拼出最终 DOM。索引大多以渲染后的结果为准，但渲染要消耗资源、有并发上限，所以这一步可能延后很久，也可能失败。
- 原始 HTML 里没有内容，只能进渲染队列等待；
- 渲染超时或报错，索引里的可能是半成品；
- JS 文件或数据接口被 robots.txt 挡住，渲染完依旧是空壳。
一个简单的判断标准：关掉 JS 再打开页面，还能看到主要内容吗？如果看不到，收录质量就取决于渲染队列的进度。
常见表现：收录了，但内容对不上
- 搜索结果里的摘要来自骨架屏文案或导航文字，不是正文；
- 拿页面里的一句原文去搜，找不到自己的页面；
- 上线很久才被收录，收录之后内容长时间停在旧版本；
- 网址检查里渲染正常，线上索引结果却是几个月前那一版。
先排查，再动手改
- 用查看源代码或命令行请求，确认原始 HTML 里关键内容是否直出；
- 在搜索后台的网址检查里看渲染后的 HTML 和截图，对比接口是否被拦截；
- 打开抓取统计，看 JS、CSS、接口请求有没有大量 4xx、5xx 或被屏蔽；
- 关掉 JS 访问一次，确认核心内容是否仍然可见。
能落地的处理顺序
1. 关键内容直出
列表页、详情页里决定页面价值的字段，比如标题、正文、价格、发布时间，尽量在服务端渲染或构建时生成，让原始 HTML 里就有。交互、推荐、评论区这类次要区块可以继续留给前端。
2. 预渲染与降级
架构暂时改不了，可以做预渲染，或提供一份不依赖 JS 的静态版本。但要注意别让预渲染结果和真实内容变成两套，否则又会引出内容不一致的问题。
3. 打通渲染需要的资源
- 不要把 JS、CSS 文件写进 robots.txt 的 Disallow；
- 数据接口尽量用 GET，可直接请求，不依赖登录态和复杂签名；
- 内容别只在滚动、点击、切 Tab 之后才加载；
- 分页和详情入口用可抓取的 a 标签链接，不要用纯 JS 跳转。
两个容易忽略的点
其一，渲染是有成本的，别指望每一层页面都能等来渲染。首页、栏目页、重要详情页优先直出，长尾页面靠内链和 sitemap 帮助发现，但要接受它的收录节奏更慢。
其二，被发现、被收录并不等于进入可用索引。渲染结果太差时，即使 URL 出现在报告里，也难有稳定展现。与其盯着收录数字，不如定期抽查：索引里的内容和线上内容是否一致。
最后留一个自检动作：每隔一段时间，从索引里随机抽几条 URL，关掉 JS 打开，看还剩多少有效信息。剩得越多，收录这件事就越不依赖运气。