页面在浏览器里打开得好好的，收录表现却一直不理想，这类现象里有一部分原因出在渲染方式上。搜索引擎抓取一个 URL 时，第一步拿到的是服务器返回的 HTML 响应，而不是你在浏览器里看到的最终样子。把内容写进页面，是浏览器执行脚本之后才发生的事，这两件事之间隔着一步。
抓取拿到的和你看到的，往往不是同一个东西
一次抓取大致是这样走的：请求 URL、拿到响应、解析 HTML、从里面提取正文、标题、链接等信号。如果响应里已经有这些内容，流程到此基本完成。如果响应里只有一段脚本，真正的内容要执行脚本之后才生成，那么页面会被放进渲染队列，等资源到位、脚本执行完，才有机会被读懂。
渲染本身并不是缺陷，现在的搜索引擎确实具备执行 JavaScript 的能力。问题在于渲染有排队、有资源依赖、也有失败的可能。页面越依赖脚本，中间环节越多，内容被完整读到的确定性就越低。
能被抓取，不代表内容已经被读到。抓取记录里出现了一个 URL，只说明对方来过了，不说明它看懂了页面上有什么。
先判断：你的页面到底依不依赖渲染
- 关闭 JavaScript 再看一遍。在浏览器里禁用脚本后刷新页面，如果正文、标题、主要栏目入口都消失了，说明关键内容主要靠客户端生成。
- 看网页源代码，而不是审查元素。右键查看源代码得到的是服务端返回的原始 HTML；开发者工具里看到的是脚本执行后的 DOM，两者经常差别很大。
- 直接看响应内容。用命令行请求一次，或在抓取测试类的工具里查看返回的 HTML，判断其中是否包含实质文字。
- 对照搜索结果里的标题和摘要。如果展示的标题是默认标题、摘要也含糊，值得回头确认服务端到底输出了什么。
这几条都是排查方向，用来缩小范围，不等于据此就能得出收录结论。
要改的话，优先动这几处
把关键内容放进首次响应
标题、正文主体、发布时间、列表项、面包屑这类决定页面主题的内容，尽量由服务端输出。常见做法是服务端渲染、预渲染或静态化，具体选哪种取决于站点架构，不必一步到位，先把最重要的模板改掉即可。
站内链接用真链接
导航和列表如果靠脚本绑定点击事件跳转，抓取阶段可能看不到可跟进的地址。用带 href 的链接标签，能让 URL 发现这条路径稳一些，也让页面层级更清楚。
别把重要内容藏在交互之后
需要点击、滚动、切换标签才会出现的内容，在第一次响应里通常是缺失的。如果这部分内容对判断页面主题重要，尽量让它默认可见，或至少保证有一个不需交互的直出版本。
保证渲染所需资源可访问
脚本和样式文件如果被拦截，渲染可能无法完成。检查相关目录是否被规则挡住，接口请求是否对抓取方开放。这一步只是减少渲染失败的可能，并不意味着内容一定会被采纳。
几个容易走偏的想法
- 渲染一次就够了。渲染结果通常不会被长期保存，页面更新后仍要重新走一遍流程。
- 提交了地址就会收录。提交解决的是发现，不解决服务端返回空壳的问题。
- sitemap 能补上内容。它只列地址，不携带页面正文。
- 只要脚本能跑就没问题。脚本能跑和抓取方能跑，是两码事。
小结
并非所有脚本渲染的页面都会出问题，很多站点也确实能被正常处理。但如果收录节奏长期偏慢，而服务端返回的 HTML 里几乎没有内容，这往往是值得优先处理的一环。把关键内容前移到首次响应，是在不改变内容质量的前提下，减少一道不确定性的做法。至于最终是否收录、如何展示，仍由搜索引擎自行判断。