Schema.org parentOrganization
实战教程
parentOrganization 是 Schema.org 中声明组织从属关系的核心字段， 也是 ASN 矩阵合法性的技术声明。本文提供完整代码示例 + 实施步骤 + 验证工具 + 常见错误避坑指南，让你彻底掌握如何用 Schema 公开告诉 Google 「这是我的品牌矩阵」。
① 为什么 parentOrganization 是 ASN 的关键?
Google 抓取网站时会建立实体图谱 (Entity Graph) — 评估每个域名属于哪个品牌、有什么关系、覆盖什么主题。
没有 parentOrganization 时：5 个 ASN 卫星站在 Google 眼中是 5 个独立陌生网站， 它们互相链接显得可疑（PBN 嫌疑）。
有 parentOrganization 时：5 个卫星 + 1 个核心被 Google 识别为同一品牌的多个子站点，互相链接是合理的内部品牌关系。这就是 ASN 与 PBN 的本质技术分界。
想了解 ASN 与 PBN 的完整对比，请阅读 ASN vs PBN：本质区别。
② 卫星站的 Schema 代码 (放到核心位置)
每个卫星站的 OrganizationSchema 应包含 parentOrganization 字段：
{
"@context": "https://schema.org",
"@type": ["Organization", "ProfessionalService"],
"@id": "https://satellite-site-1.com/#organization",
"name": "卫星站 1 品牌名",
"url": "https://satellite-site-1.com",
"logo": "https://satellite-site-1.com/logo.png",
"description": "卫星站 1 主题描述",
"parentOrganization": {
"@id": "https://hub-site.com/#organization",
"@type": "Organization",
"name": "核心站品牌名",
"url": "https://hub-site.com"
}
}放在每页 <head> 中作为 <script type="application/ld+json">。
③ 核心站的 Schema 代码 (反向声明)
核心站反向声明所有卫星，使用 subOrganization 数组：
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://hub-site.com/#organization",
"name": "核心品牌名",
"url": "https://hub-site.com",
"logo": "https://hub-site.com/logo.png",
"description": "核心品牌主张描述",
"founder": {
"@type": "Person",
"name": "主理人姓名",
"jobTitle": "Senior Consultant"
},
"foundingDate": "2026",
"areaServed": ["ID", "VN", "TH", "MY", "SG", "US"],
"knowsAbout": [
"主题领域 1",
"主题领域 2"
],
"subOrganization": [
{ "@id": "https://satellite-site-1.com/#organization" },
{ "@id": "https://satellite-site-2.com/#organization" },
{ "@id": "https://satellite-site-3.com/#organization" },
{ "@id": "https://satellite-site-4.com/#organization" },
{ "@id": "https://satellite-site-5.com/#organization" }
]
}关键：核心和卫星站之间通过 @id 互相引用，形成双向声明。 这样 Google 解析任何一个站点都能追溯到完整品牌生态。
④ 进阶字段：增强 E-E-A-T 信号
核心站的 Organization Schema 应包含更多字段以最大化 E-E-A-T 评估：
- founder: 主理人/创始人 + Person Schema (Expertise 信号)
- foundingDate: 创立日期 (Trust 信号 - 时间维度)
- areaServed: 服务地区数组 (覆盖范围声明)
- knowsAbout: 专业主题数组 (Topical Authority 显式声明)
- contactPoint: 客服联系点 (Trust 信号)
- sameAs: 社交媒体链接数组 (Verified Entity 信号)
- aggregateRating: 综合评分 (仅当有真实可验证评价时)
Linkup 在 OrganizationSchema 组件中实施了全部以上字段。代码参考已开源在GitHub xcynux1/asnbuilder。
⑤ 验证工具
部署后必须验证 Schema 正确性，避免静默错误：
- Google Rich Results Test:search.google.com/test/rich-results
验证页面是否符合富媒体片段格式 - Schema.org Validator:validator.schema.org
验证 JSON-LD 语法正确性 - Google Search Console: `Enhancements` 区域显示 Schema 类型与错误
重要：每次部署后等 7-14 天再看 GSC 数据 - curl + grep:
curl -s 'https://your-site.com/' | grep -oE '"@type":"[^"]*"'
快速 CLI 验证页面包含哪些 Schema 类型
⑥ 常见错误避坑
错误 1：parentOrganization 用了 URL 而非 @id
// ❌ 错误
"parentOrganization": "https://hub-site.com"
// ✅ 正确
"parentOrganization": {
"@id": "https://hub-site.com/#organization",
"@type": "Organization",
"name": "Hub Name",
"url": "https://hub-site.com"
}错误 2：核心站没有反向声明 subOrganization
必须双向声明。只有卫星声明 parentOrganization、核心没声明 subOrganization， Google 会认为关系不完整。
错误 3：所有站点用同一个 @id
每个站点的 @id 必须不同，通常是 https://{site}/#organization。 重复 @id 会让 Google 困惑哪个是真正实体。
错误 4：忘记 inLanguage 字段
非英语站点必须声明 "inLanguage": "zh-CN" 或 "id-ID" 等， Google 才能正确分配到对应语言市场的实体图谱。
错误 5：Schema 在 React SPA 中没被 Puppeteer 预渲染
React 应用默认 Schema 在客户端注入。Googlebot 虽然能执行 JS 但优先索引初始 HTML。 必须用 Puppeteer (或类似工具) 预渲染，确保 Schema 在首次 HTML 响应中已包含。 Linkup 使用 Puppeteer 预渲染所有 7 个路由。
⑦ 实例：Linkup·链 自己的 Schema 配置
Linkup·链 自身就是 ASN 方法论的产品（一个 Pillar 域名）。我们的 Schema 包含：
- Organization + ProfessionalService 混合 @type
- founder: Lilly (Senior SEO Consultant, Guangdong/Shenzhen)
- foundingDate: 2026
- areaServed: CN, ID, VN, MY, TH, PH, SG, US, GB, AU
- knowsAbout: 10 个主题领域声明 (ASN, Topical Authority, 等)
- WebSite Schema 双重声明，用 publisher 引用 Organization
- 每个 /case/ 页面 Article + BreadcrumbList
- 每个 /fangfa/ 页面 Article/TechArticle + BreadcrumbList + FAQPage
可以查看 源码 (OrganizationSchema.tsx) 了解完整实现。