最快修法： Google 的 Article 富结果要求 author 是一个 Person 或 Organization 对象，对象里带一个 name 字符串。如果你的 JSON-LD 输出的是 "author": "Jane Lee"（裸字符串）或 { "@type": "Person", "name": null }，把它改成 { "@type": "Person", "name": "Jane Lee" }，然后在 Search Console 点 Validate Fix。验证过程通常要等最多两周，Google 会重新抓取。
Search Console 的 Article 富结果报告（在 Enhancements → Articles 下，也能从单个 URL 的 inspection 面板进入）开始在几篇文章上提示 Missing field "author" (name)。几天后变成 200 篇。一周后你的文章在 SERP 里丢了署名。让人沮丧的是：你确实有作者 —— 标题正下方就写着 “By Jane Lee”。打开 JSON-LD 一看就懂 Google 为什么不满意：author 字段要么是个裸字符串，要么是缺少内层 name 属性的对象。
有一个澄清能省掉很多困惑：根据 Google 的 Article 结构化数据文档（截至 2026 年 6 月），author 严格说是推荐属性，不是硬性必填，所以页面照样会被索引。但只要你提供了 author，Google 就要求它是带 name 的结构化 Person/Organization 对象。裸字符串会被当成格式错误，警告随之触发，署名增强项也被拿掉。所以”推荐”不等于”可以无视” —— 一个填了一半的 author 比干脆不填还糟。
你是哪一种情况
警告文案对好几种不同的 bug 都一模一样。先在这张表里找到你的 JSON-LD 形状，再跳到第 2 步对应的修法。
| 你的 JSON-LD 长啥样 | 根因 | 修法 |
|---|---|---|
"author": "Jane Lee" | 字符串，不是对象 | 包进 { "@type": "Person", "name": ... } |
{ "@type": "Person", "name": null } | 数据字段为空 | 回填 name 或整块省略 |
{ "givenName": "Jane", "familyName": "Lee" } | 拆了名却没 name | 补上合并的 name |
"author": ["Jane Lee", "Sam Park"] | 字符串数组 | 改成对象数组 |
author 嵌在 publisher/mainEntityOfPage 里 | 父级错了 | 移到 Article 根级 |
| 最近每篇都是同一个通用字符串 | CMS 迁移丢了数据 | 重新映射作者，编辑内容用 Organization |
常见原因
按生产模板里的命中频次排序。
1. author 是字符串，不是对象
模板写 "author": "Jane Lee"。Schema.org 在很多字段上接受字符串，但 Google 在 Article 富结果上明确要求 author 是 Person 或 Organization 对象。
怎么判断：view-source 看 JSON-LD。"author" 是带引号的字符串就是这个 bug。
2. 数据字段为空，author 变成 { "name": null }
CMS 的 author 字段有时为 null。生成器输出 { "@type": "Person", "name": null }。Google 把这解读为”字段存在但为空”。
怎么判断：一部分文章 author 对象合法，另一部分 name 位置是 null 或空字符串。
3. author 对象有 givenName / familyName 但没 name
生成器把姓名规整地拆分，却从不输出合并的 name 字段。Schema.org 允许拆分形式，但 Google 的 Article 富结果明确要 name。
怎么判断：JSON-LD 里有 "givenName": "Jane", "familyName": "Lee"，没有 "name"。
4. author 是字符串数组而不是对象数组
多作者文章输出 "author": ["Jane Lee", "Sam Park"]。数组形状对，每个元素也得是对象。
怎么判断：view-source 看合著文章，检查数组内容。
5. author 嵌错了父级
生成器把 author 塞进 publisher 或 mainEntityOfPage，而不是放在 Article 根级。
怎么判断：在 JSON-LD 里搜 "author"，确认它的父键是顶层 Article 对象。
6. CMS 迁移丢了结构化 author 数据
迁移之后新系统只存文本作者。schema 生成器 fallback 到团队 byline 或 “Editorial Team” 这样的字符串。
怎么判断：最近的文章都共享同一个通用 author 字符串；老文章作者各不相同。
开始前
- 从 Article 报告（Search Console → Enhancements → Articles）拉受影响 URL 列表：打开
Missing field "author" (name)这个 issue，导出它的示例。存档，清理进度要拿它来衡量。 - 找到输出 JSON-LD 的模板或生成器。
- 决定数据模型：你有真正的作者表，还是只有自由文本？
- 确认
author应该是Person（典型）还是Organization（编辑团队署名内容）。
需要收集的信息
- 5-10 个受影响页面的原始 HTML，重点看 JSON-LD 块。
- 构造
author的模板代码。 - CMS / 数据来源：结构化作者记录，还是自由文本字符串。
- 站点是否同时有 Article 和 BlogPosting 两种类型，还是只用一种。
- 典型作者的样本数据（单作者、合著、匿名编辑）。
一步步修
按代价从小到大。
第 1 步：用 Rich Results Test 确认形状
把任一受影响 URL 丢进 Google 的 Rich Results Test。检测结果面板会标出问题字段的路径（比如 author 被标 “Missing field ‘name’”）。这告诉你 bug 是哪种变体。如果 Rich Results Test 连 Article 项都识别不出来，那你的 JSON-LD 多半先有语法错误 —— 去看 Search Console 单独的 Unparsable structured data 报告。
要纯看 schema（不带 Google 资格判断），用 Schema Markup Validator，它会把每个属性按解析结果原样展开，null 或嵌错的 author 一眼就能看出。判断 Google 资格用 Rich Results Test，读原始结构树用 Schema Markup Validator。
第 2 步：修 schema 生成器
最小合法形态：
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "How to bake sourdough",
"datePublished": "2026-05-10",
"author": {
"@type": "Person",
"name": "Jane Lee"
}
}author.name 里只放名字本身。按 Google 2026 年 6 月的作者最佳实践，name 字段不能带敬称、职务或刊物名。写 "name": "Jane Lee"，别写 "name": "Dr. Jane Lee, Senior Editor at Acme"。要做消歧的链接放进 author.url。
模板代码：
function authorBlock(article) {
if (!article.author?.name) {
// No reliable author — omit the field entirely rather than fake it
return undefined;
}
return {
"@type": "Person",
"name": article.author.name,
...(article.author.url && { url: article.author.url }),
};
}
const jsonLd = {
"@context": "https://schema.org",
"@type": "Article",
"headline": article.title,
"datePublished": article.publishedAt,
...(authorBlock(article) && { author: authorBlock(article) }),
};第 3 步：合著文章按规矩来
每位作者一个独立对象：
"author": [
{ "@type": "Person", "name": "Jane Lee", "url": "https://example.com/team/jane" },
{ "@type": "Person", "name": "Sam Park", "url": "https://example.com/team/sam" }
]代码：
const authorArr = article.authors
.filter(a => a?.name)
.map(a => ({ "@type": "Person", "name": a.name, ...(a.url && { url: a.url }) }));
if (authorArr.length === 1) jsonLd.author = authorArr[0];
else if (authorArr.length > 1) jsonLd.author = authorArr;
// else: omit第 4 步：编辑团队署名走 Organization
没有具名个人的内容：
"author": {
"@type": "Organization",
"name": "Acme Editorial",
"url": "https://example.com/about/editorial"
}不要造一个假人。
第 5 步：在 CMS 里回填缺失的 author 数据
对受影响 URL：
# Find articles with missing author.name in JSON-LD
for url in $(cat affected.txt); do
curl -s "$url" | grep -q '"author":\s*"' && echo "STRING_AUTHOR: $url"
curl -s "$url" | grep -q '"name":\s*null' && echo "NULL_NAME: $url"
done逐个编辑，或者写一次性脚本设合理默认（老文章设真实作者；匿名设编辑 Org）。
第 6 步：CI 加必填 schema 字段断言
// scripts/validate-schema.mjs
import { parse } from 'node-html-parser';
for (const url of sampleUrls) {
const html = await fetch(url).then(r => r.text());
const root = parse(html);
const ld = root.querySelectorAll('script[type="application/ld+json"]');
for (const node of ld) {
const data = JSON.parse(node.text);
if (data['@type'] !== 'Article' && data['@type'] !== 'BlogPosting') continue;
if (typeof data.author === 'string') throw new Error(`String author: ${url}`);
if (!data.author?.name && !Array.isArray(data.author)) throw new Error(`Missing author.name: ${url}`);
}
}每次部署都跑。回退能在用户看到之前被发现。
第 7 步：点 Validate Fix，再确认重抓
修复部署后，在 Article 报告里打开 Missing field "author" (name) 这个 issue，点 Validate Fix。Google 会立刻抽查一批；如果通过，剩下的受影响 URL 会排队重抓，进度记在验证历史里。官方说法是验证可能要两周甚至更久，取决于你的抓取频率 —— 别因为着急反复点 Validate Fix，那会重置计时。
想让少数高价值页面快一点，把它们走一遍 URL Inspection → Request indexing。这个 issue 会一直处于 “open”，直到连续 90 天没有新实例，所以数字在零附近停留一阵是正常的。
如何确认修好了
- Rich Results Test 在 5 个修好的 URL 上识别出 Article 项，
author.name已填，且author字段零警告。 - Schema Markup Validator 显示
author是一个带非空name的Person（或Organization）节点，直接挂在 Article 下。 - Search Console 的 Article 报告里
Missing field "author" (name)数量在重抓后趋向 0，验证历史显示 “Passed”。 - 受影响 URL 的署名重新出现（注意：Google 在 2026 年一直在精简一些 Article 增强项，所以署名当作锦上添花，别当成保证 —— 真正的收益是去掉警告和资格阻断）。
- 第 6 步的 CI 断言每次 PR 都通过，新文章绝不会在缺少结构化
author对象的情况下上线。
长期预防
- 把 schema 字段当作内容合约的一部分：像必填表单字段一样校验。
- JSON-LD 生成器用 TypeScript 类型 —— 缺字段在编译期就失败。
- 在 repo README 或 schema-registry 文档里写清楚
author的标准形态。 - 确立规则：没有真实作者就用 Organization；绝不 fallback 到字符串。
- 每季度审一次 Search Console 增强警告，发现慢漂移。
常见坑
"author": ""（空字符串）比缺字段还糟。Google 标空值比标缺失更严重。- 给 author 用
@type: "Thing"。语法合法，但不是 Google Article 富结果期望的类型。 - 只在 microdata 或 RDFa 里写
author，JSON-LD 里没有。挑一种格式；Google 文档以 JSON-LD 为主。 - 加了
author.image或author.sameAs，却忘了author.name。一旦提供了author对象，name才是 Google 真正会检查的属性。 - 把作者的 URL 写成
https://x.com/handle当 name 用。url和name是不同字段，URL 永远替代不了 name。
FAQ
Q：author 到底是必填还是推荐？
截至 2026 年 6 月，Google 把 author 列为 Article 的推荐属性，不是硬性必填，所以没有它页面照样索引。但如果你提供了一个形状错误的 author（字符串或空 name），Search Console 就会报警，署名增强项被压制。这个警告说的是你已经加上的一个格式错误属性，而不是页面缺了什么必填项。要么修对形状，要么干净地省掉这个字段；别留一个填一半的。
Q：author 可以是指向作者页的 URL 而不是内联对象吗？
用一个内含 name 的内联 Person/Organization 对象，把页面链接放进 author.url。在 Google 期望对象的地方给一个裸 URL 满足不了 name。url 属性是用来消歧的，不是 name 的替代品。
Q：匿名社论能拿到 Article 富结果吗？
能，但 author 要是具名 Organization。“Editorial Team” 或刊物名都行。“Anonymous” 或空都不满足。
Q：author.name 要不要带作者的职务，比如 “Dr.” 或 “Senior Editor”？
不要。Google 的作者最佳实践说 name 只放名字本身 —— 不带敬称、职务或刊物名。写 "name": "Jane Lee"。想露职务就放在页面可见的 byline 里，别塞进 schema 的 name。
Q：作者用笔名怎么办？要不要露法律名？
按页面 byline 上写的来。Schema 必须镜像可见内容。byline 写 “J. Doe”，schema 的 name 就是 “J. Doe”。
Q：修完之后 SERP 上的署名会立刻回来吗？
不一定。署名还取决于更广的信任信号，而且 Google 在 2026 年一直在精简一些 Article 增强项。但清掉这个警告是前置条件 —— 没有合法的 author.name，署名根本不在候选里。