站点运营

站点运营:JavaScript 渲染与首屏内容自查,别把正文锁在脚本里

很多站点把正文和链接交给前端脚本生成,蜘蛛拿到的初始 HTML 可能是空壳。本文整理一套渲染自查流程:分别查看初始 HTML 与渲染后 HTML,核对正文、内链与分页入口是否依赖脚本,并给出服务端渲染、预渲染和降级兜底几种可选路径。

站点运营

站点运营:JavaScript 渲染与首屏内容自查,别把正文锁在脚本里

不少站点在浏览器里看起来完整,但服务器返回的第一份 HTML 里几乎什么都没有:正文、列表、分页链接都靠前端脚本在浏览器加载后拼出来。搜索蜘蛛抓取时看到的,往往就是这份初始 HTML。如果内容不在里面,蜘蛛就可能拿不到你想让它看到的东西。

这里说的不是「脚本一定不能被蜘蛛执行」。主流搜索引擎具备一定的渲染能力,但渲染需要额外排队和资源,存在延迟,也可能因为脚本报错、接口超时、权限配置而失败。把内容完全押在渲染结果上,等于把可控的事交给不确定的环节。

自查第一步:把两份 HTML 摆在一起看

  1. 取初始 HTML:用命令行工具或「查看网页源代码」,保存服务器直接返回的内容。不要用开发者工具里的 Elements 面板,那里已经被脚本改写过。
  2. 取渲染后 HTML:在浏览器里等页面完全加载,再把 DOM 结构导出,或者用支持渲染的抓取工具做对比。
  3. 逐项比对:正文主体、主要内链、导航、分页入口、面包屑、结构化信息,是否出现在初始 HTML 中。
  4. 记录差异清单:把「只在渲染后出现」的部分列出来,按重要性排序,优先处理正文和链接。

这些位置最容易漏

  • 列表页的后续条目和「下一页」按钮,常由脚本在滚动或点击后追加。
  • 标签切换、折叠面板里的内容,初始状态下并未插入 DOM。
  • 无限滚动加载的内容,初始 HTML 只有第一屏。
  • 评论区、相关推荐、参数表格等次要但仍有搜索价值的区块。
  • 站内链接写在脚本数组里,初始 HTML 里一个链接标签都看不到。

几种可选的处理路径

服务端渲染

让服务器直接输出带内容的 HTML,前端框架大多有对应方案。改造成本不小,但对内容型页面回报比较直接。

预渲染

在构建或发布阶段把页面渲染成静态 HTML,适合更新频率不高的栏目页和详情页。注意内容更新后要重新生成,否则会出现新旧不一致。

降级与兜底

至少在初始 HTML 里保留正文摘要、主要链接和分页入口,让蜘蛛和关闭脚本的用户都能顺着读下去。这通常是成本最低的一步。

排查时的几个注意点

  • 不要只看首页和几篇文章,列表页、分页、筛选页往往是问题重灾区。
  • 接口返回的数据如果对未登录用户也可见,尽量让它在服务端先注入。
  • 懒加载的图片和内容,确认有可访问的地址或明确的入口,而不是一片空白。
  • 渲染耗时过长会拖慢抓取节奏,必要时评估首屏渲染时间和接口响应时间。
渲染方式只是把内容交付出去的手段,不是排名手段。内容本身有价值、地址稳定、入口清晰,才谈得上后续的抓取和索引。

建议把这项检查放进改版和上线的流程里:新模板、新组件、新接口上线前,先看一眼初始 HTML 里到底有什么。这个动作只要几分钟,却能避免内容长期躺在脚本里没人看见。