独立站要不要挂 article schema:Google 只读五个属性

独立站的文章页要不要挂 article schema:要挂,但它换不来一个新的展示位。Google 官方只列了五个支持的属性,一个必填的都没有——这篇把每个属性该怎么写、缺了会怎样、以及它做不到什么,逐条对着原文说清楚。

抓取与收录8 分钟读完2396 次阅读
独立站要不要挂 article schema:Google 只读五个属性

独立站的文章页要不要挂 article schema?要挂,但别指望它换来一个新的展示位。Google 官方文档只列了五个它支持的属性,而且一个必填的都没有——这段标记的作用,是把作者、日期、标题、配图用机器不用猜的方式说清楚,不是让搜索结果里多出一块东西。想清楚这一点再动手,剩下的活半小时就能干完。

挂 article schema 换来的是什么

出处是Google 的 Article 结构化数据文档(2026-09-01 抓取,页脚标的最后更新时间是 2025-12-10)。它在开头第一句就把收益写完了:加上这段标记「can help Google understand more about the web page and show better title text, images, and date information for the article in search results on Google Search and other properties」。更准的标题文字、更合适的配图、更准的日期。没有新的框。

紧跟着的那句更要紧,它把多数人加这段标记的理由拿掉了:「While there's no markup requirement to be eligible for Google News features like Top stories, you can add Article to more explicitly tell Google what your content is about.」进 Top stories 不需要这段标记。Google 的结构化数据特性库(同日抓取)里 Article 确实还列着,描述是「a news, sports, or blog article displayed in various rich result features, such as the title of the article and larger-than-thumbnail images」,分类标签写的是 News 和 Sports——这个特性当初是给谁做的,标签已经说了。

没有必填项,不等于随便写。它真正的意思是:你漏了什么,不会有任何工具提醒你。

一周发两三篇博客的出海独立站,不在那个人群里。这段标记仍然值得挂,理由是文档真正支持的那一个:它把作者、日期和规范标题用一种不需要猜的格式说出来。至于给搜索结果加一块可见的东西,它做不到。

为什么 Google 的清单比 schema.org 短这么多

这里有两套词汇表在同一个页面上碰头,体量完全不是一个量级。schema.org 的 Article 类型定义(2026-09-01 抓取)把它写成「an article, such as a news article or piece of investigative report」,层级是 Thing › CreativeWork › Article,自己定义的属性只有八个:articleBody、articleSection、backstory、pageEnd、pageStart、pagination、speakable、wordCount。从 CreativeWork 和 Thing 继承下来的还有一百多个。同一页把部署量标成「10M+ Domains」,脚注写明数据来自 Google 网页索引的月度聚合,日期是 2026 年 7 月。

Google 点名的那五个

官方页面上「The Google-supported properties are the following」这句底下,只有一个子标题:Recommended properties。没有第二个子标题。条目是 author(另外拆出 author.name 和 author.url)、dateModified、datePublished、headline、image。管着这五个的那句话,全页出现了两次:「There are no required properties; instead, add the properties that apply to your content.」

一百多个和五个之间的这个落差,就是这个话题全部的实操内容。生成器和插件会往每篇文章里塞 articleBody、wordCount、articleSection、mainEntityOfPage 和 publisher,因为词汇表允许它们这么干。publisher 这个尤其值得知道:它在 Google 那一页上只出现在 author 最佳实践一节里,用途是「本来会被塞进 author.name 的出版方名字,应该改放这里」。它不在支持清单上。

动手:七步

第一个模板留半小时,之后每种模板五分钟左右。

  1. 先查你的站现在输出了什么。看页面源码,搜 ld+json,确认有没有已经存在的 Article 或 BlogPosting。WordPress 的 SEO 插件、Shopify 的博客主题、大部分 Next.js 脚手架都默认输出一段,你手写的那段不会替换它,只会挨着它一起挂着。做完的标志:你能说清楚接下来是新写一段,还是改已有的那一段。
  2. 选类型。官方原话:「Article objects must be based on one of the following schema.org types: Article, NewsArticle, BlogPosting.」博客文章用 BlogPosting,带日期的新闻稿用 NewsArticle,两个都不贴切才用 Article。做完的标志:这个选择是按模板定下来的,不是按每篇文章现定。
  3. headline 从渲染可见标题的同一个字段取。Google 建议标题写短,「as long titles may be truncated on some devices」。做完的标志:两个字符串一字不差——分两处各自拼装的模板,一个月内必然对不上。
  4. datePublished 和 dateModified 用 ISO 8601 写,带时区偏移。官方原话:「We recommend that you provide timezone information; otherwise, we will default to the timezone used by Googlebot.」做完的标志:两个值结尾都带 +08:00 这样的偏移,而且你真去改一篇旧文时 dateModified 会跟着动。
  5. author 写成数组,一人一个对象,每个带 @type、name、url。官方原话:「When specifying multiple authors, list each author in their own author field」,以及「Use the Person type for people, and the Organization type for organizations. Don't use the Thing type」。做完的标志:author.name 里只剩一个名字——职位、敬称、出版方名字、「posted by」这类引导词,官方逐条点名不许放。
  6. image 指向这篇文章自己的图,不是站点 logo。官方措辞是「Use images that are relevant to the article, rather than logos or captions」,并建议给「multiple high-resolution images (minimum of 50K pixels when multiplying width and height) with the following aspect ratios: 16x9, 4x3, and 1x1」。做完的标志:退出登录状态下每个图片地址都打得开。
  7. 用富媒体搜索结果测试工具验证,再上线几个页面、用网址检查工具读一遍,这是官方给的顺序。同一页还要求确认这个网址没被 robots.txt、noindex 标签或登录墙挡住。做完的标志:这段标记解析通过,没有 critical error。

交付物:两段 JSON-LD 和一张属性判读表

先是最小可用的那段。里面没有任何一项是 Google 要求的,它只是「还能说出 HTML 本身没明说的东西」的最小版本。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "我们怎么把 Shopify 主题的首字节时间压下来",
  "image": ["https://example.com/photos/16x9/photo.jpg"],
  "datePublished": "2026-09-01T09:00:00+08:00"
}
</script>

完整版多了两个最容易写错的属性:author 写成带类型的对象数组、每人一个主页地址;dateModified 接在真实的修改动作上,而不是手打上去的。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "我们怎么把 Shopify 主题的首字节时间压下来",
  "image": [
    "https://example.com/photos/1x1/photo.jpg",
    "https://example.com/photos/4x3/photo.jpg",
    "https://example.com/photos/16x9/photo.jpg"
  ],
  "datePublished": "2026-09-01T09:00:00+08:00",
  "dateModified": "2026-09-01T14:30:00+08:00",
  "author": [{
    "@type": "Person",
    "name": "Mei Chen",
    "url": "https://example.com/about/mei-chen"
  }]
}
</script>

下面这张表按分诊看,不是照着填满的清单。第三列写的是官方文档对「缺了会怎样」说了什么,多数行它什么都没说——没说本身就是答案。

属性官方分档缺了会怎样
headline推荐官方没说后果
image推荐官方没说后果
datePublished推荐测试工具不报警告
dateModified推荐测试工具不报警告
author推荐官方没说后果
author.name推荐官方没说后果
author.url推荐可用 sameAs 顶替
publisher不在支持清单官方没说
articleBody只在 schema.org官方没说
wordCount只在 schema.org官方没说
articleSection只在 schema.org官方没说
speakable只在 schema.org官方没说

有两行要补一句。日期那两行的「测试工具不报警告」是官方自己的说法:Rich Results Test「doesn't show a warning for this property, as it's only recommended if you decide that it's applicable to your site」。author.url 则有一个文档给的替代品:「You can use the sameAs property as an alternative.」

三种常见的做坏

article schema 写坏的这三种,在测试工具里都不报错,所以能在站上活很多年。

  1. dateModified 要么永远不动,要么每次部署都动。两种错法形状一样:这个字段声称描述的是一次内容修改,实际描述的是一次构建。把它接到内容自己的更新时间上,或者干脆不写——官方给它的定位就是「if you decide that it's applicable to your site」。
  2. 几个作者被合成一个字符串。官方把反例原样贴了出来,一个 author 对象的 name 写成「Willow Lane, Regula Felix」,改法是数组、一人一个对象。同一节还禁止往名字里塞职位和敬称,这两样各有各的属性。
  3. 插件把 Article 挂到了根本不是文章的页面上:分类页、标签归档、首页。schema.org 给这个类型的定义是「an article, such as a news article or piece of investigative report」,而一页分页的标题列表不是文章。第一步那个源码检查,防的就是这一种。

这一篇管不到的地方

三处边界,直说。这段标记不会让页面排得更前,官方文档把它写在「帮助理解」和「外观」下面,从没写成排名输入。它也不保证展示,同一页 troubleshooting 一节的原话是「Google does not guarantee that features that consume structured data will show up in search results」。以及最实在的一条:对一个不发新闻也不发体育的站,我们指不出搜索结果里有哪一个可见元素,是只因为挂了这段标记才出现的——文档没点名,我们也没做过能把它单独隔离出来的测试。

AI 引擎读不读它,我们不知道

Google 那一页讲的是 Google 搜索,schema.org 是一份词汇表规范,两边都没提 AI 爬虫拿到一段 BlogPosting 会怎么处理。今天真正能验证的是这些爬虫到底取不取得到这个页面,这件事可以用 AI 爬虫可达性自查 直接看,而且它更该先修。

还有一条技术准则离属性表很远,容易漏。系列长文分页时,Google 要求「the rel=canonical points at either each individual page or a "view-all" page (and not to page 1 of a multi-part series)」。你的专题模板要是分页的,这一条比属性表上任何一行都重要。

更上层的那个判断——现在还值得挂哪几种结构化数据类型——写在 结构化数据还剩哪几种有用 里。描述「这一页在站里的位置」而不是「这一页写的是什么」的那个兄弟类型,看 面包屑导航怎么标

常见问题

article schema 到底是什么?

一段 JSON-LD,把页面标成一篇文章,并用一套固定词汇说出它的标题、配图、日期和作者。Google 认三种 schema.org 类型——Article、NewsArticle、BlogPosting——并从里面读五个属性。

独立站不挂 article schema 会怎样?

不会怎样。官方在自己那一页上说了两次「没有必填属性」,Top stories 的资格也不需要任何标记。把它当成把页面事实说准的一种方式,不是页面能排名之前必须打的一个钩。

在线生成器出的那段能直接用吗?

第一段可以,之后就是负担。生成器给的是一段写死的片段,而 dateModified 和 author 必须从你自己的数据里来。生成一段,对着上面那张表读一遍,再把值搬进模板。

Article、NewsArticle、BlogPosting 该选哪个?

博客文章选 BlogPosting,带日期的新闻报道选 NewsArticle,两个描述都不贴切时才选 Article。官方对三种一视同仁,也没给过任何「哪种更利于排名」的说法,按内容的真实体裁选就行。

WordPress 装了 SEO 插件还用自己写吗?

多数情况下不用重写,要做的是核对。插件通常已经输出了一段 BlogPosting,你再加一段的结果是两段并存、还可能互相矛盾。先看源码,再决定改哪一段。

怎么验证自己站上那段写对了?

先对网址跑富媒体搜索结果测试工具,再对已上线的页面跑网址检查工具,这是官方给的顺序。前者告诉你这段能解析,后者告诉你 Google 到底够不够得着这个页面——前者不管这件事。

本文属于 QueryWin 实操手册 · 第 2 阶

独立站要不要挂 article schema:Google 只读五个属性