不少站点改版到前端框架之後，頁面在浏览器里看起来一切正常，但把 HTML 源碼拉出来，正文、标题、連結全都不在，只有一個空的挂载节点和几行脚本。對訪客没有影响，對依赖 HTML 抓取的程序来说，這個頁面基本就是一張空白纸。這篇文章说的就是怎么自查這件事。
為什么渲染方式會影响抓取
抓取大致分两步：先拿到 HTML 源碼，再决定要不要排队执行頁面里的 JavaScript，拿到渲染後的内容。第二步成本高、有延迟，而且不同引擎的执行能力、队列長度、超时時間都不一样。如果頁面完全依赖客戶端渲染，關键内容在一段時間内可能只以空壳的形式被看到。
這不是收錄與否的保證問题，而是内容送達难度的問题。頁面能少一层依赖，就少一层不确定性。
怎么判断自己的頁面属于哪種情况
最简單的方法不是打開開發者工具看 Elements 面板，那里顯示的是渲染後的结果，看不出問题所在。
- 在浏览器里右键查看網頁源代碼，搜尋正文里的一個關鍵詞，看它在不在。
- 用命令行抓一次，例如 curl 頁面地址，把輸出儲存下来再搜尋關鍵詞。
- 把 JavaScript 關掉再打開頁面，观察首屏是否還有主要内容。
- 用搜尋引擎提供的抓取測試工具，對比原始 HTML 與渲染後 HTML 的差异。
常见的几種空白表現
- 正文全部由接口返回後插入，源碼里只有加载占位。
- title、description、canonical、h1 由脚本執行时寫入，源碼里是預設值或者干脆没有。
- 列表頁用無限滚動，翻頁不是真正的連結，第二頁之後的内容很难被逐层跟随。
- 首屏图片用了懒加载，真實地址寫在 data-src 上，src 是占位图，抓取时拿不到图片。
- 路由使用 hash 形式，多篇不同内容共用同一個可抓取地址。
- 内鏈是按钮加点击事件，頁面上看得见点得動，但没有可跟随的連結。
一份可以照着做的自查清單
- 對一個典型詳情頁执行原始抓取，確認正文首段、小标题是否存在于源碼中。
- 分別检查首頁、栏目頁、詳情頁三類模板，不要只测一個頁面。
- 確認 title、h1、canonical 在源碼里就已经是最终值，而不是脚本补上的。
- 检查分頁與列表入口是否為可点击、可跟随的連結，而不是纯 JS 事件。
- 检查首屏图片的真實地址是否直接出現在 img 标簽的 src 中。
- 確認 robots.txt 没有拦截承载内容的 JS、CSS 文件，否則渲染本身就會失敗。
- 检查接口請求是否依赖登入態或特殊請求头，抓取时是否返回空資料。
- 检查渲染後頁面的内容與 canonical、结构化資料是否一致，避免出現两套内容。
處理顺序建议
如果自查發現問题，不必一次性大改，可以按投入产出排序：
- 先把首屏關键内容服務端輸出，比如标题、正文前几段、主要連結，這一步收益最大。
- 把詳情頁、列表頁的分頁連結改回真實連結，保證能逐层被跟随。
- 頁面路由尽量使用普通路径，避免把内容藏在 hash 後面。
- 短期做不到服務端渲染，可以考虑预渲染或静態生成，先把已發布内容渲染成 HTML。
- 動態渲染只作為過渡方案，注意给用戶和抓取程序的内容要保持一致。
给抓取程序看的内容和给用戶看的内容必须一致。為爬虫單獨准备一套简化頁面，短期也许有效，但一旦被识別為伪装，代價遠大于收益。
把它放進上线流程
渲染方式的問题往往在改版时集中出現：以前是模板直出，重构後變成前端渲染，頁面看起来更現代了，内容却變得难抓。建议在發布清單里加一條：新模板上线前，用原始抓取的方式检查一遍源碼，確認關键内容、連結、标题都在里面。這一條检查花不了几分钟，但能省掉後面几周反复排查的時間。