先分清“源碼里有什么”和“浏览器里看到什么”
在浏览器里右键查看網頁源代碼，看到的是服務器返回的那份 HTML；而按 F12 打開的“审查元素”面板，展示的是脚本执行之後、经過浏览器加工過的 DOM。這两者经常差別很大。前者是抓取时優先拿到的東西，後者才是用戶看到的画面。很多“内容不收錄”的疑問，源头就在于把两者当成了一回事。
自查的第一個動作很简單：把正文里最核心的一段话複製出来，在查看源代碼的頁面里搜一下。搜得到，說明内容在初始 HTML 中；搜不到，就要考虑脚本渲染的問题。
几個常见的“正文藏在脚本後面”的场景
無限滚動與“加载更多”按钮
列表頁只輸出前十條，後面的靠滚動触發接口。用戶滑得開心，但抓取端往往不會主動滚動，也不會去点按钮。结果是後續内容既没有入口連結，也没有可抓的地址。
選項卡與折叠面板
同一個頁面用 Tab 切換“简介 / 參數 / 评價”，只有目前選中的那部分在 HTML 里，其余靠脚本注入。這類内容常常是頁面里最有價值的部分，却預設藏在後面。
客戶端路由
單頁應用里，從列表点到詳情，地址變了、画面變了，但請求的是同一份 HTML。如果没有服務端直出或预渲染，詳情頁的标题、正文都可能不在初始响應中。
自查的几條實操路径
- 用命令行工具抓一次頁面，例如用 curl 輸出 HTML，儲存成文件後搜尋正文關鍵詞。
- 對照工具里的抓取方式报告，看看是否存在“僅通過渲染才發現的内容”。
- 在浏览器里禁用 JS 後刷新頁面，看還剩多少可讀内容。剩下的部分，大致就是初始 HTML 的成色。
- 逐條检查列表頁的“加载更多”：這些後續條目有没有獨立的、可点開的 URL。
- 把站点地图與實际可抓地址對一遍，確認動態加载出来的頁面是否也在清單里。
處理思路：能让内容先在 HTML 里出現，就別赌渲染
- 關键内容優先直出。标题、正文首段、面包屑、主要導航，這些放在服務端渲染里最稳妥。
- 分頁改成真實連結。“加载更多”可以保留，但至少提供一個指向下一頁的 a 标簽，让抓取端有路可走。
- 图片用标准 img 标簽。懒加载可以加 loading 属性或脚本增强，但 src 別留空，替代文本寫清楚。
- 選項卡内容考虑全部輸出。用 CSS 控制顯示隐藏，比用脚本按需注入更容易被讀到。
- 單頁應用考虑预渲染或服務端渲染。這一步成本不低，但比反复猜测抓取效果更可控。
- 別忘了站点地图和分頁入口。即使渲染問题暂时解决不了，也尽量让地址本身可被發現。
別走到另一個极端
把所有内容一次性塞進 HTML 也不總是好事：首屏体积變大、加载變慢，反而影响体驗。更實际的做法是先分清哪些是“必须被抓到”的核心内容，哪些只是交互增强，然後只對前者做直出處理。
另外，渲染方式只是影响抓取的因素之一，最终能否被抓到、以什么形式展示，仍由抓取方决定。自查的意义在于减少不确定性，而不是保證结果。
把“用戶能看到”和“抓取端能拿到”当成两件事分別检查，是站点运营里性價比很高的一項日常工作。每次改版或上线新栏目之後跑一遍，問题通常能在早期被發現。