用浏览器打開頁面，标题、正文、相關推荐一應俱全；把 JavaScript 關掉再刷新，屏幕上可能只剩一行導航和一個轉圈的图标。這種差异在前端框架普及之後變得很常见，也是站点运营里容易被忽略的一环。
為什么會出現「两個版本」的頁面
蜘蛛抓取頁面时，拿到的是服務器返回的原始 HTML。如果正文、内鏈、图片地址都靠脚本在浏览器里動態生成，那么第一次抓取得到的就只是一份骨架。搜尋引擎虽然普遍具备渲染能力，會排队执行頁面脚本再抓一次，但這個過程有成本、有延迟，也不是每個頁面都能被完整渲染。
结果就是：用戶看到的頁面没問题，蜘蛛看到的頁面却可能缺内容、缺連結，進而影响 URL 發現和内容理解。
先搞清楚你的頁面属于哪種渲染方式
- 静態生成：构建时就把 HTML 生成好，蜘蛛拿到什么、用戶看到什么，基本一致，最省心。
- 服務端渲染（SSR）：每次請求在服務器拼好 HTML 再返回，首屏内容通常完整，需要關注服務器压力與缓存策略。
- 客戶端渲染（CSR）：HTML 里基本是空容器，内容由浏览器执行脚本後填充，抓取風險最高。
- 混合與動態渲染：部分内容服務端輸出，部分由脚本补齐，需要逐块確認。
大部分站点並不是單一模式，往往首頁是 SSR、列表頁是 CSR、詳情頁又是另一種。自查时要按模板類型分別看，而不是抽查一個頁面就下结论。
自查清單：確認關键内容真的能被讀到
- 關掉 JavaScript 打開頁面。浏览器開發者工具里可以禁用 JS，或者用命令行工具直接請求 URL，看返回的原始 HTML 里有没有正文、标题和主要内鏈。
- 看首屏關键内容是否在 HTML 中。文章正文、商品信息、栏目名稱這類决定頁面主题的内容，最好在原始 HTML 里就能看到，而不是等脚本执行完才出現。
- 检查内鏈是不是脚本生成的。如果導航、相關阅讀、分頁連結都由 JS 渲染，蜘蛛可能讀不到這些連結，URL 發現效率會明顯下降。
- 確認 JS 和 CSS 文件没有被 robots.txt 挡住。渲染依赖這些资源，挡住它們等于让渲染直接失敗。
- 检查接口請求是否被拦。部分站点會屏蔽接口路径，如果頁面内容靠接口返回，這條規則要重新评估。
- 观察渲染等待時間。脚本执行時間過長、依赖多個第三方請求时，渲染可能中途超时，留下不完整的頁面。
- 避免「点了才出現」的内容。折叠区块、标簽頁切換、滚動到底才加载的模块，對用戶是体驗，對蜘蛛可能是空白。
几個務實的處理方向
不是所有頁面都必须做服務端渲染，但决定頁面主题和层級關系的部分，值得優先保證。
- 核心内容優先服務端輸出：标题、正文、主要内鏈、面包屑放進原始 HTML，收益最直接。
- 谨慎使用懒加载：图片和次要模块可以延迟，正文和連結不建议。
- 保留無脚本兜底：可以用 noscript 标簽提供基础内容或連結，至少让蜘蛛知道頁面讲了什么。
- 控制第三方脚本數量：統計、客服、广告脚本過多會拖慢渲染，也增加渲染失敗的概率。
- 改版时同步驗證：換了前端框架後，抓取表現往往要過一段時間才反映出来，別等索引掉了才回头查。
怎么持續確認没有退化
單次自查只能說明当下，站点运营更需要一個轻量的观察习惯：
- 按模板類型各挑一两個代表頁面，定期用無 JS 方式請求一次，對比原始 HTML 是否還包含關键内容。
- 结合服務器日誌看蜘蛛請求的返回狀態和抓取量變化。如果某個目錄的抓取量突然下降，先怀疑渲染問题或资源被屏蔽。
- 上线新栏目、換主题、加新脚本时，把「原始 HTML 自查」寫進發布清單，成本很低，但能挡掉不少問题。
渲染方式的差別不會立刻体現在报表上，它更像一種慢慢积累的损耗：内容還在，連結還在，但蜘蛛能讀到的部分越来越少。定期用最笨的方式看一遍頁面，往往比事後排查索引問题省事得多。
站点运营不需要人人都懂前端框架，但至少要能回答一個問题：把脚本關掉之後，這個頁面還剩多少信息。這個問题答得清楚，很多抓取和收錄上的困惑也就有了方向。