很多人排查收录时会盯着服务器日志：蜘蛛来过，状态码 200，响应也正常，可索引里就是查不到这个 URL。如果站点是前端渲染的，问题往往不在“有没有被抓”，而在“抓到的那份 HTML 里到底有没有内容”。
抓取、渲染、索引是三件不同的事
搜索引擎处理一个 URL，大致会经历：抓取原始响应、排队执行脚本完成渲染、从渲染结果里提取正文和链接、再判断这个页面是否值得进索引。如果原始 HTML 里只有一个空容器和一堆脚本，蜘蛛第一次拿到的就是一份“没有内容的页面”。渲染是异步排队的，快则几分钟，慢则很久，站点权重、页面数量、渲染成本都会影响等待时间。
所以“抓取成功”只说明第一段路走通了。真正决定收录的是后面几步：渲染有没有排上、渲染后有没有拿到有效正文、拿到之后是否被判定为值得收录。
哪些写法最容易卡在渲染这一步
- 正文完全由脚本请求接口后插入，HTML 里没有任何兜底文字。
- 列表页、分类页的内链靠脚本生成，原始 HTML 里没有可点的链接。
- 图片懒加载，占位区域里既没有说明文字也没有替代文本。
- 用无限滚动代替分页，内容没有对应的独立 URL。
- 折叠块、切换标签里的内容只在交互后才加载。
这些写法不一定直接导致不收录，但会让 URL 发现和内页抓取变得不稳定。尤其是靠脚本生成的链接，蜘蛛必须先执行脚本才能看到，等于把 URL 发现的时点往后推了一步。
自查时先看关掉脚本之后剩什么
比猜更有效的办法是对比：用浏览器的开发者工具禁用 JavaScript 后刷新页面，或者用只取原始 HTML 的方式抓一次，看看还剩什么。如果标题、正文、内链都不见了，说明整站的关键信息都压在渲染上。
再配合两件事：一是看日志里这些 URL 是否在渲染后被二次抓取，二是用站内或站长工具查具体 URL 的索引状态。两边对照，大致能分清是“没抓到”“抓到了没渲染”，还是“渲染了但没被收录”。
处理顺序上的几点建议
- 先保证正文和内链出现在 HTML 里。主要文字、面包屑、分页链接、栏目入口，尽量由服务端直接输出。这一步的收益通常大于其他优化。
- 再保证入口可达。没法服务端渲染的部分，至少让 URL 能从普通链接点到，不要只挂在点击事件上。
- 渲染方式按成本来选。服务端渲染、静态生成、预渲染都可以用，动态渲染可以作为过渡，不建议长期依赖，因为各引擎的支持程度并不完全一致。
- 给列表页留一个可抓结构。无限滚动可以保留浏览体验，同时提供传统的分页 URL 作为兜底。
- 改完别急着下结论。重新抓取、重新渲染、重新判断都需要周期，用同一批 URL 做前后对比，比看单次结果可靠。
渲染不是收录的替代方案。搜索引擎愿意执行脚本，但执行脚本的成本远高于直接读 HTML，所以“已经写在 HTML 里的内容”始终比“需要算出来才知道的内容”更稳。
三个常见误区
用了框架就一定会出问题
不一定。问题不在框架本身，而在于有没有把内容输出到 HTML。同样是单页应用，做了服务端渲染和只挂一个空容器，结果差别很大。
检测工具里能看到内容，蜘蛛就能看到
不少检测工具自己会执行脚本，所以显示正常。要区分“渲染后能看到”和“原始 HTML 里就有”，这两件事对抓取的意义不同。
收录慢就先加大抓取量
如果页面本来就要渲染后才有内容，堆抓取量只会让蜘蛛反复取回一堆空壳。先把能读到的内容补齐，再谈抓取入口和频次，顺序反了效率会很低。
总体来看，依赖脚本渲染的站点，收录问题多数不是“蜘蛛不来”，而是内容出现在蜘蛛能读到位置的时机太靠后。先让原始 HTML 有内容、有链接，再去核对抓取和索引状态，排查思路会清楚很多。