很多站点把正文交给前端框架渲染，用戶在浏览器里看到的是完整的，但搜尋引擎第一次拿到的 HTML 里可能只有骨架。收錄和索引建立在這份它實际看到的内容之上，两邊對不上，就會出現收錄慢、索引里内容残缺、用正文片段搜不到自己的情况。
抓取和渲染是两步，不是一步
搜尋引擎通常先按 URL 抓一次原始 HTML，放進處理队列，之後再排队执行渲染——跑 JS、請求接口、拼出最终 DOM。索引大多以渲染後的结果為准，但渲染要消耗资源、有並發上限，所以這一步可能延後很久，也可能失敗。
- 原始 HTML 里没有内容，只能進渲染队列等待；
- 渲染超时或报错，索引里的可能是半成品；
- JS 文件或資料接口被 robots.txt 挡住，渲染完依舊是空壳。
一個简單的判断标准：關掉 JS 再打開頁面，還能看到主要内容吗？如果看不到，收錄质量就取决于渲染队列的進度。
常见表現：收錄了，但内容對不上
- 搜尋结果里的摘要来自骨架屏文案或導航文字，不是正文；
- 拿頁面里的一句原文去搜，找不到自己的頁面；
- 上线很久才被收錄，收錄之後内容長時間停在舊版本；
- 網址检查里渲染正常，线上索引结果却是几個月前那一版。
先排查，再動手改
- 用查看源代碼或命令行請求，確認原始 HTML 里關键内容是否直出；
- 在搜尋後台的網址检查里看渲染後的 HTML 和截图，對比接口是否被拦截；
- 打開抓取統計，看 JS、CSS、接口請求有没有大量 4xx、5xx 或被屏蔽；
- 關掉 JS 訪問一次，確認核心内容是否仍然可见。
能落地的處理顺序
1. 關键内容直出
列表頁、詳情頁里决定頁面價值的字段，比如标题、正文、價格、發布時間，尽量在服務端渲染或构建时生成，让原始 HTML 里就有。交互、推荐、评论区這類次要区块可以繼續留给前端。
2. 预渲染與降級
架构暂时改不了，可以做预渲染，或提供一份不依赖 JS 的静態版本。但要注意別让预渲染结果和真實内容變成两套，否則又會引出内容不一致的問题。
3. 打通渲染需要的资源
- 不要把 JS、CSS 文件寫進 robots.txt 的 Disallow；
- 資料接口尽量用 GET，可直接請求，不依赖登入態和复杂簽名；
- 内容別只在滚動、点击、切 Tab 之後才加载；
- 分頁和詳情入口用可抓取的 a 标簽連結，不要用纯 JS 跳轉。
两個容易忽略的点
其一，渲染是有成本的，別指望每一层頁面都能等来渲染。首頁、栏目頁、重要詳情頁優先直出，長尾頁面靠内鏈和 sitemap 帮助發現，但要接受它的收錄节奏更慢。
其二，被發現、被收錄並不等于進入可用索引。渲染结果太差时，即使 URL 出現在报告里，也难有稳定展現。與其盯着收錄數字，不如定期抽查：索引里的内容和线上内容是否一致。
最後留一個自检動作：每隔一段時間，從索引里随机抽几條 URL，關掉 JS 打開，看還剩多少有效信息。剩得越多，收錄這件事就越不依赖运气。