有些頁面在浏览器里打開一切正常，标题、正文、列表都在，但在收錄里，這個地址要么不出現，要么抓到的只是一层空壳：導航、頁脚，再加一句“加载中”。這類問题往往不是内容质量不够，而是内容压根没在抓取环节暴露出来。排查时，顺序比工具重要。
先分清：人看到的版本和抓取看到的版本
在動手改任何代碼之前，先確認問题出在哪一层。同一個 URL 通常存在三種“样子”：浏览器渲染完成後的 DOM、服務器直接返回的原始 HTML、以及索引侧實际抓取並處理後的结果。三者不一致时，才谈得上修复。
常用的核對方式有三種：查看網頁源代碼（不是開發者工具里的 Elements 面板，那個顯示的是渲染後的结果）；用命令行請求一次，看返回体里有没有正文文字；以及在開發者工具里禁用 JavaScript 後刷新頁面。三者對照，很快就能判断正文是存在于原始 HTML 中，還是必须靠脚本执行才出現。
原始 HTML 里没有正文，要分清是哪一種“没有”
- 纯空壳：HTML 里只有一個根容器和一堆脚本引用，正文完全由前端請求接口後拼出来。這是最典型的情况。
- 半渲染：模板层已经輸出了标题、面包屑、相關推荐，但主体内容仍由脚本填充。這时索引里可能保留一個“有框架没内容”的頁面。
- 内容在但被隐藏：文字确實寫在 HTML 里，只是被折叠在選項卡、手風琴或懒加载容器中，需要交互才可见。這類内容能否被使用，取决于它是被样式隐藏，還是压根没輸出。
渲染结果要核對的不只是文字
確認服務器返回的内容之後，還要看渲染這一层是否稳定。渲染不是萬能补丁，它有自己的失敗方式：
- 接口需要登入態或有频率限制，抓取时請求被拒绝，渲染结果為空；
- 渲染依赖地理位置、时区或本地存储，不同环境得到不同内容；
- 渲染超时，脚本没跑完就被放弃，頁面上只剩骨架屏；
- 渲染後的正文與原始 HTML 差异過大，比如多了原始 HTML 里没有的推荐模块，容易让人誤判哪一份才是“頁面内容”。
處理的顺序：先给正文，再谈美化
不是所有站点都要改造成服務端渲染，但可以按下面的顺序收敛：
- 先把核心正文、主标题、關键信息以服務端輸出的形式放進 HTML，哪怕样式朴素。
- 再检查首屏之外的内容是否必要。分頁、折叠内容若對用戶有價值，尽量保留在 HTML 中。
- 如果确實無法服務端輸出，確認渲染鏈路對匿名訪問、無 Cookie 的請求是稳定的。
- 最後才是补充结构化資料、調整 URL 與内鏈，让這些已经可见的内容有清晰入口。
几個容易忽略的细节
判断内容能不能被抓到，看的不是頁面在你自己浏览器里的样子，而是匿名、無缓存、不登入的一次請求返回了什么。
- 同一套前端代碼，列表頁可能返回了正文資料，詳情頁却是空白，要逐個模板核對，不要用一個頁面的结果推断全站。
- 接口返回的内容如果同时被多個地址使用，可能带来重复内容問题，正文入口和 URL 規范要一起考虑。
- 改動上线後，重新抓取不等于立即生效，索引里的舊版本會按自己的节奏更新，观察期要留够。
- 不要依赖 robots 或 noindex 去“解决”空壳頁面，先解决内容可见性，再决定哪些地址本就不该被收錄。
這類問题很少是搜尋引擎“没兴趣”，更多是頁面對匿名抓取請求没有交出内容。把原始 HTML、渲染结果、索引狀態三份對照着看，先確認缺的是哪一层，再决定改前端、改接口還是改入口，改動范围會小很多。