现在不少页面依赖 JavaScript 来拼装内容：导航由组件渲染，列表从接口拉取，正文也可能在客户端才注入。对用户来说这没什么问题，但对搜索引擎来说，蜘蛛第一次拿到的往往只是一个骨架 HTML。如果内容只存在于渲染之后，收录的判断就会整体往后拖。
蜘蛛其实会看到两份页面
理解这个问题，先要分清两份东西：
- 原始 HTML：服务器返回的第一版，通常只有 head、少量占位节点和脚本引用，正文位置是空的。
- 渲染后的 DOM：搜索引擎用无头浏览器执行 JS 后得到的版本，这才是它真正拿去判断内容的版本。
两份之间的差异越大，从抓取到进入索引之间隔的时间通常越长。抓取成功并不等于收录，渲染失败或渲染结果为空，页面都会停在索引之外。这也是抓取与收录最容易被混为一谈的地方。
容易卡住的几个位置
初始 HTML 里几乎没有正文
- 正文完全靠 JS 注入，初始 HTML 里只有一个空容器；
- 文章列表由接口返回，HTML 中没有任何链接；
- 标题、描述、结构化信息也在客户端拼装。
这种情况下，页面能否被理解，几乎全押在渲染这一步上。
渲染要用的数据被挡住了
如果 robots.txt 屏蔽了接口路径，或者接口需要登录态、特定请求头、特定来源，渲染器拿不到数据，渲染出来的就是空壳。这属于站点自己阻断了自己，和内容质量没关系，但表现上会被当成收录问题。
内容要交互才出现
点击“展开更多”、切换标签页、滚动到页面底部才加载的内容，渲染器不一定会执行这些动作。未触发的那部分内容，基本不会被纳入判断范围，链接也同样不会被发现。
渲染超时或资源阻塞
首屏脚本太重、第三方资源长时间不返回、渲染队列等待过久，都可能让渲染被提前结束，拿到的只是半成品。表现就是：同一个页面，有时能收录，有时迟迟不动。
怎么判断自己是不是这种情况
- 用平台自带的 URL 检查工具，对比“已抓取的 HTML”和“渲染后的 HTML”，看正文是否真的出现；
- 在浏览器里关闭 JavaScript，或直接查看页面源代码，确认核心内容是否存在于初始 HTML；
- 看服务器日志里该 URL 的抓取频次、返回状态和资源请求情况，判断是否有接口请求失败；
- 抽查一批核心页，不要只看首页或某一个模板。
处理顺序建议
- 优先让核心内容页做到服务端渲染或预渲染，至少保证正文和主要内链出现在初始 HTML 中；
- 把主内容、面包屑、分页链接这类用于 URL 发现的元素放在初始 HTML，而不是等脚本补上；
- 检查接口是否被 robots 规则挡住，确认渲染器能正常取到数据；
- 精简首屏脚本和第三方依赖，减少渲染超时的概率；
- 以上都确认后，再谈 sitemap 提交和内链引导，顺序反了容易白等。
sitemap、内链、外链解决的是“让蜘蛛知道并找到 URL”；页面能不能进索引，还要看渲染出来的内容是否可读、是否有独立价值。两件事分开看，排查才不会被带偏。
如果你的站点收录数字长期偏低，又刚好是前后端分离的架构，建议先把渲染这条链路走通再看别的原因。很多看起来像收录策略的问题，源头其实在内容根本没被渲染出来。