先分清“抓到了”和“看懂了”
蜘蛛請求一個 URL 时，服務器先返回一份 HTML。這份初始 HTML 里有什么，决定了蜘蛛第一眼能看到什么。如果标题、正文、列表、站内連結都是由 JavaScript 在浏览器里执行後才生成，那么蜘蛛拿到的初始响應可能只是一個空壳。
用戶打開頁面看到完整内容，是因為浏览器执行了脚本、調用了接口、把資料插進了 DOM。這個過程發生在用戶的浏览器里，不一定會發生在蜘蛛那一邊。
渲染是排队做的，不是即时的
現在主流搜尋引擎确實會做渲染：把頁面放進無头浏览器里执行脚本，再讀取渲染後的结果。但這件事是异步排队進行的，有资源額度限制，也並不保證每一個頁面都會被完整渲染一遍。所以“我的頁面用戶能看到”不能直接推導出“蜘蛛一定能看到”，更不能推導出“一定會被收錄”。
哪些寫法最容易出問题
- 正文、卡片、商品信息由前端接口拉取後插入，初始 HTML 里只有加载中的占位文字
- 導航、面包屑、相關推荐由 JS 生成，源碼里的 a 标簽為空或干脆不存在
- 翻頁、加载更多只改變前端狀態，没有對應的可訪問 URL
- 需要点击、滚動、悬停之後才出現的内容
- 關键信息放在图片、画布，或必须登入後才會返回資料的接口里
這些寫法在開發视角下很常见，但在抓取视角下，等于把内容藏在了第一层响應之外。
自查：用最原始的方式看頁面
- 關閉 JavaScript，或直接查看網頁源代碼，確認初始 HTML 里有没有标题、正文和站内連結
- 用搜尋平台的 URL 检查類工具，對比渲染前後两個版本的差异
- 對照服務器日誌，看蜘蛛有没有抓到你的接口請求。多數情况下它不會主動去調你的异步接口
- 抽查几個最重要的頁面，而不是只看首頁
四步做下来，通常就能判断出問题是出在抓取阶段，還是出在内容本身。
處理思路與優先級
不必一上来就把整站改成服務端渲染，先把“必须被理解的内容”放回初始响應里就够了。
- 首屏正文、核心連結、标题與描述，尽量在 HTML 直出
- 列表頁保證第一頁内容在源碼里，後續翻頁使用可被抓取的獨立 URL
- 站点地图里填的是最终能直接訪問的地址，不要填只有脚本才能跳轉到的狀態
- 确實只能靠脚本渲染的部分，至少留一段静態兜底文本
预渲染适合什么场景
頁面數量不大、更新频率不高、模板相對固定的站点，可以用预渲染把 HTML 提前生成好；内容量大且更新频繁的站点，更常见的做法是服務端渲染，或者把關键区块直出。两者目标一致：让初始响應里就有可讀内容。
抓取與收錄的区別在這里怎么体現
渲染不完整，通常先表現為抓取阶段就缺内容，蜘蛛手里没有可判断的素材，收錄自然無從谈起。另一種情况是頁面被抓到了，但初始 HTML 内容稀薄，被当成低质量頁面處理。前者要查日誌、查渲染鏈路，後者要回到内容本身，排查方向並不一样。
把“用戶能看到”当作驗收标准是不够的。蜘蛛看到的那一版，才是收錄判断的輸入。
別把所有收錄問题都归到 JS 上
有些頁面渲染完全正常，收錄依然不理想，原因可能在重复内容、URL 寫法不统一、站点层級過深，或者頁面本身没有獨立價值。渲染只是其中一环，排查时把它和其他因素分開看，才能找到真正的原因。