蜘蛛先拿到的是 HTML，不是运行后的页面
多数搜索引擎的抓取分两步：先请求 URL 拿到响应体，再把页面放进渲染队列执行 JavaScript。第二步是有成本的，排队、超时、资源加载失败都可能让渲染结果与用户看到的页面不一致。如果主要内容、导航链接都靠脚本生成，抓取路径的起点就变得不稳定。
链接写在脚本里，会带来三个具体问题
- 发现延迟：链接不在初始 HTML 中，通常要等渲染完成才会被提取，新页面进入抓取队列的时间会被拉长。
- 触发依赖：只有点击“加载更多”“展开全部”才出现的链接，蜘蛛一般不会主动去点，后续页面就成了抓取死角。
- 渲染失败即丢失：脚本报错、接口超时或被 robots.txt 屏蔽时，渲染后的 HTML 里就没有这些链接和内容。
让重要内容出现在初始 HTML 里
不一定整站都做服务端渲染，但至少要让入口层稳定：首页、栏目页、详情页的正文与主要导航，应该在第一个响应里就能看到。常见做法是服务端渲染或静态生成，客户端再接管交互。纯靠接口返回 JSON、再由脚本插入正文的方式，等于把抓取的成功率交给渲染队列。
列表页最好保留可点击的真实链接
“加载更多”用按钮实现时没有 href，蜘蛛没有可跟的地址。可以在列表下方保留传统分页链接，或者让按钮同时带一个指向下一页的真实 URL，两种入口并存并不冲突。
渲染后的链接同样参与 URL 发现
搜索引擎会在渲染后的 HTML 中提取链接，所以只要渲染成功，脚本生成的地址仍然有机会被发现。问题在于这条路径更长、更依赖外部条件：渲染资源被拦、接口变慢、脚本报错，都会让原本能走通的路径断掉。因此判断标准不是“渲染后有没有链接”，而是“在最差情况下还有没有链接”。
别把渲染需要的资源挡在门外
robots.txt 屏蔽 JS、CSS 或渲染依赖的接口，会让渲染结果缺内容。可以重点检查这几项：
- JS、CSS 等静态资源路径是否可被抓取；
- 渲染过程中调用的内容接口是否要求登录态或短时效 token；
- 接口是否对非浏览器 UA 做了差异化处理；
- CDN 或 WAF 是否对频繁请求返回验证页面。
渲染是抓取之后的第二步，第一步拿不到的东西，不要指望第二步一定补回来。
上线前的自测顺序
- 禁用 JavaScript 打开页面，看正文、导航和主要链接是否还在；
- 查看页面源码（不是审查元素），确认关键链接存在于 HTML 中；
- 用抓取工具对比渲染前和渲染后的 HTML，记录差异；
- 检查渲染依赖的脚本、样式和接口是否返回 200，是否被 robots.txt 拦截；
- 在访问日志里确认蜘蛛是否请求了这些资源，以及返回码是否正常。
改造精力怎么分配
优先级可以按“是否影响 URL 发现”和“是否是主要流量页面”来定。导航、列表页、详情页正文属于高优先；评论区、个性化推荐这类次要模块放到客户端渲染问题不大。改造后不必追求立刻见效，观察抓取日志里渲染相关资源的请求比例、新页面首次被抓的时间变化，比盯着单日数据更可靠。