很多站点在浏览器里打開一切正常，但抓取到的 HTML 里几乎没有正文。問题往往不在服務器，而在于頁面把關键内容交给了 JavaScript 在客戶端拼装。做一次渲染自查不需要多高深的技術，只要愿意用最朴素的方式，看一遍原始响應。
先確認：蜘蛛看到的和你看到的是不是同一份東西
浏览器會执行脚本、加载样式、填充内容，你看到的是渲染之後的结果；而抓取拿到的第一手资料，是服務器返回的原始 HTML。如果正文、主要連結、标题层級都只在渲染之後才出現，那么後續的索引、内鏈传递和内容判断都會打折扣。
自查方法很朴素：
- 用命令行請求頁面，把返回的 HTML 存成文件，直接在文本里搜尋正文中的几個關鍵詞。
- 在浏览器里禁用 JavaScript 再打開同一地址，看還能剩下多少内容。
- 查看源代碼，確認導航與列表里有没有完整的 a 标簽 href，而不是只有 onclick 或 data-href。
四類最常见的坑
一、連結不是連結
用 div 加点击事件来實現跳轉，人点得動，抓取端讀不到。列表頁、導航、相關推荐里如果大量使用這種寫法，等于把内鏈入口關掉了。可点击的元素應当有真實的 href，脚本只负责增强体驗。
二、正文靠懒加载或交互才出現
折叠面板、标簽切換、点击展開全文才顯示的内容，如果預設不輸出到 HTML，就等同于不存在。更稳的做法是把首屏核心内容直接服務端輸出，交互只影响展示顺序。
三、元信息與结构化資料由脚本注入
标题、描述、canonical、结构化資料如果全靠脚本寫入 head，容易因為执行失敗或时机不對而丢失。這些關键信息建议在服務端就寫進 HTML，脚本只做兜底。
四、無限滚動與加载更多
滚動自動加载的列表，抓取端很难完整遍歷。保留可訪問的分頁地址，或者在列表里提供下一頁的真實連結，让列表有终点可走。
一份可执行的自查清單
- 取一篇文章頁、一個列表頁、一個首頁，分別儲存原始 HTML。
- 检查原始 HTML 中是否包含正文主体、主标题和主要導航連結。
- 检查是否有可讀的 title、description 與 canonical。
- 確認分頁或加载更多背後存在真實 URL。
- 確認關键的 CSS 與 JS 没有被 robots 規則挡住，渲染所需资源能正常获取。
- 對比原始 HTML 與渲染後的文本差异，差异越大越值得優先處理。
改的时候按顺序来
優先解决内容有没有的問题，再解决好不好看的問题。顺序大致是：先让正文和連結出現在服務端返回的 HTML 里，再處理元信息，最後才考虑渲染性能與资源体积。
- 能用服務端渲染或预生成的部分，尽量前置。
- 必须靠脚本的部分，保證首次渲染不依赖用戶点击。
- 避免把大段正文藏在需要授權或二次請求的接口後面。
改完怎么驗證
- 用搜尋平台提供的網址检查工具，對比原始 HTML 與渲染後 HTML。
- 观察抓取记錄中该目錄返回的内容体积是否回到合理水平。
- 過一段時間再看索引與展現的變化，不要指望当天见效。
渲染方案没有绝對優劣，稳定和可预期更重要。技術再新，如果抓取端每次拿到的内容都不一样，站点运营就很难做長期判断。
最後提醒一句：渲染自查不是一次性任務。前端框架升級、组件重寫、加载策略調整，都可能让原本正常的頁面重新變回空壳。把它放進改版流程里，比事後排查省事得多。