為什么先看“渲染後還剩什么”
不少站点改版後用了前端框架或异步接口，浏览器里看起来一切正常，但搜尋蜘蛛拿到的原始 HTML 里，正文位置可能只有一层空壳。抓取预算被消耗在“没有内容的頁面”上，URL 發現速度也會跟着變慢。這類問题通常不报错，所以更需要主動自查。
第一步：關掉 JS 看源碼
最直接的驗證方式，是在禁用 JavaScript 的情况下訪問几個代表性頁面，或者直接查看網頁源代碼，確認下面這些内容是否存在于原始 HTML 中：
- 主标题與正文首段
- 核心内鏈，例如列表頁、詳情頁、栏目入口
- canonical 标簽以及分頁的上一頁、下一頁關系
- 结构化資料里的關键字段
如果這些内容都要等脚本执行完才出現，就要评估搜尋引擎能否顺利执行你的脚本。
第二步：確認脚本执行的代價
主流搜尋引擎會执行 JS，但通常排在 HTML 解析之後，並且受時間延迟與配額限制。渲染队列积压时，頁面可能長期停留在“待渲染”狀態。常见影响因素包括：
- 脚本体积大、依赖多，首屏渲染耗时越長越不友好
- 第三方統計、广告、客服脚本阻塞主线程
- 接口返回慢，或需要登入態才能拿到資料
- 關键路径被 robots.txt 拦住，脚本或接口抓不到
把 robots.txt 里被屏蔽的 JS、CSS、接口路径列為重点排查對象，相当一部分渲染失敗就是從這里開始的。
第三步：按三层做清單核對
内容层
- 标题、正文、發布時間、作者是否服務端渲染或预渲染
- 列表頁的分頁與篩選结果是否具备可抓取的連結结构
- 图片懒加载是否保留占位與 alt，避免出現空白图
連結层
- 導航、面包屑、相關阅讀是否使用真實 a 标簽，而不是纯 JS 跳轉
- 点击事件绑定的元素是否同时提供了 href
- 前端路由是否配置了可被直接訪問的静態路径
元信息层
- title、description、canonical 是否由服務端輸出，避免渲染後再用脚本改寫導致不一致
- hreflang 與分頁标记是否随首屏一起返回
第四步：做一張源碼與渲染對照表
挑 10 到 20 個有代表性的頁面，首頁、栏目頁、詳情頁、分頁第二頁、带篩選參數的頁面各取几個，把“源碼中可见的内容”和“渲染後可见的内容”分別记下来。差异集中在哪一類頁面、哪一類模块，那里就是優先修复的位置。這样比全站推倒重来更省成本，也更容易驗證改動是否有效。
第五步：常见修复顺序
- 關键内容改為服務端渲染或预渲染，至少保證首屏可讀。
- 脚本改為异步加载，减少主线程阻塞，压缩首屏渲染時間。
- 列表與導航改為服務端輸出的真實連結，避免纯 JS 分頁。
- 给詳情頁接口加缓存，降低渲染超时或失敗的概率。
- 修复後结合抓取日誌观察目标 URL 的訪問次數與狀態碼變化。
什么时候需要重跑一遍
模板改版、引入新的前端框架、更換 CDN、上线大型活動頁，這几種情况都應该重跑一次清單。把每次的對照结果记錄下来，既能看出趋势，也方便出問题时定位到具体改動。渲染自查不是一次性動作，更像上线前的一個固定開關，做顺了通常十几分钟就能走完。