現在很多站点為了交互，正文、列表、图片都靠脚本在浏览器里渲染。用戶看着没問题，但從抓取角度看，服務器返回的原始 HTML 里可能只有一個空壳。蜘蛛進来看到的和用戶看到的不是同一份内容，URL 發現和内容理解都會受影响。這篇聊聊怎么自查。
為什么要专门查這件事
抓取程序通常分两步：先拿到服務器返回的 HTML，再决定要不要执行脚本。执行脚本是有成本的，很多抓取方只执行一部分，或者干脆不执行。如果正文、内鏈、列表都在脚本里，等于把内容發現權交给了別人愿不愿意多跑一步。
先確認頁面属于哪種類型
- 服務端渲染：HTML 里就有完整正文和連結，最稳。
- 同构或预渲染：首次返回的 HTML 里有内容，脚本负责後續交互，一般没問题。
- 纯客戶端渲染：HTML 是空壳，内容全靠接口拼出来，風險最大。
先把自己站点的頁面按這三類分一遍，重点盯第三類。
几個常见的坑
正文等接口返回才出現
頁面源碼里只有一個挂载节点，正文靠接口拉。這種情况要確認接口返回的内容能不能被單獨訪問，以及有没有對應的静態或预渲染版本。
“加载更多”和無限滚動
列表第二頁之後的内容如果只在点击时用脚本插入，且没有獨立 URL，那這些内容基本等于只對用戶可见。能给出分頁地址的方案，通常比纯滚動更利于發現。
图片用 data-src 占位
懒加载的常见做法是把真實地址寫在 data-src 里，src 先放占位图。如果抓取方不执行脚本，就只能看到占位图。要检查首屏图片是否至少有正常的 src。
交互控件替代了連結
有些入口寫成了 div 加点击事件，没有 href。用戶能点，抓取方找不到地址。能改成带 href 的連結就改，交互用脚本增强即可，但地址本身別藏起来。
自查怎么做
- 浏览器里禁用 JS，重新打開几個典型頁面，看有没有正文、有没有可点連結。
- 用命令行工具直接請求頁面，只看原始 HTML，對照渲染後的内容差多少。
- 挑首頁、栏目頁、詳情頁各两三個逐步查看差异，別只看首頁。
- 检查列表頁的下一頁、加载更多有没有可訪問的 URL。
- 检查詳情頁正文所在容器在原始 HTML 里是否為空。
- 把差异记錄下来，标注是“必要渲染”還是“可以预置”。
改造思路
- 核心内容優先服務端輸出，交互部分再用脚本增强。
- 列表分頁给出可訪問地址，滚動加载只作為补充。
- 首屏图片用真實 src，後續图片再做懒加载。
- 關键入口保持可点击的連結，不要只依赖事件。
- 如果架构短期改不了，至少做好预渲染或静態快照。
判断标准很简單：把脚本關掉，頁面還剩多少能被讀到的内容和入口。剩得越多，站点越稳。
多久查一次
改版、換框架、上线新模板之後必查一遍。平时可以按季度抽查，重点看模板有没有被前端改動带偏。