越来越多的站点由前端框架驱動，頁面要等浏览器跑完 JavaScript 才算完整。對用戶来说這没什么問题，但對搜尋蜘蛛来说，中間多了一道门槛：如果渲染环节出問题，它拿到的可能只是一個空壳 HTML，正文、連結、發布時間、價格全都不在里面。
先分清三種“看到的頁面”
排查之前得先统一口径。同一個 URL 至少存在三種形態：
- 原始 HTML：服務器直接返回的源碼，右键“查看網頁源代碼”看到的内容。
- 渲染後的 DOM：浏览器执行完 JS 之後的结构，開發者工具 Elements 面板里看到的通常是這個。
- 蜘蛛實际抓到的版本：取决于它的渲染能力和渲染时机，可能接近第一種，也可能接近第二種，還可能介于两者之間。
很多誤會都来自拿第二種去判断第一種：開發者工具里明明有内容，源碼里却空空如也。
自查清單
1. 用源碼视图，而不是元素视图
打開一個典型内容頁，右键選擇“查看網頁源代碼”，然後在頁面里搜尋一段正文文字。搜不到，說明内容靠 JS 注入，属于典型的客戶端渲染场景。栏目頁、詳情頁、分頁、面包屑都要分別检查一遍。
2. 關掉 JS 再看一遍
浏览器禁用 JavaScript 後重新加载頁面。如果只剩下導航和頁脚，說明整個主体内容都绑在脚本上。不是所有站点都必须做服務端渲染，但至少要让核心的标题、正文、主要連結在無 JS 情况下可见。
3. 確認資料接口是否被拦
内容通過接口异步拉取时，要检查接口本身是否允许抓取。有些站点在 robots.txt 里屏蔽了 /api/ 之類的路径，或者接口要求特定請求头，结果頁面壳能拿到，資料拿不到。
4. 检查 JS 和 CSS 是否可被抓取
渲染依赖脚本资源。如果 robots.txt 屏蔽了 JS、CSS 文件所在目錄，或者這些资源返回 403、404，渲染過程就無法完成。這一点很常见，也很容易被忽略。
5. 看渲染触發的时机
不少内容是点击、滚動、切換标簽之後才加载的。對用戶是交互，對蜘蛛就是一道墙。重要内容尽量在首屏渲染时就出現，不要等滚動到底部或点了“加载更多”才生成。
6. 注意超时與资源体积
渲染是有時間预算的。如果首屏要串行等待三四個接口、加载几個大体积脚本，蜘蛛可能等不到内容出現就結束了。压缩脚本、减少串行請求、把關键内容提前，都能提高渲染完成率。
几個常见的坑
- 懒加载图片但占位地址為空：真實地址放在 data-src 里，脚本没执行就等于没有图片。
- 前端路由缺少服務端响應：單頁應用内部跳轉正常，但直接訪問深层 URL 返回空壳或错誤狀態。
- 内容藏在彈窗或折叠面板里：預設不展開就不渲染。
- 動態插入的 canonical 或 meta：脚本执行失敗时，這些标簽直接缺失。
- 測試环境開關誤上线：某些渲染降級配置随版本發布到了生产。
排查和修复的先後顺序
- 先定范围：全站是纯客戶端渲染，還是只有少數模块依赖 JS。
- 再定優先級：首頁、栏目頁、核心詳情頁優先，邊角頁面可以往後放。
- 然後選方案：服務端渲染、预渲染、静態生成，或者退一步，把關键内容直接寫進 HTML。
- 最後做驗證：改完後用源碼视图复查，並观察一段時間的抓取日誌，看渲染相關請求有没有變化。
不要指望“蜘蛛很聪明，它會自己跑 JS”来解决结构問题。能靠 HTML 说清楚的事，尽量不要留给脚本。
JS 渲染自查不是一次性動作。前端框架升級、打包策略調整、第三方脚本引入，都可能悄悄改變頁面的最终形態。把它放進改版和上线的检查清單里，比出問题之後再回头翻日誌要划算得多。