先分清抓取和渲染是两步
搜索引擎处理一个 URL，通常先取回服务器返回的 HTML 源码，再判断要不要把它放进渲染队列执行脚本。渲染要消耗额外的计算资源，所以并不是每个页面都会立刻渲染，也不是每次渲染都能把所有脚本顺利跑完。内容如果只存在于脚本执行之后，等于把被发现的机会押在了这一步上。
这也是为什么同一套前端框架，有的站点抓取覆盖不错，有的却长期只有首页和几个栏目页被收录。差别往往不在框架本身，而在关键内容和链接是否出现在源码里。
哪些内容最容易在渲染前看不见
- 内链：用脚本拼接出来的导航、列表和相关推荐，源码里没有可点的 href，蜘蛛就找不到下一跳。
- 分页与加载更多：靠按钮点击触发的列表，缺少可以直接访问的分页 URL。
- 正文主体：接口返回后再插入页面的文字，源码里往往只剩一个空容器。
- 标题与元信息：页面标题、描述、canonical 若由脚本写入，渲染前可能是缺失或默认值。
- 结构化数据：需要在客户端注入的标记，渲染失败时不会留下任何痕迹。
让蜘蛛少依赖脚本的几种做法
- 关键内容走服务端渲染或静态生成，至少保证首屏正文和主要内链出现在 HTML 源码中。
- 列表页给出真实可访问的分页地址，而不是只留一个点击事件。
- 异步加载的区域，提供无脚本也能读到的备用链接，作为兜底入口。
- 把渲染后才出现的 URL 同步进 Sitemap，让它们有一条不依赖脚本的发现通道。
- 渲染压力大的页面，减少第三方脚本和串行请求，让关键内容更早进入 DOM。
渲染排队也会影响发现节奏
即便页面最终能被渲染，排队本身也有先后。首屏依赖大量脚本、报错频繁或请求超时的页面，被完整渲染的概率会打折扣。相比之下，源码里已经有正文和链接的页面，即使渲染慢一点，URL 发现和基本内容判断也不会中断。
怎么确认自己页面被看到的样子
- 查看页面源代码，而不是开发者工具里的元素面板，确认正文和内链是否真实存在。
- 用抓取工具对比原始 HTML 与渲染后 HTML，列出两者的差异清单。
- 在服务器日志里核对这些 URL 有没有被访问、返回什么状态、响应体有多大。
- 对关键路径做一次检查，确认脚本失效时页面里是否还有可走的链接。
不必追求全部交给渲染
渲染是有限资源，不适合承担全部的 URL 发现和内容理解。更稳妥的思路是：能静态呈现的部分尽量静态，必须异步的部分给出可抓取的替代路径，再用 Sitemap 和内链把关键 URL 稳定地交出去。
一个简单的自检方式：关掉 JavaScript 之后，页面里还剩多少正文、还剩多少条能走的链接。剩下的这部分，基本就是蜘蛛在渲染前能拿到的东西。