做站点运营时，经常遇到一種情况：自己在浏览器里看頁面一切正常，标题、價格、正文都在，但蜘蛛抓到的内容却少得可怜，甚至只有導航和頁脚。問题往往不在内容本身，而在頁面是怎么渲染出来的。
先分清“用戶看到的”和“蜘蛛拿到的”
搜尋引擎抓取时，第一步拿到的是服務器返回的原始 HTML。如果正文是通過 JavaScript 在浏览器里执行後才插入的，那么原始 HTML 里就可能只有一句“加载中”或一個空的容器。後續虽然也會做渲染，但渲染是有成本的，不一定每個 URL 都能等到那一步。所以自查的第一件事，是把頁面的原始 HTML 拿出来看，而不是只看浏览器里的最终效果。
三種常见渲染方式的風險点
服務端渲染
服務器直接把完整 HTML 吐出来，蜘蛛拿到的和用戶看到的基本一致，風險最低。要注意的是模板里有没有把主要内容包在需要异步加载的区块中，以及首屏之外的分頁内容是否也在 HTML 里。
客戶端渲染
頁面骨架先返回，内容靠接口异步填充。這種结构對蜘蛛最不友好。如果站点主体是這種形式，至少要保證核心内容在無脚本环境下有一定呈現，或者為關键栏目准备可被抓取的静態版本。
混合渲染與渐進增强
一部分内容直出，一部分靠脚本补充。這類最容易出問题：直出的部分可能只是标题和几句摘要，真正有價值的長文本、參數、图集都在後面。需要逐個模板確認，哪些字段是直出的，哪些是後补的。
一次可执行的渲染自查清單
- 關閉 JavaScript 打開頁面，记錄還能看到哪些内容。
- 查看網頁源代碼，搜尋正文中的一段獨有文字，確認是否出現在原始 HTML 里。
- 對比原始 HTML 與渲染後的 DOM，看差异集中在哪些区块。
- 检查重要入口連結是否寫在 HTML 的 a 标簽里，而不是靠脚本点击生成。
- 確認分頁、篩選、詳情頁等模板各自的表現，不要只测首頁。
- 把结果记成一張表，标出模板名、風險等級、负责同事。
發現問题後，按這個顺序處理
- 先處理詳情頁和栏目首頁，這些頁面通常承载主要内容和入口。
- 把關键文本、标题、價格、更新時間等字段改為直出，非關键交互再交给脚本。
- 给列表頁补上可点击的静態連結，保證不执行脚本也能走到下一层。
- 改完後重新做一次原始 HTML 對比，確認改動生效。
- 在抓取日誌里观察這些模板的抓取量和返回内容是否随之變化。
渲染方式属于網站底层结构，調整周期通常以周計，不要指望改一處就立刻看到明顯變化。先把“蜘蛛能拿到什么”這件事看清楚，再谈其他優化。
把渲染自查纳入例行的站点巡检，和連結、响應碼、Sitemap 放在同一張清單里，能减少很多“内容明明更新了，蜘蛛却没反應”的困惑。