很多站点把内容交给前端框架渲染，頁面在浏览器里看着完整，但蜘蛛第一次請求拿到的那份 HTML，往往只有骨架。把“抓取”和“渲染”当成两件獨立的事来看，比纠结某個标簽更能解释收錄慢的原因。
抓取和渲染不是同一個動作
蜘蛛訪問一個 URL 时，第一步永遠是發 HTTP 請求，拿服務器返回的原始内容。這一步只看响應，不执行頁面里的脚本。真正需要 JavaScript 才會出現的内容，會被排進渲染队列，由渲染环节稍後执行脚本、拿到最终 DOM。這個過程可能延迟几分钟到几天，也可能因為资源抓取失敗而根本走不完。
也就是说，同一個 URL 在蜘蛛眼里可能有两個版本：第一次看到的原始 HTML，和渲染之後的完整頁面。如果關键信息只存在于第二個版本，等于把發現时机往後推，還可能推丢。
渲染要額外花掉抓取成本
渲染不是免費的。要跑脚本，蜘蛛還得去抓 HTML 里引用的 JS、CSS，甚至接口返回，這些都會算進站点的抓取消耗，而渲染队列通常比普通抓取队列更拥挤。
- 被 robots.txt 挡住的 JS、CSS，會让渲染结果残缺；
- 需要登入、点击、滚動才出現的内容，多數情况下不會被自動补齐；
- 脚本里拼接出来的連結，在原始 HTML 里並不存在，相当于少了一條發現路径。
几個容易踩的位置
- 把内鏈寫進脚本。列表頁、分頁、相關推荐如果用 JS 插入連結，蜘蛛第一次抓取时看不到這些 URL。改成服務端輸出，或至少在 HTML 里保留可点击的連結，能省掉一轮渲染等待。
- 關键正文懒加载。首屏之外的内容等到滚動才請求，渲染环节不一定模拟這個動作。
- 接口資料当成正文。内容全靠异步請求拉取，接口又没有別的入口被發現，抓取和索引都容易悬空。
- 分頁只留一個“加载更多”。没有真實可抓的下一頁 URL，深分頁的内容基本只能靠 Sitemap 兜底。
让两條發現路径都成立
比較稳的思路是双层保障：
- HTML 层：标题、正文主体、主要導航和内鏈尽量由服務端輸出，保證不执行脚本也能看出一條完整的抓取路径。
- URL 层：重要頁面整理進 Sitemap，用 lastmod 标出真實更新時間，让蜘蛛不必依赖脚本就能發現新 URL。
- 资源层：確認 JS、CSS、接口没有被 robots.txt 拦住，返回碼稳定，別让渲染抓到一半断掉。
怎么驗證這道落差
最简單的检查是關掉浏览器的 JavaScript 再刷新頁面，看看還剩多少内容、還剩多少連結，這一步能直观暴露蜘蛛第一次看到什么。再對照服務器日誌里 JS、CSS、接口的請求比例，判断渲染是否真的發生過。搜尋平台的抓取測試工具也能用来對比原始 HTML 與渲染结果。
不必追求整站改造
不用為了這件事把整站都改成服務端渲染，也没必要把所有内容硬塞進 HTML。優先把离正文最近的路径做扎實：入口頁、列表頁、分頁、詳情頁之間的内鏈，以及正文本身。這些位置少一层脚本依赖，抓取路径就少一個断点。
把内容藏在脚本後面，等于让蜘蛛排队等你；把發現路径放在 HTML 里，蜘蛛才知道下一步该去哪。