author schema：出海站的这篇文章，到底是谁写的
author schema 是把一篇内容挂到一个具体人名下的那个属性。这里有可以直接粘的 JSON-LD、名字必须一字不差的七个地方，以及它换不来的东西。
出海独立站的文章署名，常见的只有三种写法：空着、写公司名、写 admin。这三种在机器眼里是同一种——这一页没有作者。author schema 就是把一篇内容挂到一个具体人名下的那个属性：一个 Person 对象、一个名字、一个能查到这个人的页面地址。半小时能做完。它不换排名，也不是谁被引用的原因。
读这篇前
这一章只讲一个属性，以及它背后那个「人」的实体。机构层面的同一件事——让引擎把公司说对——在品牌实体怎么被说对那篇。那篇管的是公司，这篇管的是人。两者用的类型不同，落地清单也不重合，不是一套活儿拆成两半。
两个词先分清，本篇从头到尾不混用：被提及，是你的名字出现在一段答案里；被引用，是你的页面被当作来源交出去。第二件事靠什么，在什么样的内容会被 AI 引用那篇，靠的不是标记。
author schema 解决的不是排版，是身份
署名在页面上是一个排版决定。它排在标题下面，看起来像归属，但对解析器来说它只是一串字符，位置跟全世界每一篇文章放署名的位置一样。结构化数据改变的是这串字符的种类：它不再是页面上的一段文字，而是一个有类型的值——一个 Person。schema.org 给这个类型的定义是 A person (alive, dead, undead, or fictional).（一个人：活着的、死了的、不死的，或者虚构的。）它通过 author 属性挂在这篇内容上。
schema.org 对 author 的定义是 The author of this content or rating.，并且只接受两种类型：Organization 或 Person。没有第三个选项。这个限制本身就是重点——它逼你表态，这篇东西到底是一个人写的，还是一家公司发的。多数出海站两个都不选，而两个都不选不是中间态，是空缺。
真正起作用的是那个网址。Google 对 author.url 的说法是 A link to a web page that uniquely identifies the author of the article. For example, the author's social media page, an "about me" page, or a bio page.（一个能唯一识别出本文作者的网页链接，例如作者的社交媒体页、about me 页，或者个人简介页。）承重的词是 uniquely。同一页还写着 Google can understand both sameAs and url when disambiguating authors.——消歧（disambiguating）是 Google 自己用的动词，它告诉你这个属性是拿来干什么的。2026-09-01 读自 Google 的 Article 结构化数据文档；两个类型定义同日读自 schema.org/Person 与 schema.org/author。
机器认不出一个作者。它只能比对一串字符——而它信的那一串，是你指给它的每一个地方都原样返回的那一串。
文档原文，八条
下面八条全部出自上面那两个页面，2026-09-01 读的。右列是原文照抄，左列是我们给它起的名字。
| 规则 | 原文 |
|---|---|
| 只放名字 | "In the author.name property, only specify the name of the author. Don't add any other piece of information." |
| 公司名另有去处 | "The name of the publisher. Instead, use the publisher property." |
| 职位另有去处 | "The author's job title. Instead, use the appropriate property if you want to specify that information (jobTitle)." |
| 不带头衔前缀 | 敬称要放 honorificPrefix 或 honorificSuffix；"posted by" 这类引导词被列为不许加的东西。 |
| 一人一个字段 | "When specifying multiple authors, list each author in their own author field." |
| 不许合并作者 | "Don't merge multiple authors in the same author field" —— 它给的反例是 "name": "Willow Lane, Regula Felix"。 |
| 类型别用错 | "Use the Person type for people, and the Organization type for organizations. Don't use the Thing type." |
| 补上类型和网址 | "To help Google better understand who the author is, we strongly recommend using the type and url (or sameAs) properties." |
同一页还有一条，它决定了合著文章怎么处理：Make sure that all the authors that are presented as authors on the web page are also included in markup.（页面上以作者身份出现的每一个人，都要同时写进标记里。）页面上看得见的名字就得进标记。这是一条对齐要求，也是 Google 原文里唯一把渲染出来的页面和 JSON-LD 绑在一起的地方。
🔴 出海站特有的两个坑
下面这两个不在 Google 文档里，是中国团队做英文站时反复踩的。
第一个是一个人四套名字。你在自己站上署 Chen Yuan，LinkedIn 的显示名是 Yuan Chen，GitHub 是 cyuan，中文物料里写「陈远」。四个字符串，在机器手里就是四个候选人。拼音的空格和大小写也算数：Chen Yuan、ChenYuan、Chen-Yuan 是三个串，不是一个。做法是对外定死一种写法，其余能改的全部改过来；平台不让改显示名的，那一条干脆别放进 sameAs——放进去等于自己安排了一次核对失败。
第二个是署名写 admin、editor、小编，或者干脆写公司名。这不违规，Google 也不会因此罚你。它的代价是：你交出去的这个实体，名字叫 admin，而世界上还有几十万个 admin，谁的履历都不会攒到你头上。
动手做：五步
每一步都配一个能跑的检查。检查不过，这一步就没做完，不管代码看起来多完整。
- 给这个人挑一个字符串当名字，写进一个文件里。整章就这一个决定，后面全是复制它。完成标志：你手上有一行以后不会再改的文字。
- 把
author.url要指向的那一页做出来——个人简介页、about me 页，或者这个人自己能登录的平台资料页。完成标志：curl拿回 200，而且名字在交付的 HTML 里，不是加载后由脚本注入的。 - 在文章的 JSON-LD 里加上
author数组，带@type、name、url。完成标志：Google 富媒体结果测试按 Article 解析这一页，零报错。 - 只为这个人能登录的资料页加
sameAs。完成标志：每个网址在不登录的情况下请求都返回 200，且上面的显示名与你定的那一串一字不差。 - 最后改页面上看得见的署名，因为它是唯一会被人看出来不对的那一处。完成标志：同一串字符在交付的 HTML 里出现两次，一次在署名，一次在标记里。
第四步最费时间，也是最常被跳过的一步。一个你登录不进去的资料页，意味着它的显示名可以在你不知情的时候被改掉。
交付物：可以直接粘的那一段
放进文章页的 <head>。所有值换成你自己的。第四步里匿名请求没取回来的那条 sameAs，删掉。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "How we cut our lead time to nine days",
"datePublished": "2026-09-01T09:00:00+08:00",
"dateModified": "2026-09-01T09:00:00+08:00",
"author": [
{
"@type": "Person",
"name": "Chen Yuan",
"jobTitle": "Production manager",
"url": "https://www.novaoptics.com/about/chen-yuan",
"sameAs": [
"https://www.linkedin.com/in/chenyuan",
"https://github.com/chenyuan"
]
}
],
"publisher": {
"@type": "Organization",
"name": "Nova Optics",
"url": "https://www.novaoptics.com"
}
}
</script>两个作者就是数组里两个对象，各有各的 name 和 url。公司名一次都不出现在 author 里，它只出现在 publisher。两处填了同一个字符串的站，等于告诉解析器：有一家公司是个人。
交付物：名字必须一字不差的七个地方
这张表按人过一遍，不是按文章过。每一行都是机器自己就能走到的地方，这也正是不一致要付代价的原因。
| 在哪 | 为什么 |
|---|---|
| 页面上的署名 | Google 要求页面上以作者身份出现的人都要进标记，所以这两串是任何解析器最先比对的一对。 |
author.name | 这是实体拿到的标签。这个对象里没有别的字段在叫这个人，这里打错字，实体的名字就是那个错字。 |
作者页的 h1 | author.url 指过去的那一页得看得出说的是同一个人，而 h1 是那页上最强的名字信号。 |
作者页的 title | 它是搜索结果里会显示的那一部分，写法不同就会被收录成另一个名字相近的人。 |
| 作者页自己的标记 | 文章里声明一串、资料页上声明另一串，等于发布了两个互相链接的人。 |
| 每个 sameAs 显示名 | 每一条都是你主动安排的一次核对。显示名不一样，这次核对就从印证变成打脸。 |
| 旧文章的署名 | 一个归档里存在两种写法，就是把一个作者劈成两半，而两半谁也继承不了对方的履历。 |
最后一行是悄悄毁掉前六行的那一行。一个人前两年署「C. Yuan」、改版之后署「Chen Yuan」，机器手里就是两个候选人，这个月的新文章标记写得再对，也合并不回去。
三种常见的写错
这三种都能通过代码评审。其中两种看着还像更用心，所以它们活得很久。
- 把公司名填进
author.name。Google 在「不许加的东西」里第一条列的就是发布方名称，并且给了publisher这个属性专门放它。怎么发现：把两个值放一起看，author.name和publisher.name是同一串，就是它。这是合法标记，对不少站也是事实陈述，代价只是没有任何一个人可以让履历攒起来。 - 两个人塞进一个字段。原文很直接——"Don't merge multiple authors in the same
authorfield"——反例就是一个name里用逗号连着两个人名。怎么发现：在自己的输出里搜author.name中有没有逗号、顿号、& 或者 and。结果是造出一个实体，而它的名字没有任何人在用。 - 名字字段里除了名字什么都有。职位、敬称、"posted by"、部门。前两类 Google 各给了一个属性，第三类直接判为不许加。怎么发现：把
author.name念出来，如果它印在护照上会显得不对，就一直删到对为止。
还有第四种，我们把它标成「我们的读法」而不是规则：author.url 指向一个只列这个人历史文章的归档页，页面上没有一句介绍。Google 给的三个可接受例子是社交媒体页、about me 页、个人简介页，一串翻页的标题列表不属于这三种里的任何一种。这是我们对原文的读法，Google 没有明说不行。
这一章到哪儿为止
Google 自己给 Article 结构化数据划的效果范围很窄：它 can help Google understand more about the web page and show better title text, images, and date information for the article in search results（帮 Google 更了解这个网页，并在搜索结果里给出更好的标题文字、图片和日期信息）。作者不在这份外观清单里。同一批文档还写着 Google does not guarantee that features that consume structured data will show up in search results.（Google 不保证消费结构化数据的那些功能一定会出现在搜索结果里。）两句都是 2026-09-01 读的。
AI 引擎拿 author schema 做什么，我们不知道。没有一家公开过自己解析不解析这个属性，也没有一家说过读到一个 Person 之后会改变什么。这里没有数字，谁给你一个数字，谁就是在猜。在这件事还没有公开说明之前，我们不会把一个没测出来的效果写成收益。
所以这一章的诚实范围很小：它不会让你被引用，也不会让你被提及，这是两件不同的事，标记哪一件都换不来。它消除的是一种具体的失败——一篇内容，机器挂不到任何人身上。消除这个失败在下游值多少钱，是没有人公布过的那一部分，包括我们。
半年后加一次 CMS 迁移，这七串字符还对不对得上，是 QueryWin 正在做的事。
常见问题
author schema 对排名有用吗
Google 没有在任何文档里这么说过。Article 那一页把效果描述成更好的标题文字、图片和日期信息，作者不在其中。把它当身份管道，不要当排名杠杆。
署名写公司名可以吗
可以。author 本来就接受 Organization，Google 也给了一个指向公司主页的例子。结果是这篇内容由一家公司署名，背后没有人。这是一个正当选择，只是和这一章想做的事不是同一件。
author 和 publisher 有什么区别
作者是写的人，发布方是发的人。Google 自己的示例把两者放在同一块里分开写——author 里是 Person 对象，publisher 里是一个 Organization——并且明说要把公司名从 author.name 里挪走。
用英文名或者笔名行不行
行，条件是这个名字在别处也这么写。机器比的是字符串一致性，不是身份证。真正塌掉的情况是同一个人在站上用英文名、在 LinkedIn 用拼音、在 sameAs 里又指向第三种写法。
加了之后 AI 会更愿意引用我吗
不知道，我们宁可这么说，也不去把这个空填上。没有任何引擎公布过它怎么处理这个属性。被说准和被当成来源，是两个问题，只有前一个能靠标记做掉一部分。
本文属于 QueryWin 实操手册 · 第 2 阶
