有时会遇到这种情况：某个 URL 已经出现在搜索结果里，标题也正确，但摘要和正文是空的，或者只剩导航和一行占位文字。点进去看页面是正常的，因为浏览器执行了 JavaScript。问题不在“有没有收录”这一步，而在抓取之后的渲染环节。
抓取到的版本和渲染后的版本，不是同一份
搜索引擎先按 URL 请求服务器，拿到原始 HTML。如果正文是页面加载后由 JS 写进 DOM 的，原始 HTML 里就只有空容器。之后这批 URL 会进入渲染队列，用无头浏览器再跑一遍，这时才可能看到完整内容。
关键在于，渲染是排队执行的，不是抓完立刻渲染。队列有优先级，页面越重、依赖越多，等待越久；渲染失败、超时或中途报错，索引里留下的就可能是那份原始 HTML 的版本。
几个常见原因
- 正文完全由 JS 注入：不执行脚本的抓取看不到任何内容。
- JS、CSS 或接口路径被 robots.txt 挡住：渲染需要自己去请求这些资源，被禁止抓取后就拿不到数据。
- 内容要交互才出现：点标签页、展开折叠、滚动到一定位置才加载。
- 请求依赖登录态或特定请求头：渲染请求通常不带用户会话。
- 超时或资源过重：首屏脚本太大、串行请求太多，渲染在超时前没跑完。
- 前端报错：接口结构变化、跨域限制、版本不匹配，页面渲染到一半停住。
自查顺序
- 用 URL 检查类工具对比“原始 HTML”和“渲染后的 HTML”，看正文是否出现在后者里。如果两边都空，问题在数据层，不在渲染层。
- 禁用 JS，或用 curl 直接请求该 URL，看返回的 HTML 里有没有正文。这一步最直观。
- 检查 robots.txt 是否误封了 JS、CSS、图片或接口路径，这是最常见的隐性原因。
- 检查接口返回是否依赖时间、地区、登录态或随机参数。
- 看渲染日志与页面性能：首屏脚本体积、外部请求数量、有没有长时间阻塞。
处理方向
核心内容尽量在服务端输出：标题、正文、价格、主要链接直接写在 HTML 里。交互增强的部分可以继续用 JS 做，但不应该由它决定页面“有没有内容”。
需要滚动或点击才加载的列表，尽量保留一组可抓取的分页 URL，而不是只有无限滚动。
noscript 里放一段提示，不能替代真正的服务端输出，抓取工具也不会把它当成正文的备选。
如果正文只有执行脚本后才存在，就别把“是否收录”当成唯一指标——索引里的内容是否完整，需要单独核对。
最后一句
收录只说明 URL 进了索引，不代表索引里的内容可用。对依赖前端框架的站点，建议把“渲染后的 HTML 是否包含正文”列为固定检查项，尤其在改版、换框架或调整接口之后。