很多站長都遇到過這種情况：在浏览器里打開頁面一切正常，标题、正文、图片都在，但蜘蛛抓到的 HTML 源碼里只有几行 div 和一句加载中的提示。訪客看到的是渲染後的结果，蜘蛛收到的是渲染前的骨架，两者並不是一回事。
当頁面主体内容依赖 JavaScript 在浏览器端生成时，搜尋引擎需要額外执行脚本才能看到内容。這個過程不是必然失敗，但會增加成本，也會放大不确定性。對站点运营来说，把這件事提前查清楚，比事後反复猜测為什么頁面不收錄要省力得多。
一、先確認蜘蛛拿到的是什么
不用复杂工具，三種方式就能看出大概：
- 查看源代碼：在浏览器里按 Ctrl+U，或者用 curl 拉一次頁面，看返回的 HTML 里有没有正文文字。如果只有脚本引用和容器标簽，說明内容是後渲染的。
- 禁用 JavaScript：在浏览器開發者工具里關掉 JS 再刷新，頁面如果變成大片空白或只剩導航，說明主体内容强依赖脚本。
- 渲染结果對比：主流搜尋平台都提供抓取或渲染结果的查看入口，把原始 HTML 和渲染後的 HTML 對比一下，差异越大越值得處理。
二、哪些寫法容易让頁面變成空壳
- 整站使用前端路由，所有頁面共用一份 HTML 模板，正文靠接口返回後再拼進 DOM。
- 内容接口需要登入態或特定請求头，蜘蛛請求时拿不到資料，只能得到空结果。
- 列表和分頁連結用点击事件模拟跳轉，源碼里没有可跟随的 a 标簽。
- 图片和正文采用懒加载，首屏之外的内容在未滚動时根本不存在于 DOM 中。
- robots.txt 里屏蔽了 JS 或 CSS 文件，渲染时脚本和样式缺失，頁面结构错乱。
其中最後一條最容易被忽略。為了让日誌干净，有人顺手把静態资源目錄屏蔽掉，结果渲染环节直接缺了脚本，反而帮了倒忙。
三、可以怎么處理
- 關键内容服務端直出：标题、正文、價格、發布時間這類核心信息，尽量在首次响應里就出現在 HTML 中，交互部分再交给脚本處理。
- 引入预渲染或服務端渲染：内容型站点用静態生成或服務端渲染是性價比較高的方案，改動集中在构建流程或中間层，不必重寫整個前端。
- 把導航連結寫成真實的 a 标簽：栏目、列表、分頁、面包屑的跳轉地址寫進源碼，蜘蛛才能顺着連結繼續走下去。
- 合理放行资源：確認 robots.txt 没有挡住渲染所需的脚本和样式文件，同时核對接口返回的头部有没有意外的 noindex。
- 保留一份兜底内容：即使用戶端渲染，也建议在初始 HTML 里保留最基本的說明文字和站内連結，让頁面在脚本失敗时仍然可讀。
四、處理完记得回头看日誌
調整之後，观察几天服務器訪問日誌或抓取統計，看看目标地址的抓取次數、返回狀態碼和抓取到的字节數有没有變化。如果字节數長期很小，往往意味着蜘蛛仍然只拿到骨架。這個反馈比任何主观判断都更可靠。
把内容放在 HTML 里，是让頁面被理解和被發現最省事的方式。渲染技術可以不断演進，但不要让核心内容成為脚本的附属品。