不少站点上线後發現一個現象：頁面在浏览器里打開完全正常，站長工具里也顯示被訪問過，但索引里要么没有這個地址，要么索引到的版本几乎是空的。原因往往不在内容本身，而在于内容出現的方式——正文是脚本执行之後才被插入到頁面里的。
要判断問题出在哪一步，需要先把抓取、渲染、索引這三件事分開看。抓取是拿到响應内容，索引是把頁面内容理解和入库，而在這两者之間，還有一個常常被忽略的环节：渲染。
抓取到的 HTML，不一定是用戶看到的頁面
当爬虫請求一個地址时，服務器返回的是一段 HTML 源碼。如果正文由前端請求接口後再插入，這段源碼里就没有正文，只有框架、容器和脚本引用。爬虫需要額外执行頁面上的脚本、构建出完整的 DOM，才能看到那些文字。
問题在于，渲染是要消耗资源的，不保證每個被抓取的地址都會被渲染。通常被優先渲染的是抓取频率較高、外鏈和内鏈較多、站点里相對重要的頁面。邊缘頁面、參數頁、很少被連結到的地址，可能在渲染队列里排得很靠後，甚至一直没有得到渲染机會。
哪些寫法容易让正文在抓取阶段消失
- 正文全部由前端接口返回後動態插入，服務端只輸出一個空容器。
- 内容依赖交互才出現，比如点击标簽頁、展開折叠区、滚動到某個位置才加载。
- 關键文字寫在图片、canvas 或背景图里，源碼中没有對應的可讀文本。
- 站内連結使用脚本跳轉而不是 a 标簽加 href，爬虫無法顺着連結發現新地址。
- 頁面在無脚本环境下直接报错中断，後續内容完全不再輸出。
這些寫法對用戶体驗可能没有明顯影响，但對以源碼為起点、以渲染為补充的抓取流程来说，就等于把内容藏在了第二层。
几個成本很低的自检動作
- 查看搜尋引擎實际抓取到的源碼。站長工具里的網址检查一般能看到抓取版本，把返回内容複製下来，搜尋正文開头的几個字，看是否存在于源碼中。
- 在浏览器里禁用 JavaScript 後打開頁面，看看還剩下多少可讀文字。如果只剩導航和一句提示，說明正文完全依赖脚本。
- 用命令行工具或在线抓取工具直接請求地址，確認服務器返回的 HTML 里的内容量，排除浏览器缓存带来的错觉。
- 對比渲染快照和原始源碼，確認两者内容是否一致、正文是否都完整。
- 顺带检查内鏈部分：如果分頁、下一篇、相關推荐都是脚本生成的，那么新頁面被發現的速度也會受影响。
做完這几步，基本能判断出頁面属于哪種情况：源碼里已有主体内容、只有部分内容依赖脚本，還是几乎完全空壳。
如果确實要改造，優先保住哪部分
- 让标题、正文主体、主要栏目連結和關键列表由服務端直接輸出，脚本负责的部分留给次要模块，比如评论、推荐、實时資料。
- 采用预渲染或動態渲染时，要保證返回给爬虫的版本和用戶看到的版本内容一致，避免出現两套差异很大的頁面。
- 無脚本降級内容不要只留一句提示，至少给出正文摘要、主要連結和必要說明。
- 不要為了省事把所有地址都强行返回同一份渲染结果，那會引入新的重复内容問题。
改造范围不必一次铺開，可以先從轉化價值高、外鏈多的頁面做起，观察一段時間後再决定是否扩展到全站。
連結和地图仍然决定頁面的被發現速度
渲染解决的是内容看得见的問题，URL 能不能被發現是另一件事。脚本生成的連結、只在彈窗里出現的入口，都可能让頁面迟迟進不了抓取队列。站点地图能帮助地址被發現，但被發現和被抓取、被收錄依然是不同的阶段，不能互相替代。
判断頁面為什么没有被收錄时，先確認爬虫拿到的源碼里有没有内容，再谈其他因素。很多所谓的内容质量問题，其實只是渲染問题。
观察节奏與常见誤区
改造上线後不要每天反复調整同一批頁面。先记錄改動時間，再看抓取日誌中爬虫訪問的频率和返回狀態，然後過几周再對照索引狀態和索引版本内容。改動生效需要時間，频繁推翻前面的調整只會让信号變得混乱。
另一個常见誤区是把渲染問题和内容质量問题混為一谈。如果源碼里本来就有完整正文、只是展示方式不同，那么收錄不理想的原因大概率不在這里，需要回到頁面质量、重复程度、内鏈结构上繼續排查。分清問题属于哪一层，才能少走弯路。