不少站点为了交互体验，把正文、列表、详情都交给 JavaScript 在浏览器里生成。对用户来说这没问题，但对搜索蜘蛛来说，第一次请求拿到的 HTML 可能只有框架和占位符。如果蜘蛛没有继续执行脚本，或者执行到一半超时，页面在它眼里就接近空壳。
为什么 JavaScript 渲染容易让蜘蛛空手而归
主流搜索引擎具备执行 JavaScript 的能力，但和真实用户浏览器相比，仍有一些限制：渲染队列需要排队，执行时间有上限，外部脚本、接口请求也可能被拦截。结果就是：用户能看到内容，蜘蛛看到的却是初始 HTML。
- 关键正文写在 JS 模板里，初始 HTML 没有对应文字。
- 接口需要登录态或特定请求头，蜘蛛请求直接失败。
- 脚本文件被 robots.txt 或防火墙拦截，渲染流程中断。
- 懒加载触发条件依赖滚动或点击，蜘蛛不一定会操作。
自查时先做这几件事
不用一上来就改架构，先确认问题是否存在。
- 用浏览器禁用 JavaScript，或者用纯文本模式访问几个代表性页面，看还剩多少可读内容。
- 查看页面源代码，而不是审查元素。源代码里若没有标题、正文、链接，说明它们是后注入的。
- 用搜索资源平台的 URL 检查工具，对比原始 HTML 和渲染后 HTML。
- 在服务器日志或抓取日志里，看蜘蛛请求接口和脚本时返回的状态码。
常见问题与处理方向
正文完全依赖客户端渲染
如果详情页、文章页的正文只在 JS 执行后出现，优先考虑服务端渲染、静态生成或预渲染。至少让初始 HTML 包含标题、核心段落和主要内链。对已经上线的页面，可以先做关键页面的预渲染，再逐步迁移。
接口和资源被挡在门外
检查 robots.txt、WAF、CDN 规则是否误伤了蜘蛛需要的接口或脚本。接口返回 403、401 或 5xx，渲染自然失败。可以按 User-Agent 和 IP 段做白名单，但不要为了放行蜘蛛而把整个接口暴露给任意请求。
懒加载与无限滚动
图片懒加载一般问题不大，正文懒加载就要小心。如果第二屏之后的内容必须滚动才加载，蜘蛛可能只拿到首屏。可以考虑首屏直出、分页链接，或者用 Intersection Observer 之外的可抓取兜底方案。
动态注入的 meta 和链接
有些站点用 JS 动态写入 canonical、robots meta、hreflang。搜索引擎虽然可能执行，但延迟和冲突会让规则不稳定。重要指令尽量放在服务端输出的 HTML 里，避免同一页面出现两套信号。
一份简化的自查清单
- 代表性页面在禁用 JS 后是否还有核心内容？
- 原始 HTML 是否包含标题、描述、canonical、主要内链？
- 渲染所需的脚本和接口是否对蜘蛛可访问？
- 是否有接口返回错误或超时？
- 分页、筛选、详情页是否存在无限滚动遮挡？
- 日志里蜘蛛是否频繁请求脚本和接口，却很少抓到内容页？
渲染问题没有一刀切的答案。先确认蜘蛛实际看到了什么，再决定用服务端渲染、预渲染还是降级方案。不要指望改完立刻被大量收录，抓取和索引都需要时间。
把 JavaScript 渲染自查纳入常规站点巡检，和死链、Sitemap、响应速度放在同一张清单里。蜘蛛能稳定拿到内容，后续的 URL 发现和栏目运营才有讨论的基础。