現在用前端框架搭站的团队不少，頁面首屏靠 JavaScript 拉資料再渲染。用戶用浏览器打開，脚本跑完，看到的是一張完整頁面；抓取端虽然大多也能执行一部分脚本，但执行時間、渲染资源、接口响應都可能受限。于是就出現了那種不好定位的情况：你自己点開一切正常，抓取端拿到的却接近空壳。這類問题通常不报错，只能靠主動比對發現。
先確認抓取端看到的是哪一版
不建议一上来就全站掃描，先挑一批有代表性的地址做人工比對，效率更高也更接近真實情况。選样时可以覆盖：首頁、主要栏目頁、内容詳情頁、列表或聚合頁，以及你近期最希望被發現的几個新頁面。
具体做法很朴素：在浏览器里查看網頁源代碼，看看里面有没有正文文字、标题、主要内鏈；再打開開發者工具看渲染後的 DOM，把两者對照。如果源碼里几乎是空的容器加一串脚本，而渲染後才出現内容，那么這類頁面就有必要進一步確認抓取端的表現。
容易出問题的地方
- 正文完全依赖接口返回後再插入，脚本一旦失敗頁面上就没有文字。
- 标题、H1、面包屑、正文内鏈由脚本拼接，源碼里看不到。
- 列表頁只有“加载更多”，没有可單獨訪問的分頁地址。
- 懒加载图片缺少占位尺寸與替代文字，渲染时机又滞後。
- 關键資料接口被規則文件或防火墙拦住，抓取端請求不到 JSON。
- 渲染依赖第三方 CDN，脚本加载超时或域名被拦截。
- 不同用戶代理返回不同内容，服務端做了 UA 判断但没有给預設版本。
一次可执行的自查流程
- 列抽样清單：從每個主要模板里挑两到三個 URL，固定下来，後面复用。
- 看源碼：在關閉脚本或直接查看源碼的狀態下，確認頁面里有没有正文與内鏈。
- 對比渲染结果：记錄差异，判断是“缺失”還是“延迟出現”。
- 检查接口可達性：確認資料接口没有被規則文件屏蔽，也不依赖登入態或特殊請求头。
- 確認兜底：核心頁面是否可以通過服務端渲染、预渲染或静態輸出，让内容直接出現在 HTML 里。
- 回归驗證：調整後重新跑一遍同一份清單，比較前後差异，並留下记錄。
兜底方案不必一步到位
如果整站改造周期長，可以先從收益最高的部分入手：把詳情頁與栏目頁的正文、标题、主要内鏈輸出到服務端；把分頁做成真實可訪問的地址，而不是只保留一個按钮；给不支持脚本的场景留一個可讀的預設版本。這些改動通常不需要推翻現有架构，却能让更多内容直接出現在初始 HTML 中。
同时也要留意，不要為了讨好抓取端而给不同来源返回两套差別很大的内容。服務端與前端渲染的應当是同一份信息，只是呈現路径不同，避免人為制造不一致。
把渲染检查放進日常巡检
渲染相關問题往往出現在變更之後：換了模板、改了接口协议、調整了缓存策略、替換了 CDN。與其等發現問题再回头排查，不如把抽样清單挂在固定位置，在下列节点各跑一遍：新模板上线前、接口版本變更後、缓存或 CDN 配置調整後、以及每季度一次的常規复查。
渲染問题很少直接报错，它的表現通常是抓取端比用戶少看到一部分内容。靠定期比對同一批地址，比凭感觉判断更可靠。
對以内容為主的站点来说，頁面能被完整讀取，是後續一切工作的前提。先把這件事做扎實，再去谈栏目規划與更新节奏，會顺畅得多。