做站点运营时，经常遇到一种情况：自己在浏览器里看页面一切正常，标题、价格、正文都在，但蜘蛛抓到的内容却少得可怜，甚至只有导航和页脚。问题往往不在内容本身，而在页面是怎么渲染出来的。
先分清“用户看到的”和“蜘蛛拿到的”
搜索引擎抓取时，第一步拿到的是服务器返回的原始 HTML。如果正文是通过 JavaScript 在浏览器里执行后才插入的，那么原始 HTML 里就可能只有一句“加载中”或一个空的容器。后续虽然也会做渲染，但渲染是有成本的，不一定每个 URL 都能等到那一步。所以自查的第一件事，是把页面的原始 HTML 拿出来看，而不是只看浏览器里的最终效果。
三种常见渲染方式的风险点
服务端渲染
服务器直接把完整 HTML 吐出来，蜘蛛拿到的和用户看到的基本一致，风险最低。要注意的是模板里有没有把主要内容包在需要异步加载的区块中，以及首屏之外的分页内容是否也在 HTML 里。
客户端渲染
页面骨架先返回，内容靠接口异步填充。这种结构对蜘蛛最不友好。如果站点主体是这种形式，至少要保证核心内容在无脚本环境下有一定呈现，或者为关键栏目准备可被抓取的静态版本。
混合渲染与渐进增强
一部分内容直出，一部分靠脚本补充。这类最容易出问题：直出的部分可能只是标题和几句摘要，真正有价值的长文本、参数、图集都在后面。需要逐个模板确认，哪些字段是直出的，哪些是后补的。
一次可执行的渲染自查清单
- 关闭 JavaScript 打开页面，记录还能看到哪些内容。
- 查看网页源代码，搜索正文中的一段独有文字，确认是否出现在原始 HTML 里。
- 对比原始 HTML 与渲染后的 DOM，看差异集中在哪些区块。
- 检查重要入口链接是否写在 HTML 的 a 标签里，而不是靠脚本点击生成。
- 确认分页、筛选、详情页等模板各自的表现，不要只测首页。
- 把结果记成一张表，标出模板名、风险等级、负责同事。
发现问题后，按这个顺序处理
- 先处理详情页和栏目首页，这些页面通常承载主要内容和入口。
- 把关键文本、标题、价格、更新时间等字段改为直出，非关键交互再交给脚本。
- 给列表页补上可点击的静态链接，保证不执行脚本也能走到下一层。
- 改完后重新做一次原始 HTML 对比，确认改动生效。
- 在抓取日志里观察这些模板的抓取量和返回内容是否随之变化。
渲染方式属于网站底层结构，调整周期通常以周计，不要指望改一处就立刻看到明显变化。先把“蜘蛛能拿到什么”这件事看清楚，再谈其他优化。
把渲染自查纳入例行的站点巡检，和链接、响应码、Sitemap 放在同一张清单里，能减少很多“内容明明更新了，蜘蛛却没反应”的困惑。