跳至正文
WordPress 与 WooCommerce · Google SEO

WordPress 主题用 JS 输出正文:抓取与收录要注意什么

// / / 光算科技

要回答这个问题,先把"看不到"和"没处理"分开:主题用 JavaScript 拼出正文,Google 并不会跳过这个页面,它会用浏览器内核把脚本跑一遍再看内容。真正会出问题的是另一件事——正文在初始 HTML 里缺席,链接靠脚本点击事件触发,这两处让抓取阶段拿不到它需要的东西。官方的表述是"内容不出现在渲染后的 HTML 里,Google 就无法索引它",而不是"JS 页面一律不处理"。 如果采用前后端分离,还需要按Headless WordPress 的抓取与链接检查验证最终输出。

正文在初始 HTML 与渲染后 HTML 两个阶段的分布对照,标出抓取阶段能读到的那一段在哪、渲染阶段才出现的那一段在哪
原创示意:图中为同一页在初始 HTML 与渲染后 HTML 两个阶段的正文与链接分布对照,不是真实后台截图或数据。

先确认你的主题属于哪一种输出方式

WordPress 主题开发手册把主题分成两类:区块主题主要由 HTML 和一个主题配置文件构成,文章内容本身就在页面里;经典主题是原始那种形态,主要用 PHP、JavaScript 和 CSS 拼出来。这意味着同一个 WordPress 站,不同主题的"正文在不在初始 HTML 里"可能完全不同,不能凭主题类型下结论,得逐页去看。

判断方法只有一步:打开文章的"查看源代码",搜正文里的一个独特短句。搜得到,说明服务端已经把正文吐出来了,问题基本不在抓取上;搜不到但页面显示正常,说明正文是脚本插进去的,接着要确认第二件事——站内链接是不是真的带 href。

官方把处理拆成了哪几步

Google 关于 JavaScript 搜索优化的说明把这件事写成三个阶段:抓取、渲染、索引。文档里有一段专门描述所谓的"应用外壳模型"——初始 HTML 不含实际内容,Google 必须先执行 JavaScript 才能看到页面真正显示的东西。文档同时写明,返回 200 状态码的页面都会被放进渲染队列,这个页面"在队列里可能停留几秒,也可能更久"。

这里有两句要分清。一是"可能更久"不等于有某个等待上限——官方从未公布"渲染超过几秒就放弃"的阈值,网上流传的各种秒数都没有出处。二是文档同时建议继续做服务端渲染或预渲染,理由写得很直白:对用户和对爬虫都更快,而且并非所有爬虫都能运行 JavaScript。这是对"只要 Google 能跑 JS 就够了"的一个明确保留。

怎么做:四步把正文搬回 HTML

  1. 列一份受影响页面清单。用查看源代码逐页确认,不要抽样。首页、文章页、分类页、静态页各看两三篇,通常就能看出这是全局行为还是某个模板的行为。
  2. 把正文从"脚本插入"改成"服务端输出"。经典主题里这通常意味着在模板文件中直接输出文章内容,而不是先放一个空容器再由脚本填充。
  3. 逐个检查站内链接。官方对链接的判定标准写得很窄:Google 一般只能抓取带 href 属性的 <a> 元素;靠脚本事件充当链接的写法无法被可靠解析。用 JavaScript 动态插入的链接可以,但必须用标准标记。
  4. 加长期缓存时给文件名加内容指纹。官方在两份文档里都提到 Googlebot 缓存激进、Web 渲染服务可能忽略缓存头,从而用到过期的 JavaScript 或 CSS;把内容指纹写进文件名可以避免这个问题,资源一改文件名就变。
查看源代码的结果页面上的链接形态先处理哪一项
正文能搜到链接带 href这一页暂时没有抓取侧问题,把精力放到内容与内链上
正文能搜到链接靠脚本事件先把链接改成带 href 的标准元素,成本最低
正文搜不到链接带 href把正文改成服务端输出,链接不用动
正文搜不到链接靠脚本事件两项都要改,先改链接,改完立刻复测再改正文

什么时候不适用这套判断

有几种情况这套判断基本用不上。一是站点本来就是一个应用形态,正文只在特定交互后出现,页面上没有可独立存在的静态内容——这时讨论"正文在不在 HTML 里"没有对象。二是正文确实在初始 HTML 里,问题出在别处,比如标题重复、地址规范或内链结构,那属于另一类排查。三是先动 JS 渲染之前,页面里已经有更基础的问题:HTTP 状态码不对、robots 规则挡住了抓取,官方明确写了抓取被禁时不会渲染被挡页面上的 JavaScript。

还有一个常见误判:把"我的页面在浏览器里正常"当成"抓取也正常"。浏览器会跑脚本、会有缓存、可能有权限授权,官方文档专门写过渲染服务每次加载都像普通浏览器一样跟进重定向,但不会保留状态:本地存储和会话存储会被清空,HTTP Cookie 同样会被清空。任何依赖"上次访问过"才显示的内容,在抓取侧就是空的。

怎么验证改完真的被看到了

改完之后别靠猜。Google 关于修复 JavaScript 抓取问题的文档给的是同一套工具:结构化数据测试工具和网址检查工具,可以直接看到加载了哪些资源、JavaScript 控制台输出和异常、以及渲染后的 DOM 长什么样。官方在这份文档里也建议顺带收集并审计 JavaScript 报错,因为它同样影响内容是怎么被渲染出来的。

具体到 WordPress 站,验证顺序建议是:先抽查三到五篇文章的渲染后 HTML,确认正文在、链接带 href;再用网址检查工具逐个看抓取状态;最后到WordPress 加速先选插件还是调服务器:缓存、CDN 与动态页面怎么分工里说的那样,把静态与动态的分工理清,避免改完输出又被缓存层盖回旧版本。同一页里链接放在什么位置还有差别,链接上下文为什么重要:同一页不同位置差别在哪讲的是这一层;主题层面为什么值得先花时间在这一层,WordPress 为什么便于做 SEO:5 项优势及使用条件里也拆过。