搜索引擎处理一个页面，通常可以粗略分成两段：先抓取服务器返回的 HTML，再根据资源情况执行页面里的脚本进行渲染。如果正文、链接、规范标签这些东西只在渲染后才出现，收录环节就要多等一步，甚至可能等不到。
抓取与渲染不是一回事
抓取阶段拿到的是原始 HTML，搜索引擎会把它存下来做初步解析，包括提取链接、识别文本、判断页面是否有实质内容。渲染阶段则要下载 JS、CSS 等资源，在类似浏览器的环境里执行，才能看到最终页面。这两步之间存在时间和资源成本，不同搜索引擎对渲染的支持程度和排队策略也不一样。
于是会出现一种情况：你在浏览器里看页面完全正常，蜘蛛抓到的却是一个只有容器标签的空壳。这不是页面坏了，而是它把内容放在了抓取环节看不见的位置。
三种渲染方式在收录上的差别
客户端渲染
HTML 里只有一个挂载节点，正文由脚本从接口取数据后写入。抓取阶段看不到正文，链接也提取不到。能不能进入索引，取决于搜索引擎是否愿意为这个页面付出渲染成本，越深层、越不被重视的页面越容易被跳过。
服务端渲染与静态生成
HTML 里直接带正文和链接，渲染只是补充。这类页面在抓取阶段就能被理解，收录路径相对短，也更容易被内链发现。
混合渲染
首屏由服务端输出，后续内容靠脚本加载。首屏正文和主导航能进 HTML 一般问题不大，但如果列表、分页、相关推荐全靠客户端拉取，链接发现会受影响，深层页面可能长期停留在未被发现的状态。
怎么确认蜘蛛拿到的内容
- 查看页面源代码，确认正文是否真的出现在源码里，而不是只在开发者工具的元素面板中。
- 用不执行脚本的方式请求 URL，对比返回的 HTML 与浏览器渲染后的文本差异。
- 翻服务器日志，看 JS、CSS 和接口请求里有没有蜘蛛的访问记录。如果这些资源从没被请求过，说明渲染大概率没有发生。
- 使用抓取工具或搜索平台提供的抓取测试，对比原始 HTML 与渲染后 HTML 的文本量。
几个容易忽略的细节
- 内链由脚本生成。蜘蛛拿不到链接，URL 发现这一环就断了，页面可能一直停在未发现状态。
- 正文藏在标签页、折叠面板或点击展开的区域里，渲染后存在，但是否被当作正文处理，取决于具体实现。
- 分页列表靠滚动加载，下一页链接不在 HTML 中，深层页面缺少入口。
- canonical、robots meta 由脚本动态插入，初始 HTML 里缺失时，判断依据会变得模糊。
- 接口返回 403 或需要登录态，渲染时取不到数据，页面渲染出来仍是空的。
建议的处理顺序
- 先把正文、标题、canonical 和内链放进服务端返回的 HTML，这是成本最低、收益最明确的一步。
- 把列表页和分页链接改成服务端输出，至少保证第一页之后的入口能被抓到。
- 对确实没法改架构的部分，再考虑预渲染或静态化，优先覆盖有收录价值的页面。
- 改完之后不要只看一次结果，隔一段时间对比日志里渲染资源请求是否出现变化。
一个简单的判断标准：在不执行脚本的情况下，如果页面的主要内容和链接都在，收录环节就少了一道不确定的关卡。