Organization Schema：sameAs怎么写

Organization Schema（组织结构化数据）是一段放在网页中的代码，用来向搜索系统说明：这家组织叫什么、官网是哪一个、使用什么标志、地址在哪里，以及它在其他网站上有哪些可以核验的身份页面。

很多网站已经添加了这段代码，做法却只是复制模板，再替换公司名称和官网地址。代码看起来完整，实际信息可能并不准确，常见问题包括：

代码中的组织信息与页面正文不一致；
sameAs 填入了不能证明组织身份的链接；
同一家公司在不同页面使用了不同的名称、标志、地址或外部账号。

sameAs 是 Organization Schema 中的一个属性，用来填写能够明确识别同一组织的外部页面。这里的 URL，指可以直接访问的网页地址。sameAs 不是友情链接，也不是所有提到过这家公司的网页。

准确的 Organization Schema 可以帮助搜索系统理解组织信息、区分同名主体，也可能影响组织标志等搜索展示元素。但它不能保证网站一定获得特定展示，也不能保证内容一定被 AI（人工智能）系统引用。

这段代码是否有用，主要取决于信息是否真实、统一，并且能够持续维护，而不是填写了多少字段。

添加之前，先确认6条规则

1. 放在真正介绍组织的页面

Google 建议将 Organization 结构化数据放在网站首页，或者“关于我们”这类专门介绍组织的页面，不需要在每个页面重复添加。

如果网站系统会自动在所有页面输出这段代码，应确保每个页面使用的组织名称、标志、网址和固定标识完全一致。

2. 不需要填满所有字段

Google 的 Organization 指南没有规定必须填写哪些属性。网站只应填写真实、适用，并且能够持续维护的信息。

字段少但准确，比字段多却包含失效链接或虚假信息更合适。没有公开地址、税号、员工数或对外联系方式时，可以不填，不能为了让代码显得完整而编造。

3. 选择与组织匹配的类型

@type 用来说明当前数据描述的是哪类主体。不是所有网站都应该使用最宽泛的 Organization。

电商网站可以考虑 OnlineStore，也就是网上商店类型；实体门店则应结合 LocalBusiness，也就是本地经营场所类型，以及对应的官方指南处理。

具体使用哪种类型，应根据组织的真实业务和页面内容决定。

4. 正确理解`sameAs`

Schema.org 是一套供网站描述人物、组织、商品等信息的通用结构化数据词汇。它将 sameAs 定义为能够明确表明当前项目身份的参考网页地址。

因此，sameAs 不能用来填写普通友情链接、关键词相关页面，或者只在正文中提到过该组织的文章。

5. 数量没有统一下限

sameAs 可以填写多个网址，但官方没有规定最低数量，也没有“必须填写8条”之类的要求。

只填写真正属于该组织，并且能够核验身份的页面。三条准确链接，比十条混有错误主体的链接更可靠。

6. 优先使用JSON-LD，并检查实际输出

JSON-LD 是一种用代码描述网页信息的结构化数据格式。Google 通常建议使用这种格式，因为它比较容易部署和维护。

代码写完后，要先检查语法；正式上线后，还要查看搜索引擎实际读取的网页中是否包含最新数据。不能只检查网站后台中的配置。

Organization Schema：sameAs怎么写

每个字段分别填写什么

字段	含义及填写方式	常见错误
`@context`	声明代码使用哪套结构化数据词汇，通常填写 `https://schema.org`	拼写错误或使用无效地址
`@type`	填写与实际组织最匹配的类型	门店和电商网站一律填写 `Organization`
`@id`	填写站内稳定、唯一的组织标识地址	每个页面生成不同的标识
`name`	填写网站和用户日常识别的组织名称	官网、代码和社交账号使用不同名称
`legalName`	填写与工商或注册信息一致的法定名称	把宣传口号写成法定名称
`alternateName`	填写真正使用的简称、英文名或历史别名	堆积关键词和产品名称
`url`	填写组织官方网站的固定标准网址	填写栏目页或临时活动页
`logo`	填写可以公开访问的正式 Logo，也就是组织标志图片	图片无法访问、需要登录或尺寸过小
`description`	填写能够由页面正文核验的组织介绍	加入页面中没有的荣誉、规模或业务
`foundingDate`	填写真实的成立日期	使用未经核验的日期
`address`	填写适用且真实的联系地址	与页面或营业信息中的地址冲突
`contactPoint`	填写用户目前可以正常使用的联系方式	电话、邮箱已经停用
`sameAs`	填写能够明确识别同一组织的外部页面	填写搜索结果、转载文章或他人页面

下面分别说明最容易出错的几组字段。

Organization Schema：sameAs怎么写

`name`、`legalName`和`alternateName`怎么区分

这三个字段不能分别写成三套互不相关的宣传词。

name：网站和用户日常使用的组织名称；
legalName：组织的正式注册名称；
alternateName：组织公开使用的简称、英文名或历史别名。

只有当日常名称与法定名称不同时，分别填写 name 和 legalName 才有实际意义。

填写前，可以先整理一份名称核验记录：

使用位置	示例	核验依据
`name`	示例科技	官网页头、站点名称
`legalName`	示例科技有限公司	注册文件、网站法律信息
`alternateName`	Example Tech	官网公开使用的英文名称

如果某个英文名只出现在代码中，网站页面和公开资料从未使用，就不适合直接写入 alternateName。

`@id`为什么要保持稳定

@id 是同一组织在结构化数据中的固定标识。它不是网页标题，也不要求用户打开后看到一个独立页面。

常见写法是在官网固定网址后添加一个不会随页面变化的片段：

"@id": "https://www.example.com/#organization"

如果网站中的 Article、WebSite 或 Product 等结构化数据需要引用这个组织，可以继续使用同一个 @id。这三个类型分别用于描述文章、网站和商品。

统一使用固定标识，可以避免每次引用发布者或品牌时，又生成一套不同的名称、标志和地址。

同一家公司应确定一个主要组织标识。集团、子品牌和门店如果确实属于不同主体，就要根据真实关系分别设置，不能全部指向同一个 @id。

`sameAs`应该放哪些链接

判断一个链接能不能写进 sameAs，不在于平台是否知名，而在于页面能否明确证明它对应同一个组织。

可以考虑以下几类页面：

由组织自己维护，并且公开展示组织身份的官方社交账号；
能够明确对应这家组织的行业平台或评价平台资料页；
符合平台规则并且真实存在的 Wikipedia 或 Wikidata 条目；
由权威注册系统或标识系统提供的组织身份页面。

Wikipedia 是公开协作的网络百科全书；Wikidata 是用于记录人物、组织、地点等信息的结构化知识库。

以下链接不适合写入 sameAs：

搜索结果页、话题页和标签页；
只提到公司一次的新闻或博客文章；
经销商、创始人个人或合作伙伴的页面；
尚未创建、无法打开或跳转到其他主体的资料页；
为凑数量临时注册、没有组织信息的空账号。

如果组织没有 Wikipedia 或 Wikidata 页面，直接不填即可。不要保留模板中的示例地址，也不能使用不属于自己的 QID。QID 是 Wikidata 分配给每个条目的编号。

Logo、地址和联系方式怎么处理

Google 建议 Logo 图片至少为112×112像素。图片地址应当能够被搜索引擎直接访问，并使用 Google 图片支持的格式。如果使用白色 Logo，还要检查它在白色背景上是否能够正常显示。

在代码中，Logo 可以使用 ImageObject，也就是图片对象类型来描述。

地址应使用 PostalAddress，也就是邮寄地址类型，拆分填写街道、城市、省份、邮政编码和国家。国家建议使用两位国家代码，例如中国填写 CN。

联系方式可以使用 ContactPoint，也就是联系信息类型。电话号码应包含国家和地区代码，contactType 则用来说明联系方式的用途，例如客户服务。

只有用户目前确实可以使用的联系方式才应填写。涉及隐私或不对外公开的信息，不要因为代码中有对应字段就写进去。结构化数据最终会出现在公开网页的源代码中。

一套可以修改的JSON-LD模板

下面使用 example.com 和“示例科技有限公司”作为占位内容。代码通过 HTML，也就是组成网页源代码的标记语言，嵌入页面。

正式上线前，必须逐项替换示例内容，并删除不适用的字段。示例名称、地址、电话、邮箱、账号链接和 Wikidata 编号都不能留在正式代码中。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.example.com/#organization",
  "name": "示例科技有限公司",
  "legalName": "示例科技有限公司",
  "alternateName": "示例科技",
  "url": "https://www.example.com/",
  "logo": {
    "@type": "ImageObject",
    "url": "https://www.example.com/assets/logo.png"
  },
  "description": "提供工业设备设计、生产与技术服务。",
  "foundingDate": "2018-06-01",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "示例路88号",
    "addressLocality": "杭州市",
    "addressRegion": "浙江省",
    "postalCode": "310000",
    "addressCountry": "CN"
  },
  "contactPoint": {
    "@type": "ContactPoint",
    "telephone": "+86-571-0000-0000",
    "email": "contact@example.com",
    "contactType": "customer service"
  },
  "sameAs": [
    "https://www.linkedin.com/company/example-company",
    "https://www.youtube.com/@example-company",
    "https://www.wikidata.org/wiki/Q000000"
  ]
}
</script>

这是一套修改模板，不是一段可以直接上线的正式代码。某个字段没有真实信息时，应删除整个字段，而不是保留空值或示例值。

Organization Schema应该放在哪个页面

优先放在网站首页，或者明确介绍组织的“关于我们”页面。一个站点保留一套主要的 Organization 数据即可。

如果内容管理系统会在每个页面自动输出 Organization，应确认所有页面中的内容和 @id 完全一致。内容管理系统通常简称 CMS，指用于编辑和发布网站内容的后台系统。

重复输出本身不一定造成错误，但如果网站主题和多个插件分别生成名称、Logo 与 sameAs，就容易出现信息冲突，也会增加维护成本。

不要只把 JSON-LD 放在需要登录、带有 noindex，或者被 robots.txt 阻止的页面。

noindex 是要求搜索引擎不要收录该页面的设置；robots.txt 是用于限制搜索引擎访问网站页面的文件。

部署完成后，应使用 Google Search Console，也就是查看网站在 Google 中抓取和收录情况的管理工具，检查目标页面。其中的 URL Inspection，中文通常称为“网址检查工具”，可以用来确认 Google 实际读取的 HTML 中是否包含最新数据。

上线前必须完成的8项检查

部署前，可以使用 Rich Results Test，也就是 Google 的“富媒体搜索结果测试”工具检查代码。上线后，再通过 Search Console 的网址检查工具确认实际读取结果。

正式发布前，逐项检查：

JSON-LD 语法是否有效，括号、引号和逗号是否正确；
@context 和 @type 是否正确；
名称、网址、Logo 和地址是否与页面可见内容一致；
Logo 是否可以直接打开并被搜索引擎访问；
每条 sameAs 是否确实属于同一组织；
示例值、空字段和失效链接是否已经全部删除；
富媒体搜索结果测试是否出现关键错误；
上线后，网址检查工具是否能够看到最新代码。

代码通过测试，不代表网站一定会出现知识面板、Logo 或其他搜索展示。知识面板是搜索结果中集中展示组织信息的卡片。

结构化数据提供的是便于机器读取的组织信息，不是搜索结果展示保证。

上线后怎么维护

组织名称、官网域名、Logo、地址、联系方式或外部资料页发生变化时，需要同时更新结构化数据和页面正文。

已经失效的 sameAs 应及时删除，不要长期保留已注销账号。每次更新后，应保留版本记录，重新测试 JSON-LD，并检查网页最终输出的代码。

如果代码由 CMS 插件生成，还要在网站模板或插件升级后检查两件事：

原有字段是否被覆盖；
页面中是否出现重复或互相冲突的组织信息。

最终应以公开页面实际输出的源代码为准，不能只看插件后台显示的内容。

常见问题

1. Organization Schema必须放在每个页面吗？

不需要。Google 建议放在首页，或者“关于我们”这类专门介绍组织的页面。如果系统会在多个页面自动输出，应确保内容和 @id 完全一致。

2. `sameAs`必须填写8条吗？

不需要。官方没有统一的最低数量要求。只填写能够明确识别同一组织的真实页面，准确性比数量更重要。

3. 没有Wikipedia或Wikidata页面怎么办？

不填即可。不要复制模板中的示例 QID，也不要为了填写结构化数据而创建不符合平台规则的条目。

4. 添加Organization Schema后一定会被AI引用吗？

不能保证。它主要帮助系统理解和区分组织信息，也可能影响 Logo 等搜索展示元素。是否被引用，还取决于内容、搜索引擎是否能够访问和收录页面，以及用户提出的具体问题。

这里的收录，是指搜索系统保存网页信息，并允许用户通过搜索找到该页面。

5. 使用插件生成后还需要检查吗？

需要。插件可能继续使用旧名称、默认 Logo 或空的社交链接，也可能与网站主题生成的数据重复。最终应以页面实际输出的源代码为准。

6. 怎么验证部署是否成功？

部署前使用富媒体搜索结果测试检查代码；上线后使用 Search Console 的网址检查工具，查看 Google 实际读取的页面。发现错误并修复后，再请求 Google 重新访问页面。

添加之前，先确认6条规则

1. 放在真正介绍组织的页面

2. 不需要填满所有字段

3. 选择与组织匹配的类型

4. 正确理解sameAs

5. 数量没有统一下限

6. 优先使用JSON-LD，并检查实际输出

每个字段分别填写什么

name、legalName和alternateName怎么区分

@id为什么要保持稳定

sameAs应该放哪些链接

Logo、地址和联系方式怎么处理

一套可以修改的JSON-LD模板

Organization Schema应该放在哪个页面

上线前必须完成的8项检查

上线后怎么维护

常见问题

1. Organization Schema必须放在每个页面吗？

2. sameAs必须填写8条吗？

3. 没有Wikipedia或Wikidata页面怎么办？

4. 添加Organization Schema后一定会被AI引用吗？

5. 使用插件生成后还需要检查吗？

6. 怎么验证部署是否成功？

公开资料入口

4. 正确理解`sameAs`

`name`、`legalName`和`alternateName`怎么区分

`@id`为什么要保持稳定

`sameAs`应该放哪些链接

2. `sameAs`必须填写8条吗？