有些頁面在搜尋结果里能看到标题，点進去却和预期對不上；在索引狀態里查，頁面是已收錄，但抓取到的内容只有導航、頁脚和一句加载提示。遇到這種情况，先不要急着判断是收錄出了問题——多數时候，爬虫确實抓到了這個地址，只是它拿到的 HTML 里本来就没有正文。
抓取和收錄不是一回事，先確認你看到的是哪一层
抓取是請求一個地址、拿到响應；收錄是把响應里的内容理解、去重後放進索引。前端渲染的站点常见的情形是：第一次請求返回的 HTML 是個空壳，正文由脚本在浏览器里跑出来。搜尋引擎會另外安排渲染，但渲染有成本、有延迟，也有失敗的可能。如果渲染没跑到，或者跑到一半被規則挡住，進索引的就只剩那個空壳。
核對顺序：先看服務端给了什么
- 查看响應正文。用命令行請求工具带上常见的爬虫标识訪問一次頁面，看返回的 HTML 里有没有正文關鍵詞。不放心就再換一個普通浏览器标识對比，两者差异往往就是問题所在。
- 對比渲染前後。搜尋後台的網址检查一般會同时给出原始响應和渲染後的结果，把两者的可见文字提取出来一比，缺了哪一段一目了然。
- 看抓取日誌里的响應体大小。同一類模板的頁面，如果日誌里记錄的响應体明顯偏小，多半是正文没進 HTML。
- 检查拦截規則。CDN、防火墙、限流策略可能對脚本請求、接口請求区別對待。渲染时被拦，正文自然也出不来。
几種常见的空壳来源
正文完全靠客戶端渲染
頁面的文字、列表、價格都由接口返回後再插入，首次响應里只有一個容器。這是最典型的一類，改動方向也明确：让首屏的核心内容随 HTML 一起返回。
内容藏在交互後面
需要滚動、点击展開、關閉彈窗之後才出現，或者放在懒加载区域里。渲染未必會触發這些動作，抓到的就只有外层框架。
站内跳轉不是真正的連結
跳轉全靠点击事件實現，没有可被识別為連結的元素。這样的地址既不容易被發現，也谈不上入口深度。
接口或资源被規則挡住
正文接口、脚本文件返回 403 或 404，渲染會中断或降級。這類問题在抓取日誌和错誤統計里通常留有痕迹。
調整时按這個顺序来
- 先把核心正文、标题、關键資料放進服務端直出的 HTML，脚本只做增强。
- 确保站内跳轉使用标准連結元素，能被正常跟随。
- 確認爬虫相關請求没有被 CDN、防火墙或 robots 規則誤伤。
- 最後再补充提交入口、内鏈和站点地图，顺序反了容易白忙一场。
不要采用给爬虫單獨發一份内容、给用戶發另一份内容的做法。短期看似有效，長期是風險，而且很难维護。
改完之後怎么驗證
重新用同样的方式抓一次，看响應正文里的可见文字是否包含核心段落；再打開網址检查對比渲染结果；然後观察一段時間的索引狀態變化。這里不承诺收錄速度，只把抓到的 HTML 里有没有正文這件事確認清楚。
收錄是结果，抓取到什么才是前提。把服務端輸出這一层理顺，後面關于 URL 規范、重复内容、入口深度的整理才有意义。