不少站长遇到过这样的场景：浏览器里打开页面，正文、价格、评论区都在；一旦换成不执行脚本的方式去取同一份 HTML，返回的源码里却只剩容器和占位符。而蜘蛛第一次拿到的，往往就是这份源码。抓取问题的起点常常就在这里。
蜘蛛先拿到的是源码，不是渲染后的画面
抓取一般分两步：先按 URL 取回 HTML，再排队做渲染。渲染要排队、要耗资源，不是每个 URL 都能立刻轮到，尤其当站点脚本重、接口慢、资源多的时候。所以判断一个页面能不能被抓到，先看它在不执行脚本的情况下还剩多少内容，会比看截图更接近实际情况。
几种常见渲染方式对应的抓取结果
- 服务端直出：HTML 里就有正文和链接，取回即可解析，最省事。
- 同构或预渲染：首屏内容在源码里，后续交互靠脚本，抓取基本没问题。
- 纯前端渲染：源码是空壳，必须等脚本跑完，结果取决于渲染队列是否处理到你。
- 混合渲染：部分区块直出、部分延迟拉取，要逐块确认哪些在源码里。
不必追求全站改成服务端直出，但至少要保证正文主体、主要导航、指向详情页的链接在源码里能读到。
懒加载最容易漏掉什么
懒加载的出发点是省流量、加快首屏，但对抓取并不友好，常见的有三个位置：
- 图片和视频先用占位图，进入视口才换成真实地址，图片资源可能一直没被取到。
- 列表页第二屏之后的内容靠滚动加载，蜘蛛不会一直往下滚，后面的条目相当于没有入口。
- 评论区、规格参数、问答等模块要点「展开更多」才请求接口，这部分内容基本不会被读到。
处理思路不是全部取消懒加载，而是留一层兜底：列表页保留可点开的翻页链接，折叠内容有独立且可访问的 URL，重要信息在源码里至少有摘要。
内链和 URL 发现受影响更大
抓取路径是从链接开始的。如果链接要靠脚本点击才拼出来，蜘蛛很可能走不到下一页。
比较稳妥的做法是：导航、面包屑、列表翻页、相关阅读这类结构，使用可被直接解析的 a 标签加 href，指向真实的、返回 200 的 URL。脚本可以做增强，但不要让脚本成为唯一入口。配合 Sitemap 提交主要 URL，能补上一部分发现路径，但 Sitemap 替代不了站内链接。
怎么自查
- 用抓取工具或在浏览器里禁用脚本取一遍页面，看标题、正文、内链是否还在。
- 对照服务器日志，确认蜘蛛取回的 URL 是否返回 200，响应体长度是否正常。
- 抽查几个重要落地页，比较「源码里有的内容」和「用户看到的内容」差多少。
- 用抓取调试类工具查看解析后的内容，辅助判断差异出在渲染还是接口。
改造顺序建议
优先做收益明显的部分：把正文和主要导航直出；把列表页翻页做成真实链接；给 Sitemap 补齐核心栏目；把折叠内容拆成可访问的独立地址。服务器与接口的稳定性也要跟上，渲染队列排到你的页面时如果接口超时或返回 5xx，这一趟基本等于白来。
最后提醒一句：要不要全站服务端渲染，取决于站点规模和维护成本。多数内容站只要保证「关键内容不依赖脚本、关键链接不依赖点击」，抓取路径就会顺畅不少。具体效果因站而异，建议改完之后用日志观察一段时间，再决定下一步动哪里。