站点用了前端框架之後，最容易出現的一種情况是：人工在浏览器里点開頁面，内容完整、排版正常；但用抓取工具或直接拉取 HTML 时，返回的却是一個空壳，正文要等脚本跑完才出現。蜘蛛是否执行脚本、执行到什么程度，不同抓取方做法不一样，也随时可能調整，把内容能不能被看到完全押在這一点上並不稳妥。所以這類自查的目的不是追求某個技巧，而是確認一件事：没有脚本时，頁面還剩什么。
先分清「看得到」和「抓得到」
浏览器里的「审查元素」面板顯示的是脚本执行後的 DOM，而「查看網頁源代碼」顯示的是服務器最初返回的 HTML。两者差別越大，說明内容越依赖客戶端渲染。做自查时要以源碼和抓取工具的视角為准，而不是以自己屏幕上的效果為准。
可以照着做的几項检查
1. 對同一批 URL 做两種方式的取回
挑首頁、栏目頁、几篇正文頁、一個列表分頁，分別用「查看源代碼」和渲染後的方式各取一份，對比正文文字量、内鏈數量、标题是否出現。差异明顯的頁面，就是需要優先處理的頁面。
2. 關掉 JavaScript 再打開頁面
在浏览器里禁用脚本後刷新，如果頁面只剩導航和一片空白，說明正文、相關阅讀、评论等内容全部由脚本注入。這不一定是错誤，但要有意识地確認哪些内容属于「希望被抓到」的部分。
3. 核查關键元素是否在初始 HTML 里
- 頁面标题、H1、面包屑
- 正文主体段落，尤其是首屏之後的内容
- 指向其他内容頁的站内連結，而不是点击後才由脚本拼出来的地址
- 图片的真實地址與 alt 文本
- canonical、hreflang 等头部信息
- 结构化資料所在的脚本块
4. 注意分頁與無限滚動
無限滚動在体驗上顺畅，但如果没有可抓取的静態分頁地址，列表深處的條目可能一直缺少入口。比較稳妥的做法是给滚動列表补一份带頁碼的静態連結，或者提供一個「查看全部」的列表頁。
5. 對比响應体大小和首屏内容
同一條 URL，服務器返回的 HTML 只有几百字节、渲染後却是几十 KB，說明内容基本靠脚本。返回体里正文占比越低，越值得考虑服務端渲染或预渲染處理。
几類常见問题
- 正文放在選項卡、折叠面板、懒加载模块里，用戶不点击就不出現。
- 内容通過接口异步拉取，接口一旦限流或报错，頁面就是空的。
- 關键連結用按钮加事件绑定實現，源碼里只有無意义的占位标簽。
- 不同模板渲染方式不一致，改版只改了其中一部分頁面。
處理思路
- 先列出「希望被抓到」的内容清單，不要全站一起動。
- 優先級最高的頁面改服務端渲染，让正文直接出現在初始 HTML 中。
- 暂时無法改動架构的，可以考虑预渲染方案，並确保渲染结果與用戶看到的一致。
- 保留一套不依赖脚本的降級入口，比如静態分頁、站点地图中的正文連結。
- 改完之後用同一批 URL 复测，對比修改前後的差异。
记錄與复查节奏
把抽查的日期、URL、源碼中的正文長度简單记下来，下次改版或換模板时就能快速判断有没有退化。建议在每次模板調整、接口改造、上线新栏目之後各抽查一次，而不是等到資料出現異常才回头找原因。
渲染方式属于技術细节，調整後的效果不會立刻反映在資料上。把「關閉脚本後頁面還剩什么」当成一條固定检查項，定期抽查，通常比一次性大改更實际。
最後提醒一句：结论尽量以多種方式對照為准，單一工具的渲染结果只能作為參考。自查的價值在于把不确定的地方變成可確認的事實，而不是找到一套一劳永逸的寫法。