先分清三种渲染方式
同一个页面，用户和爬虫拿到的 HTML 可能完全不同。先确认自己的页面属于哪一类，再谈收录，判断会稳很多。
- 服务端渲染（SSR）：请求返回的 HTML 里就带正文，爬虫不需要执行脚本。
- 预渲染或同构：首屏在服务端或构建时生成，后续交互交给 JS 接管，初始 HTML 里通常已经有主体内容。
- 纯客户端渲染（CSR）：返回的 HTML 只有一个空壳和几个 script 标签，正文要等 JS 执行、接口返回数据之后才出现。
收录表现的差距主要来自这里。CSR 页面要经过两步处理：先抓 HTML，再排队渲染。渲染失败、超时或被拦截，最终进入索引的可能就是一个空壳。
核对顺序：先看抓到的 HTML，再看渲染后的结果
- 禁用 JS 打开页面，或直接查看网页源代码，确认标题、正文、主要链接是否出现在初始响应里。
- 检查状态码、canonical、meta robots 是否由服务端输出。这些信号如果靠 JS 注入，很容易在渲染环节丢失。
- 确认渲染所需的数据接口没有被 robots.txt 拦住。接口路径被屏蔽，等于正文永远拿不到。
- 对比渲染后的 DOM 与接口返回的数据，看有没有因为登录态、地区判断或灰度策略返回空内容。
- 回到抓取日志，看蜘蛛请求的是完整页面，还是只带走了那份空壳 HTML。
抓取与收录在这里最容易混在一起
日志里看到蜘蛛来过，只能说明它抓住了那份 HTML。是否入库还取决于渲染这一步能不能拿到足够的主体内容。如果初始 HTML 里没有正文，渲染又依赖大量脚本和串行接口，页面很可能长期停在“已发现”，或者干脆不进索引。这不是抓取失败，而是抓到的版本没有可用内容。
渲染成本与抓取预算
搜索引擎渲染页面是有成本的，通常不会对每个 URL 都完整渲染一遍。页面越依赖 JS，站点整体被渲染的比例就越低，新页面等待入库的时间也更长。可以从这几处收敛：
- 首屏关键内容尽量服务端直出，交互部分再交给 JS。
- 减少首屏接口数量，避免多层串行请求。
- canonical、hreflang、结构化数据优先写在服务端输出的 HTML 里。
- 图片懒加载用原生 loading 属性，别让正文块在脚本执行后才挂载。
短时间内改不动框架怎么办
如果站点是纯前端框架搭的，短期改不成 SSR，可以先做预渲染：对内容型 URL 在构建或请求时生成静态 HTML，交互页保持原样。这样至少让标题、正文、canonical 出现在初始响应里，收录核对才有稳定的基准可对比。
判断标准很简单：禁用 JS 后打开页面，如果核心正文、标题和主要链接都还在，收录核对就少一层变量；如果只剩下一个空白容器，那就先把渲染问题解决，再谈其他收录优化。
小结
核对渲染类页面的收录，顺序是先确认抓到的 HTML 里有什么，再确认渲染后能拿到什么，最后看日志与索引状态是否能对上。把“抓到了”和“内容够不够入库”分开看，很多看似矛盾的现象就说得通了。