很多站点在浏览器里看起来一切正常，标题、正文、图片都在，但搜索引擎拿到的原始 HTML 里可能只有一个空壳容器和几段脚本。这种情况在纯前端渲染的单页应用、以及把正文交给 JS 异步加载的页面上尤其常见。抓不到内容，后面的索引和排名自然无从谈起。
先用三个动作确认自己属于哪种情况
不用急着改代码，先做基础判断：
- 查看源代码：在浏览器里右键“查看网页源代码”，看正文是否直接出现在返回的 HTML 中，而不是等到 JS 执行后才出现。
- 关闭 JavaScript：禁用 JS 后刷新页面，如果只剩导航骨架和一片空白，说明主要内容依赖客户端渲染。
- 用命令行请求：用 curl 或类似工具请求一次目标 URL，观察返回内容里有没有关键词、正文、内链。
三个结果如果都不理想，就不要再纠结，直接进入改造清单。
不同渲染方式的取舍
服务端渲染与静态生成
这两种方式返回的 HTML 里已经带有完整内容，对蜘蛛最友好，也最适合内容型页面。静态生成适合更新频率不高的栏目页、详情页；服务端渲染适合内容实时变化、需要按请求组装的页面。
客户端渲染
并非不能用，但正文、标题、关键内链最好别完全依赖它。后台管理、登录后可见的功能页用客户端渲染没什么问题，因为它们本来也不指望被收录。
预渲染与动态渲染
没法马上改架构时，可以先用预渲染把重要页面在构建时生成静态 HTML；动态渲染的成本更高，且要谨慎使用，避免出现给蜘蛛和访客两套不同内容的做法。
骨架屏与懒加载的边界
骨架屏对体验有帮助，但它只是占位，不能替代真实内容。懒加载图片、按需加载的模块，如果连首屏正文都被延迟，蜘蛛很可能只看到占位符。把关键内容放在懒加载范围之外，是更稳妥的选择。
自查清单
- 核心栏目页、文章详情页返回的 HTML 中能否找到正文首段和主要标题。
- 标题、描述、canonical 是否在原始 HTML 里就存在，而不是由脚本后插。
- 列表页的文章链接是否为可点击的 a 标签，而不是 onclick 事件或 div。
- 分页、翻页入口是否在初始 HTML 中。
- 面包屑和主导航是否直接输出，而不是等接口返回后再渲染。
- 首屏图片是否有正常的 img 或合适的替代方案，尺寸是否声明。
- 路由是否为真实路径，能否直接访问并返回 200，而不是全部落在同一个外壳上。
首屏关键内容优先
如果一时无法全站改造，至少把最有价值的栏目页和详情页做成服务端输出。判断标准很简单：这些页面是你希望被搜索到的页面，它们的内容就应该在第一次响应里出现。
给蜘蛛准备一套内容、给用户准备另一套内容，属于典型的作弊手法，短期也许有效，长期风险很高。合理的做法是把同一份内容用更可靠的方式送到两边手里。
改造后的复查
改造完成后，重新用 curl 和禁用 JS 的方式各查一遍，确认正文、内链、标题都出现在原始响应里。再观察一段时间服务器日志中蜘蛛对重要页面的抓取情况，对比改造前后有没有变化。如果日志里出现大量只抓 HTML 外壳、不深入内容的记录，通常说明渲染问题还没解决干净。
渲染方式不是一次性的技术选型，而是会随着前端框架升级、组件重构而变化。建议把它列进站点例行自查项目，每次大改版后都拿出来过一遍。