同一篇内容，在浏览器里打開是完整的，但在搜尋引擎抓到的 HTML 里可能只有几個空容器。這不是蜘蛛“看不懂”，而是抓取和渲染是两個阶段。理解這一点，很多收錄差异就能找到解释。

抓取拿到的是源文件，渲染才得到頁面

蜘蛛訪問 URL 时，首先拿到服務器返回的 HTML。如果正文、連結、價格、评论都在 JavaScript 执行後才出現，這一阶段的頁面就是一個壳。搜尋引擎通常會把需要渲染的頁面放進队列，稍後执行 JavaScript，得到最终的 DOM。队列有先後，站点越大、頁面越多，延迟可能越明顯。

所以，抓取成功不等于内容被看到。URL 被發現了，也返回 200，但渲染阶段如果失敗或被跳過，索引里就可能缺少正文，甚至只留下一個空白頁。

哪些頁面更容易在渲染上出問题

• 正文完全由客戶端渲染，HTML 源碼里没有可讀文本。
• 連結是 JavaScript 点击事件，而不是带 href 的 a 标簽。
• 内容需要点击“加载更多”或滚動到底部才出現。
• 接口請求依赖用戶登入、地区或 cookies，蜘蛛請求时拿不到資料。
• 單頁應用路由没有正确的 URL 對應，刷新後無法直接打開同一頁面。
• 首屏依赖第三方脚本，第三方被阻断时頁面整体空白。

先確認蜘蛛實际看到了什么

與其猜测，不如直接观察几個信号：

1. 查看網頁源代碼，而不是审查元素。源代碼里没有正文，說明初始 HTML 不含内容。
2. 在浏览器里禁用 JavaScript 後再打開頁面，观察是否還能讀到主要内容和連結。
3. 使用搜尋资源平台提供的抓取測試或 URL 检查工具，看渲染後的 HTML 和截图。
4. 在服務器日誌中区分普通抓取請求和渲染請求，確認渲染服務是否被訪問、返回什么狀態。
5. 用 curl 或類似工具請求頁面，查看返回的 HTML 中是否包含目标文本和可跟踪連結。

几種渲染方案的取舍

服務端渲染

服務器直接返回包含内容的 HTML，蜘蛛第一次請求就能讀到正文和連結。這是最稳妥的做法，但需要後端配合，頁面缓存和個性化内容之間要划清邊界。

预渲染

對不常變化的頁面，可以在构建或發布阶段生成静態 HTML。适合营销頁、文章頁和帮助文档。缺点是頁面更新後需要重新生成，動態内容不适合全量预渲染。

動態渲染

识別到蜘蛛請求时返回渲染後的 HTML，普通用戶仍走客戶端渲染。實現时要注意，返回给蜘蛛的内容必须和用戶看到的基本一致，不能借机塞入用戶看不到的關鍵詞或連結。這属于伪装，風險不小。

同构渲染與注水

首屏由服務端輸出，前端接管後繼續交互。它兼顾速度和可抓取性，但要注意服務端和客戶端渲染结果不一致时，可能造成内容闪烁或連結错位。

URL 發現也會被渲染影响

如果站内連結只存在于 JavaScript 生成的 DOM 中，蜘蛛在初始 HTML 阶段可能根本看不到這些地址。比較稳妥的做法是：主要導航和内容列表使用真實的 a 标簽 href；需要抓取的頁面尽量有可点击的入口；再配合 sitemap 提交，但不能把 sitemap 当成唯一發現渠道。

排查顺序建议

1. 選一個未被收錄或收錄異常的 URL。
2. 查看原始 HTML，確認正文和連結是否存在。
3. 用工具查看渲染结果和截图，確認渲染是否成功。
4. 检查 robots.txt、meta robots、X-Robots-Tag 是否誤挡。
5. 检查接口是否對蜘蛛返回空資料或错誤狀態。
6. 修复後通過站点地图或内鏈重新暴露 URL，並观察日誌與索引狀態變化。

渲染方式不會直接决定排名，但它决定了搜尋引擎能否稳定看到你的内容和連結。先把“蜘蛛看到了什么”這件事查清楚，再谈後續優化。

最後提醒一点：不要為了收錄给蜘蛛單獨准备一套内容。搜尋引擎要的是和用戶一致的頁面。把主要内容和連結放在初始 HTML 可获取的范围内，通常比事後补救更省事。