不少站点的頁面在浏览器里看着完整，但把 JavaScript 關掉，或者直接看服務端返回的 HTML 源碼，正文区域却是空的。對訪客来说，只要脚本能跑起来，問题不明顯；對搜尋蜘蛛来说，拿到的可能就是一個几乎没内容的空壳。這類問题通常在改版、換前端框架或上线新模板之後出現，而且很难在日常浏览中顺手發現。
先判断：蜘蛛到底拿到了什么
自查的第一步不是改代碼，而是確認現状。几個成本很低的方法：
- 在浏览器里打開目标頁，按 Ctrl+U 查看網頁源代碼，搜尋正文里的關鍵詞，看是否出現在源碼中。
- 临时禁用 JavaScript 再刷新頁面，观察主体内容、主要導航連結、分頁入口是否還在。
- 用抓取工具或 curl 請求頁面，對比返回的 HTML 與渲染後的頁面结构差异。
- 對同一模板下的多個栏目各抽一两個頁面，避免只测首頁就得出“没問题”的结论。
如果源碼里只有前端框架的挂载容器，正文、标题、列表項都要等脚本执行後才出現，那就要繼續往下排查。
常见的几類陷阱
懒加载把正文也一起懒了
图片懒加载本身没問题，但有些實現把正文段落、表格、评论也纳入懒加载，需要滚動到可视区域才插入頁面。蜘蛛通常不會滚動，于是只能看到首屏之外的空内容。
無限滚動没有可抓取的入口
列表頁用無限滚動加载，用戶往下滑很顺畅，但传统分頁連結被去掉之後，後面的内容就没有稳定的 URL 可供發現，越靠後的條目越难被訪問到。
連結由脚本拼接生成
導航或文章列表里的 href 是脚本执行後寫入的，源碼里只有按钮或空标簽。顺着源碼找連結时，就會走進死路。
标题與描述由前端動態寫入
title、description、canonical 如果靠脚本執行时改寫，不同的抓取方式可能拿到不一样的结果。這類信息尽量让服務端直接輸出。
處理思路
- 優先服務端渲染或静態化：让首屏的正文、标题、主要連結出現在初始 HTML 里，脚本只做交互增强。
- 预渲染作為過渡：改造周期較長时，可對重点栏目做预渲染，但要留意缓存的更新频率與内容新鲜度。
- 渐進增强：把内容放在 HTML 里，用脚本加交互，而不是把内容藏在脚本里。
- 保留可抓取的分頁或归档入口：無限滚動之外，补一套带獨立 URL 的分頁頁或按标簽归档的列表頁。
- 懒加载加兜底：图片懒加载要保留替代内容或首屏直出，正文区域不要懒加载。
- 元信息服務端輸出：title、description、canonical 以及结构化資料，尽量在服務端确定下来。
把它變成固定巡检項
前端框架升級、模板改版、CDN 更換、构建配置調整，都可能重新引入這個問题。建议在模板或主题上线前，固定检查几個代表性的頁面類型：首頁、栏目頁、詳情頁、搜尋结果頁。检查结果记到改動记錄里，下次改版时能直接對照，不用從零摸索。
判断标准其實很简單：如果一個頁面的核心内容必须等脚本跑完才出現，就要评估它在各種抓取环境下的可见性，而不是只看自己浏览器里的效果。
還要提醒一点，服務端渲染也不是萬能的。渲染超时、接口报错、缓存穿透时，返回给蜘蛛的仍可能是残缺頁面。把這几種異常情况也纳入监控，比單纯依赖某一種渲染方案更稳妥。