用浏览器打開頁面，正文、图片、评论都正常顯示，但在“查看網頁源代碼”或抓取工具返回的响應里，正文区域却是空的。這種頁面往往不是内容质量問题，而是渲染方式的問题：搜尋引擎第一次拿到的是服務端返回的 HTML，里面没有内容，後面能不能补上，取决于它是否愿意再花资源执行頁面脚本。
先分清你看到的是哪一份頁面
日常在浏览器里看到的，是脚本执行完之後的 DOM；而爬虫首先拿到的是服務器返回的原始 HTML。两者经常不是一回事。核對时可以用几種简單方式對比：
- 在浏览器里右键“查看網頁源代碼”，搜尋正文中的關鍵詞，看是否出現；
- 用抓取工具或命令行請求该 URL，看响應内容里有没有正文和連結；
- 在浏览器設定中關閉 JavaScript 再刷新頁面，观察還剩下什么。
如果關閉脚本後頁面几乎只剩框架和占位符，說明核心内容依赖渲染。這时再讨论收錄，就不是内容差异度的問题，而是内容有没有被拿到的問题。
渲染能力有差別，不要預設所有引擎都會执行脚本
主流搜尋引擎具备一定的渲染能力，但渲染通常要排队，消耗的资源也比直接讀取 HTML 高。對抓取预算有限的站点来说，依赖渲染的頁面在處理顺序上往往更靠後，延迟也更明顯。不同引擎對脚本的支持程度並不一致，把關键内容完全交给前端，等于把不确定性留在了收錄鏈路的第一环。
常见的“内容藏在渲染之後”的情况
- 正文由接口异步返回，初始 HTML 只有骨架；
- 内容預設折叠，需要点击“展開更多”才顯示；
- 列表采用無限滚動，首屏之後的資料靠後續請求加载；
- 選項卡切換的内容，未選中的部分不在初始 HTML 中；
- 图片使用 data-src 懒加载，初始 HTML 里没有真實图片地址。
這些做法對用戶体驗未必是坏事，但要判断其中哪些内容是你希望被搜到的，哪些只是辅助展示。希望被搜到的部分，最好在初始响應里就能看到。
連結發現同样受影响
内容之外，入口也常被忽略。如果站内跳轉用的是 onclick 事件、button 元素或前端路由，而不是可点击的 a 标簽，爬虫在初始 HTML 里就找不到目标地址。列表頁、分頁、相關推荐如果全部由前端渲染，深层頁面缺少可跟随的連結，發現速度會明顯變慢。检查时可以在關閉脚本的情况下走一遍站内導航，看還能不能顺着連結到達重点頁面。
可以按這個顺序核對和調整
- 先確認初始 HTML 里有什么：正文、标题、内鏈、canonical 是否齐全；
- 把最需要被收錄的正文改為服務端輸出，或做预渲染；
- 站内跳轉恢复成标准的 a 标簽連結，避免只靠脚本跳轉；
- 列表和分頁提供可抓取的連結入口，不依赖首次請求之外的加载；
- 首屏之外的内容如果重要，考虑改為服務端分頁或獨立 URL；
- 改完後對照服務器日誌，看爬虫拿到的响應是否包含正文，再观察收錄變化。
不必全站推倒重来
全站改成服務端渲染成本不低，也没有必要。可以先按頁面價值排序：承担搜尋流量的詳情頁、栏目頁優先處理，交互性强、本就不指望被搜到的功能頁保持現状即可。判断标准很简單——這個頁面希望被搜到吗？如果希望，就在初始 HTML 里给它一份完整内容。
收錄問题的排查顺序，通常是先看爬虫拿到了什么，再看它是否選擇收錄。渲染方式影响的是前者，而這往往是後面所有环节的前提。
最後提醒一点：渲染方式的調整不會立刻带来收錄變化，索引更新有自身节奏。把响應 HTML 里的内容补齐、把連結入口理顺，剩下的交给時間和持續的日誌观察。