先记住这个答案
SSR 或预渲染能在 HTTP 响应里提供页面正文、可抓取链接和标题等元信息，让用户及抓取程序更早获得页面含义，并减少对客户端脚本成功执行的依赖。不能说 CSR 一定无法收录：Google 能渲染 JavaScript，但渲染存在处理流程和限制，其他抓取程序也不一定执行脚本。社交分享需要核对平台能否读取对应 URL 的 Open Graph 等信息。SSR 不是排名或收录保证，状态码、规范地址、可访问性和原创内容同样必须正确。
- SSR 减少关键内容对客户端执行的依赖
- Google 能渲染 JavaScript，CSR 并非必然不能收录
- sitemap 帮助发现 URL，不保证索引和排名
初始正文可以减少等待和失败环节
如果响应只有空壳，抓取程序需要执行脚本并取得数据后才能理解主体内容。SSR 将已有正文直接放入响应，使正文读取不完全依赖这条客户端链路；静态生成也能获得类似的初始 HTML 优势。
Google 的流程包含抓取、渲染和索引，能够处理很多 JavaScript 页面，因此不能以是否 CSR 直接判断收录结果。应检查脚本资源是否可抓取、接口是否可用、渲染后正文是否完整，以及页面是否错误地带有 noindex。
分享卡片需要页面自己的元信息
公开题目页应有与正文一致的标题和描述，分享信息也应指向该题目及可访问图片。若每个 URL 都返回相同首页标题或只在用户操作后更新元信息，分享程序未必能得到正确卡片。
Open Graph 定义了标题、类型、图片和规范对象地址等基本字段，具体平台如何缓存和展示仍要用其实际抓取结果验证。图片无法公开访问、地址跳转异常或旧卡片缓存，都不能仅靠启用 SSR 自动解决。
从规范 URL 到正文逐层验证
先直接访问页面确认状态码和正文，再检查 canonical 是否指向该内容的规范地址、内部链接是否真实可跟随。缺失题目应返回合适的不存在状态，而不是全部返回二百和一段空内容，这会干扰页面理解。
汇总分页与 sitemap 可以补充发现路径，但提交站点地图只是告知地址，并不保证立即抓取或收录。应区分本地生成 XML、生产 URL 可访问、平台提交成功和实际索引四个结果，各自保留证据。
容易答错的地方
- 认为只要 SSR 就能覆盖所有关键词排名
- SSR 解决部分内容交付问题，不能替代独立搜索意图、准确答案和自然内链。大量只有关键词替换的相似页面仍缺少用户价值，应先把正文与主题边界做好，再分析真实搜索表现。
- 把站点地图里有地址当成已经收录
- 站点地图是发现线索，抓取与索引由搜索引擎进一步处理。需要检查公开地址、提交回执和索引状态，不能把仓库文件数量或本地 XML 条目数量直接当作搜索结果中的页面数量。
面试官还会怎么问？
不把 SEO 内页放到主菜单会影响发现吗？
主菜单不是唯一入口。可以通过有真实链接的汇总页、分类分页、相关问题和 sitemap 建立发现链，但页面不能长期成为没有内部链接的孤页；内容也应能被搜索进入的用户直接阅读。
canonical 能解决所有重复页面吗？
不能把它当作强制覆盖所有信号的命令。应统一内部链接、站点地图和规范 URL，合理处理参数与重复路径，并确保声明与内容对应；重复内容治理不能只靠加一个标签结束。
怎样验收这类页面的 SEO 基础？
分别检查原始响应、浏览器渲染结果、关键链接、状态码和元信息，再用搜索平台的 URL 检查及站点地图状态确认抓取侧结果。分享卡片单独验证，避免把浏览器看着正常当作所有程序读取正常。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。