品牌词：让答案引擎说对你是谁
品牌词在答案引擎这边的问题是消歧：它得先确定这个名字指的是谁。落地是一块结构化数据、一串你控制得住的资料页，和把名字在七个地方写成同一个样子。
品牌词的功夫，多数人花在「怎么让搜自己名字的人搜到自己」上。答案引擎那边的问题往前一步：它得先确定这个名字指的是谁，才敢写「据某某说」。这件事跟关键词几乎无关，落地是三样东西——一页上的一块结构化数据、一串你自己控制得住的资料页链接，以及把自家名字在七个地方写成同一个样子。最后那一样，是塌得最多的。
读这篇前
这一章讲的是你在自己站上怎么声明。别人在站外怎么说你，是另一件事、另一套杠杆，两者很容易混。术语先分清：被提及，和被当作来源引用，不是一回事。
结构化数据本身你应该已经跑通了。哪些类型现在还值得做，在结构化数据怎么加那篇。这一章往那份清单里加一种类型，并解释它为什么和别的不一样。
品牌词的真问题是消歧，不是排名
搜索引擎可以在不知道「这一页是谁发的」的情况下给它排序。答案引擎不行，它要署名。要写出「据 Acme 说」，它得确定是哪一个 Acme，而这个确定来自几个互不相干的来源彼此对得上。
sameAs 就是干这个的。schema.org 给它的定义是：URL of a reference Web page that unambiguously indicates the item's identity. E.g. the URL of the item's Wikipedia page, Wikidata entry, or official website.（一个能无歧义指明该事物身份的参考网页地址，比如它的维基百科页、Wikidata 条目或官网。）你不是在描述自己，你是在指出几个已经描述过你的地方，好让机器交叉核对。
结构化数据不是一句「我是谁」的声明。它是一组地址，指向这句声明可以被验证的地方。
这个属性铺得很广。schema.org 自己的页面写着它的部署量超过 1000 万个域名，依据是 Google 2026 年 7 月的网页索引。但铺得广不等于有用——一串指向荒废账号的 sameAs 比没有更糟：你主动请人来核对，然后核对没通过。
多数站都停在最后一步之前
这件事我们在长期跟的那 30 个首页上测过。27 个可达首页里，16 个带了任何 JSON-LD，其中 12 个标了组织。而这 12 个里有 2 个——Wired 和 Ars Technica——声明了 Organization 却完全没有 sameAs。这正是本章要说的形状：块在，能让机器验证的那一半不在。完整数字在多数首页根本没有结构化数据那篇。
两个出版商不构成趋势，我们也不打算把它说成趋势。值得点名是因为这两家都是有正经工程团队的大编辑部，最省事的那个解释被排除了。声明那一块是模板能生成的；资料页清单那一块得有人坐下来一条条攒，而承担验证的恰恰是后半截。
这块标记放在哪一页
放一页，不是每一页。Google 的说法很明确：We recommend placing this information on your home page, or a single page that describes your organization, for example the about us page. You don't need to include it on every page of your site.（建议放在首页，或者某一个介绍你的组织的页面，比如关于我们页。不需要放在站内每一页上。）2026-08-18 读自 Organization 结构化数据文档。
同一页还建议用「最贴合你的那个 Organization 子类型」——电商用 OnlineStore，产品另加 SoftwareApplication，实在没有更贴的就用 Organization。用笼统的类型不算错，只是同样的工夫给出的信息更少。
交付物：一段可以直接粘的 JSON-LD
放进首页的 <head>。所有值都要换成你自己的，任何一个你登录不进去的资料页，那一行删掉。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Acme Widgets",
"legalName": "Acme Widgets Limited",
"url": "https://www.acmewidgets.com",
"logo": "https://www.acmewidgets.com/logo.png",
"description": "Acme Widgets makes fastening hardware for furniture manufacturers.",
"foundingDate": "2019-04-01",
"sameAs": [
"https://www.linkedin.com/company/acme-widgets",
"https://github.com/acmewidgets",
"https://www.crunchbase.com/organization/acme-widgets",
"https://en.wikipedia.org/wiki/Acme_Widgets"
]
}
</script>四条 sameAs 好过十二条。每一条都是机器可以去验的一句话，每一条死链都是你自己送上门的一次失败。
🔴 出海品牌的两个中国式陷阱
第一个是中英双名。公司主体是中文名，对外品牌是英文名，两者在营业执照、域名、社媒账号、平台店铺名上各写各的。对机器来说这不是「一个公司两种叫法」，是两个候选实体。做法是：把对外用的那个定成 name，中文主体名放 legalName，只声明一次，然后所有对外物料统一用前者。
第二个是把登录墙后面的资料页塞进 sameAs。这一行的作用是让机器匿名去取那一页做交叉核对；一个要登录、或者对境外访问不开放的页面，取不到就核对不了。它不会带来惩罚，只是那一行不起作用——而你以为它起了。
验证方法和上面一样朴素：把每条 sameAs 的地址复制出来，不登录、从外网请求一次，看是不是 200 且能看到你的名字。
交付物：名字必须一致的七个地方
把这张表过一遍。每一行都是从公司外部看得见的，这也正是不一致要付代价的原因。
| 在哪 | 查什么 |
|---|---|
| 首页 title | 品牌串的拼写和大小写，只有一种写法 |
| 可见的 h1 或字标 | 与 title 同一个串，不是艺术变体 |
Organization.name | 客户在用的那个名字，不是注册主体 |
Organization.legalName | 注册主体，只在不同时写，且只写一次 |
og:site_name | 与 Organization.name 完全一致 |
| 每个 sameAs 资料页 | 那一页自己的显示名也要对得上 |
| 正文与署名 | 别把口头简称当成正式名字用 |
第七行是悄悄毁掉前六行的那一行。一家叫 Acme Widgets 的公司，每篇博客都写「Acme 认为」，等于给机器递了两个候选名字——而世界上另一个叫 Acme 的实体，会很乐意把这份歧义吸收过去。
怎么看引擎现在怎么认你
三步，不需要付费工具。
- 用 curl 取你的首页，确认这段 JSON-LD 在交付的 HTML 里，不是脚本加载后注入的。爬虫看不见的块等于没有。
- 把页面丢进 Google 的富媒体结果测试，确认 Organization 这块能解析、无报错。
- 让两个答案引擎各用一句话描述你的公司，把返回的话记下来。每月一次，存着。错得不一样是进展，错得一模一样是实体问题。
第三步是故意做软的。这里没有经过验证的测量——你记录的是一段时间里的印象，它之所以有价值，只是因为你写下了第一次。
每个月用同样的问法问一遍，答案连日期一起存在一个文件里。一个月两句话就够。价值在于有人问「改名到底生效没有」时你手上有记录，否则就是凭记忆争论开春时引擎说过什么。
两种做过头的方式
两种看着都像更用心，实际都更糟，所以它们总能通过评审。
- 每一页都放这块。不会因此被罚，但把组织声明重复到一千页上不会让它更强，只会让一个填错的值难改一千倍。
- 把不归你管的资料页列进去。别人建的目录条目、地址还是旧的，那不是身份证据，那是另一个挂着你名字的实体。
这一章到哪儿为止
这些东西不会让引擎引用你。它只消除一种特定的失败——被认成别的东西——就只有这一件。我们没法告诉你任何引擎给这些信号多大权重，因为没有一家公布过，给你一个数字的人是在猜。
它对站外别人怎么说你也毫无作用，那是更难的一半，而且完全不响应标记。改名或者改版之后悄悄有一处不一致了，还能发现这七处对不对得上，是 QueryWin 正在做的事。
常见问题
一句话说清品牌词在这里指什么
让机器把你的品牌名解析成一个没有歧义的组织，这样它读到的关于你的一切都堆在同一个地方，而不是劈成两半。
sameAs 该写几条
写你真的在维护的那几条，多数公司是三到六条。没有任何公开的阈值，一长串死掉的资料页不如一小串活的。
维基百科页面有用吗
它是很强的参考，因为它独立、而且机器可读。你不能给自己建一个，把它当成目标去做，结局通常是条目被删、外加在编辑那里落个坏名声。
做完这些，品牌词会进 AI 答案吗
不会。它让引擎在已经有话要说的时候，能说对是谁。被说准和被经常说，是两个问题。
本文属于 QueryWin 实操手册 · 第 2 阶
