同一個 URL，用戶在浏览器里看到的是完整頁面，搜尋引擎抓取程序第一次拿到的却可能只是几行 HTML 骨架。這不是抓取出错，而是抓取和渲染本来就是两個环节：先取回服務器返回的响應，再排队把頁面渲染出来看一遍。問题在于，很多頁面质量判断在第一环节就已经開始了。
抓取端拿到的東西，取决于服務器返回了什么
請求到達时，服務器返回的 HTML 里有什么，抓取端就先看到什么。如果主体内容、内鏈、结构化信息都依赖 JavaScript 在浏览器里执行後才插入，第一轮抓取拿到的就接近空白。搜尋引擎通常會安排渲染，但渲染要排队、要消耗资源，對站点的抓取安排並不友好。
常见的几類情况
正文由前端脚本生成
列表頁、詳情頁的資料通過接口請求後再插入 DOM。這類頁面在浏览器里一切正常，但源碼里没有對應文字，抓取端如果只做第一轮解析，就很难判断頁面主题。
图片或内容懒加载
滚動到视口才加载的大段文本、评论、图集，滚動前只是空的占位元素。抓取程序一般不會像人那样一路滚到底，看不到的内容等于不存在。
登入、地区或權限限制
未登入时返回登入提示，或按 IP 返回不同版本。抓取端往往拿不到登入態，看到的可能是提示语而不是正文。
彈窗和浮层
Cookie 同意、订阅彈窗、App 下载引導覆盖在正文之上。有些實現方式會把頁面主体包進隐藏容器，抓取端讀到的就是被折叠的内容。
個性化與 A/B 測試
同一 URL 對不同用戶返回不同模块，或長期停留在測試版本。内容不稳定时，抓取端多次拿到的结果可能互相矛盾，頁面定位也跟着模糊。
怎么判断自己有没有這個問题
- 用“查看網頁源代碼”而不是開發者工具的 Elements 面板，看第一次响應里到底有没有正文。
- 在浏览器里禁用 JavaScript 刷新頁面，观察還剩多少可讀内容。
- 用搜尋平台的 URL 检查工具，對比“已抓取的 HTML”和“渲染後的 HTML”。
- 翻服務器日誌，看抓取程序請求的 URL 返回了什么狀態碼、多大字节數。
- 检查内鏈是否用可抓取的 a 标簽，而不是点击事件绑定的 div。
可以落地的調整
- 把标题、正文主体、分類導航等關键内容放到服務端渲染或预渲染輸出里，脚本只负责增强。
- 懒加载尽量用真正的 img 和 src，配上合理占位，不要用背景图或纯脚本替換。
- 重要連結保持 a 标簽结构，脚本跳轉只作為补充。
- 彈窗不要包住正文容器，也不要預設用 display:none 隐藏内容。
- 需要登入才能看的内容，评估是否值得让抓取端訪問；确實不该收錄的，用合适的方式說明。
這些調整不會直接換来收錄，但能让抓取端第一次就把頁面看清楚，後面的质量判断才有依據。
抓取端看到的版本，才是它评判頁面的起点。用戶看到的再漂亮，第一轮 HTML 里没有的東西，就等于没寫。