不少站点把正文和导航交给前端框架渲染，浏览器里看一切正常，但搜索蜘蛛第一次请求时拿到的往往只是一个空壳容器。抓取和收录之间隔着渲染这一步，如果渲染没有被执行，或者渲染结果里缺少关键信息，页面就可能在“已发现”“已抓取未编入索引”这些状态上长期停留。
抓取时先看到的是原始 HTML
蜘蛛请求一个 URL 时，拿到的是服务器直接返回的 HTML 源码。脚本、样式、接口数据会在之后由渲染环节处理。这个环节可能被排队，也可能因为资源被 robots.txt 拦截、接口超时或脚本报错而失败。因此判断一个页面对收录是否友好，第一步不是看浏览器，而是看“不执行 JS 的原始响应里还剩什么”。
三类最常见的 JS 收录问题
正文由脚本注入
如果文章主体靠接口返回数据再插入 DOM，原始 HTML 里只有空标签，蜘蛛在渲染前看到的正文接近为空。这类页面容易被当作低质量或空白页处理，即使后来渲染成功，早期信号也可能已经影响了判断。
链接由脚本生成
导航、列表页、相关推荐如果用脚本拼接链接，或者只绑定点击事件，原始 HTML 里就没有可跟随的 href。URL 发现的入口被卡住，新页面进入抓取队列的时间会明显拉长，收录节奏自然跟着慢。想让 URL 稳定被发现，服务端输出的内链和 sitemap 仍然是主要渠道。
元信息由脚本写入
canonical、robots meta、hreflang 这类指令如果由脚本在渲染后插入，能否被正确读取存在不确定性。索引归属和抓取控制都依赖这些信号，最好直接写在初始 HTML 的 head 里。
自查方法
- 用 curl 或浏览器的“查看网页源代码”，确认不执行 JS 时能否看到标题、正文摘要和主要链接。
- 对比原始 HTML 与渲染后的 DOM，列出只在渲染后出现的正文、链接和指令。
- 在服务器日志中区分普通抓取与渲染请求，看渲染请求是否被拦截、是否返回 4xx 或 5xx。
- 用抓取诊断工具查看渲染后的代码，确认蜘蛛实际拿到的版本。
处理顺序建议
- 把标题、正文和主要内链改为服务端输出或预渲染输出，保证初始 HTML 里就有可读内容。
- 内链使用标准链接标签，避免纯脚本跳转，让 URL 发现不依赖渲染。
- canonical、robots meta 等指令直接写在初始 HTML 中，减少解析歧义。
- 确实无法改造的页面，可以用预渲染或动态渲染过渡，但要让渲染结果与用户看到的内容保持一致。
- 改造后用 URL 检查工具和日志复核，观察一段时间内抓取频次与索引状态的变化。
渲染改造能改善蜘蛛拿到的内容，但不等于一定被收录，最终仍取决于页面自身的价值和站点整体质量。
收录是一条链条：URL 被发现、被抓取、被渲染、被评估。JS 页面容易在渲染这一环掉队，而问题通常在日志和原始 HTML 里才看得出来。把“不执行脚本时能看到什么”列为常规检查项，比事后反复提交更有效。