网站收录

服务端渲染、预渲染、客户端渲染:三种方式对收录的实际差别

搜索引擎抓页面时,最先拿到的是服务器返回的原始 HTML。如果标题、正文和内链都靠 JavaScript 在浏览器里生成,蜘蛛首轮可能只看到一个空壳。本文对比服务端渲染、预渲染和客户端渲染三种方式在抓取与收录上的实际差别,并给出自查顺序和折中做法。

网站收录

服务端渲染、预渲染、客户端渲染:三种方式对收录的实际差别

蜘蛛拿到的是什么

搜索引擎抓取一个 URL 时,第一步拿到的是服务器返回的原始 HTML。它不会像浏览器那样先把页面里的脚本全部执行完再决定看什么,至少第一步不是。如果正文、标题、内链都靠 JavaScript 在浏览器里生成,蜘蛛第一次拿到的可能只是一个空壳:几个 div、一段脚本引用,正文一个字都没有。

后续搜索引擎确实会用渲染服务再跑一遍页面,把 JS 执行后的内容补上。但这一步是排队进行的,不是每次抓取都必然完成,渲染资源也有上限。所以“能渲染出来”和“每次都稳定渲染出来”之间,差别并不小。

三种渲染方式抓到的内容差在哪

  • 客户端渲染(CSR):服务器返回的 HTML 基本是空的,内容由浏览器执行 JS、请求接口后拼接。蜘蛛首轮拿到的内容最少,能否拿到完整内容取决于有没有排进渲染队列。
  • 服务端渲染(SSR):HTML 返回时正文已经在里面。蜘蛛看到的和用户看到的差别最小,是最省心的做法,代价是服务器压力略高一些。
  • 预渲染 / 静态生成:在构建或缓存阶段就把 HTML 生成好,访问时直接返回。适合内容不频繁变化的页面。

哪些页面最容易受影响

不是所有带 JS 的页面都有问题,风险高的通常是这几类:

  • 详情页正文、商品描述、文章内容靠接口异步加载;
  • 列表页的链接由 JS 生成,原始 HTML 里没有任何可点的链接;
  • 分页、筛选、排序全部走前端路由,URL 不随状态变化;
  • 首屏之外的区块,比如评论和相关阅读,延迟加载。
判断标准很直接:看原始 HTML 里有没有核心内容。如果关掉 JS 后正文和内链都消失,收录就会变得不稳定。

动手检查的顺序

  1. 用“查看网页源代码”(不是检查元素)看服务器返回的 HTML,确认标题、正文、主要内链是否在里面。
  2. 用抓取工具或命令行请求一次页面,和服务端日志里记录的响应做对比。
  3. 在索引覆盖报告里看同类模板的收录比例,如果整批页面都停在“已发现但未编入索引”,往往指向同一类技术问题。
  4. 对比渲染后的页面和源 HTML,差异越大,风险越高。

折中方案可以怎么做

不一定要把整个站改成 SSR,分层处理往往更现实:

  • 核心内容,包括标题、正文、主要链接,走服务端输出,交互部分保留 JS;
  • 给不常变化的页面做预渲染,或在边缘节点缓存一份渲染好的 HTML;
  • 列表页至少保证基础链接写在 HTML 里,前端翻页只作为增强;
  • 关键内容不要只依赖客户端路由,让每个页面有独立、可直接访问的 URL。

最后补一句:渲染做好只是让内容有机会被看到,能不能留下还要看内容本身是否值得。把技术上该补的补上,等于把原本该有的机会拿回来。