先弄清蜘蛛拿到的是哪個版本

搜尋引擎抓取頁面时，第一步拿到的是服務器返回的 HTML 源碼，而不是浏览器渲染之後的画面。如果标题、正文、連結全靠 JavaScript 在浏览器里生成，源碼里可能只有一個空的容器。抓取到的版本和用戶看到的版本不一致，收錄判断就會跟着出問题。

核對方式很直接：用查看網頁源代碼或 curl 拉一次頁面，再關掉 JavaScript 打開一次，看看還剩多少内容。如果關掉 JS 後頁面接近空白，那這套内容對抓取意味着什么，就需要重新评估。

三種渲染方式的差別

服務端渲染與静態生成

這两種方式下，服務器返回的 HTML 里就带着标题、正文和内鏈，抓取和收錄相對省事，後續排查也简單。

客戶端渲染

源碼几乎是空壳，内容在浏览器里才拼出来。搜尋引擎會排队等待渲染，渲染本身有成本也有延迟，收錄慢、收錄不全、收錄的版本偏舊都可能出現。

比對抓取版本與渲染版本

在站点工具里用 URL 检查類的功能，一般能看到「已抓取的 HTML」和「渲染後的结果」两種輸出。重点看三處：

• title、H1、正文首段是否出現在已抓取的 HTML 里；
• canonical、robots meta 是否在源碼里就寫好，而不是等 JS 注入；
• 内鏈是否以 a href 的形式存在于源碼中。

如果 canonical 或 robots meta 靠 JavaScript 寫入，抓取时可能還没生成，指令就等于没寫。

内鏈常被漏掉

JS 渲染站点里，導航和列表連結经常是事件绑定或异步插入。抓取阶段未必能点開，也未必等到資料返回。把關键導航、列表、面包屑做成源碼里就有的 a href，通常是成本最低的改善動作。

资源與接口是否可達

渲染頁面需要 JS 文件和接口資料。如果 robots.txt 屏蔽了 JS、CSS 或接口路径，渲染就會失敗，抓取到的還是那個空壳。可以核對這几項：

• robots.txt 是否誤拦 /js、/api 等路径；
• 渲染所需接口是否需要登入態或 token；
• 接口返回是否稳定，有没有频繁的 403、429；
• CDN 或 WAF 是否把渲染請求当成異常流量拦下。

几種常见的哑火情形

懒加载與首屏之外

图片、正文後段、评论区如果必须滚動才加载，渲染阶段可能拿不到。關键内容尽量放在首屏，或直接輸出在源碼里。

無限滚動

没有分頁 URL 的無限滚動，等于把後面所有内容藏在一次交互里。给每一屏一個可訪問的地址，收錄才有入口。

整站只有一個前端路由

History API 路由如果没做服務端對應輸出，每個地址返回的都是同一份空壳，收錄结果可能只有一條。

處理顺序小结

1. 關掉 JS 看源碼，判断内容是不是接近零；
2. 用站点工具比對抓取版與渲染版；
3. 把 title、canonical、robots 指令放回源碼輸出；
4. 把導航與列表連結改成源碼里的 a href；
5. 检查 robots.txt 與接口的可達性；
6. 拆掉懒加载和無限滚動對關键内容的遮挡。

這些調整不會立刻改變收錄结果，改動之後仍要观察一段時間的抓取频次與索引狀態，再判断下一步。