在浏览器里打开页面一切正常，不代表抓取工具拿到的也是同一份内容。现在不少站点把正文、列表、分页都交给 JavaScript 在客户端渲染，爬虫如果只取原始 HTML，很容易拿到一个只有骨架、没有内容的空壳。
先搞清楚蜘蛛实际拿到了什么
自查的第一步不是改代码，而是做对比。同一篇文章，用两种方式各取一次：
- 用命令行工具或浏览器的“查看网页源代码”，看原始 HTML 里有没有正文文字；
- 用开发者工具看渲染后的 DOM，确认浏览器里显示的内容到底从哪来；
- 如果手上有抓取工具，找找“查看抓取方式”这类功能，通常能同时看到原始响应和渲染后的结果。
如果原始 HTML 里只有容器标签和一段 script，正文、标题、链接都要等脚本跑完才出现，那就要留意了。
常见的几种空壳形态
- 单页应用没有做服务端渲染，路由切换全靠前端；
- 列表页内容靠接口返回，HTML 里只留占位骨架；
- 图片和正文使用懒加载，滚动到可视区域才开始加载；
- 选项卡、折叠面板里的内容默认隐藏，需要点击才展开；
- 无限滚动代替分页，没有可访问的下一页地址。
逐项自查清单
按下面几条过一遍，通常能定位到大部分问题：
- 文章页的标题、首段、正文主体，是否直接出现在原始 HTML 中；
- 栏目页的文章列表，每条是否是一个带 href 的 a 标签，而不是按钮加点击事件；
- 分页是否有独立地址，而不是只有一个“加载更多”按钮；
- 导航、面包屑、相关阅读等内链，是否在初始 HTML 里就能看到；
- 图片是否有有效的 src 和 alt，是否依赖脚本注入；
- 是否有 noscript 之类的兜底，作用有限，但能反映内容能否直出。
可以采取的折中做法
不必把所有交互都推翻，思路是让关键内容直出，次要体验再增强：
- 正文与列表改由服务端渲染或预渲染输出，交互部分交给前端接管；
- 分页保留真实地址，“加载更多”只作为额外补充；
- 图片懒加载尽量用原生属性，并保证初始 src 有效；
- 折叠内容如果属于正文主体，考虑默认展开或单独成页；
- 首屏之外的内容可以延后，但不要延后到完全看不见。
改完之后怎么确认
调整发布后，隔一段时间看抓取日志，观察蜘蛛是否开始抓取 HTML 里新出现的链接，以及是否还在反复请求同一批脚本文件。同时记录改动时间和涉及的模板，方便后续对照。
判断标准不是“我打开页面能看到”，而是“原始 HTML 里能不能看到”。
这一步做扎实，后面谈内链、栏目规划、更新节奏才有意义——蜘蛛连正文都拿不到，其他优化很难发挥作用。