在浏览器里打開頁面一切正常，不代表抓取工具拿到的也是同一份内容。現在不少站点把正文、列表、分頁都交给 JavaScript 在客戶端渲染，爬虫如果只取原始 HTML，很容易拿到一個只有骨架、没有内容的空壳。
先搞清楚蜘蛛實际拿到了什么
自查的第一步不是改代碼，而是做對比。同一篇文章，用两種方式各取一次：
- 用命令行工具或浏览器的“查看網頁源代碼”，看原始 HTML 里有没有正文文字；
- 用開發者工具看渲染後的 DOM，確認浏览器里顯示的内容到底從哪来；
- 如果手上有抓取工具，找找“查看抓取方式”這類功能，通常能同时看到原始响應和渲染後的结果。
如果原始 HTML 里只有容器标簽和一段 script，正文、标题、連結都要等脚本跑完才出現，那就要留意了。
常见的几種空壳形態
- 單頁應用没有做服務端渲染，路由切換全靠前端；
- 列表頁内容靠接口返回，HTML 里只留占位骨架；
- 图片和正文使用懒加载，滚動到可视区域才開始加载；
- 選項卡、折叠面板里的内容預設隐藏，需要点击才展開；
- 無限滚動代替分頁，没有可訪問的下一頁地址。
逐項自查清單
按下面几條過一遍，通常能定位到大部分問题：
- 文章頁的标题、首段、正文主体，是否直接出現在原始 HTML 中；
- 栏目頁的文章列表，每條是否是一個带 href 的 a 标簽，而不是按钮加点击事件；
- 分頁是否有獨立地址，而不是只有一個“加载更多”按钮；
- 導航、面包屑、相關阅讀等内鏈，是否在初始 HTML 里就能看到；
- 图片是否有有效的 src 和 alt，是否依赖脚本注入；
- 是否有 noscript 之類的兜底，作用有限，但能反映内容能否直出。
可以采取的折中做法
不必把所有交互都推翻，思路是让關键内容直出，次要体驗再增强：
- 正文與列表改由服務端渲染或预渲染輸出，交互部分交给前端接管；
- 分頁保留真實地址，“加载更多”只作為額外补充；
- 图片懒加载尽量用原生属性，並保證初始 src 有效；
- 折叠内容如果属于正文主体，考虑預設展開或單獨成頁；
- 首屏之外的内容可以延後，但不要延後到完全看不见。
改完之後怎么確認
調整發布後，隔一段時間看抓取日誌，观察蜘蛛是否開始抓取 HTML 里新出現的連結，以及是否還在反复請求同一批脚本文件。同时记錄改動時間和涉及的模板，方便後續對照。
判断标准不是“我打開頁面能看到”，而是“原始 HTML 里能不能看到”。
這一步做扎實，後面谈内鏈、栏目規划、更新节奏才有意义——蜘蛛连正文都拿不到，其他優化很难發挥作用。