用浏览器打開頁面内容完整，用爬虫工具抓一下却只拿到一個空壳，這類情况在核對收錄时很常见。前端框架、异步接口、懒加载都會让用戶看到的頁面和搜尋引擎拿到的頁面不是同一份東西。要判断問题出在抓取還是索引，需要按固定顺序逐层核對，而不是直接去改模板。
一、先把几份内容摆在一起對比
核對的第一步不是改代碼，而是采集几份可以互相對照的样本：
- 原始响應：用命令行工具或浏览器的查看源代碼获取，不含任何脚本执行结果；
- 渲染後 DOM：在開發者工具的元素面板里查看，是脚本执行完之後的完整结构；
- 抓取快照：搜尋控制台網址检查里展示的已抓取版本；
- 索引展示：搜尋结果中的标题、摘要與落地地址。
如果原始响應里已经包含正文，問题就不在渲染；只有原始响應明顯缺正文，才需要往渲染方向繼續查。
二、区分三種常见的渲染狀態
1. 初始 HTML 就是空壳
源代碼里只有一個空的挂载节点和几行脚本引用，正文、導航、列表全部由脚本請求接口後寫入。這種頁面能否被完整抓取，取决于搜尋引擎是否愿意执行脚本以及执行後接口是否正常返回。
2. 初始 HTML 有骨架，關键字段後补
頁头、導航是服務端輸出的，但價格、库存、正文段落等關键信息在渲染後才出現。這類頁面的收錄往往不稳定，因為不同抓取轮次拿到的内容可能不一致。
3. 需要交互才出現的内容
点击展開、滚動加载、切換标簽後才顯示的正文，通常不會被自動触發。用戶能看到的第三屏内容，抓取侧可能完全没见到。
三、按這個顺序核對
- 確認請求没有被 robots、訪問控制或登入狀態拦截，原始响應返回的是正常狀態碼而不是 403 或跳轉；
- 對比原始响應與渲染後 DOM，圈出具体缺失的区块，而不是笼统地说頁面没内容；
- 在網址检查里看抓取快照，正文是否存在、是否與用戶所见一致；
- 若快照里确實没有正文，再追踪這些内容由哪些接口返回，接口是否需要特定請求头或 Cookie；
- 检查渲染是否依赖滚動、点击等用戶行為，這類触發條件在抓取时一般不成立；
- 確認标题、描述、canonical 等基础标簽寫在初始 HTML 里，而不是靠脚本注入；
- 最後再看索引狀態，区分抓取阶段就没拿到内容，還是拿到了但判定為低價值。
四、抓取問题和索引問题不要混在一起
抓取到的 HTML 里缺正文，属于渲染與抓取层面的問题；正文齐全却仍未被索引，則更可能涉及頁面质量、重复内容或站点整体信号。两者的處理方式完全不同，混着改容易白花力气。核對时先回答前一個問题，再讨论後一個問题，判断會清楚很多。
五、處理上的優先級
- 能服務端直出的内容尽量直出，尤其是标题、正文主体和主要導航；
- 必须异步加载的部分，保證接口無需登入、無需特殊請求头就能返回資料；
- 标题、描述、canonical、结构化資料放在初始 HTML 里，不依赖脚本寫入；
- 避免把正文塞進点击後才展開的折叠区域；
- 列表、分頁等重复性强的模板，優先保證首屏可见内容完整。
六、改完之後怎么確認
改動完成後不要只看浏览器顯示。重新抓一次原始响應，確認正文是否出現；在搜尋控制台重新請求抓取，等待快照刷新；再观察一段時間内该模板下頁面的索引狀態是否變化。渲染层面的調整通常需要经歷一轮重新抓取，才會体現在索引结果里。
建议固定核對顺序：原始响應 → 渲染後 DOM → 抓取快照 → 索引狀態。前三步解决的是搜尋引擎能不能拿到内容，最後一步才讨论拿到之後要不要收。