问ChatGPT或Gemini一家小公司的情况，答案经常错在一些很基础的地方：认成了另一家同名公司、写错了业务领域，或者从某个目录站抓来一个早就停用的电话号码。这些错误大多不在文章内容本身，而在网站从没用结构化数据说清楚"我是谁"。
id="4V0D4LOT">解法不复杂：搭一个JSON-LD的Organization块，给它一个固定的@id，再把它和Person（创始人）以及一组sameAs外部档案连起来。这里没有什么魔法，但这是搜索引擎和AI把同一实体的零散信息拼到一起时依赖的底层部分。
@id为什么必须固定
@id是给实体用的标识URI，不是给页面用的。常见约定是拿首页URL加一个片段，比如 https://example.com/#organization 和 https://example.com/#founder。
当站内每个页面都指向同一个@id（在publisher、author、provider这些位置里），你等于在告诉解析器：这是一个实体，而不是50个页面上的50家不同组织。
最小可用的JSON-LD块
放在首页，也可以重复放在介绍页。结构上是一个@graph数组，里面两个节点：Organization和Person，互相用@id引用。
- Organization节点带@id、name、url、logo、description，founder字段指向Person的@id，contactPoint里写telephone、contactType、areaServed，sameAs列出LinkedIn、GitHub、YouTube等外部档案链接。
- Person节点带@id、name、jobTitle，worksFor指回Organization的@id，url指向介绍页。
填写时有几个坑。name必须和Google Business Profile、社交档案、网站页脚上的名字逐字一致，差一个词（"ABC"和"ABC Agency"）就足以生成两个实体。sameAs只写你自己在管、且还在活跃的档案，塞死链或荒废账号只会添乱。schema里的电话、地址必须和页面上显示的一模一样，schema写一套、HTML写另一套是高频错误。
其他页面只做引用，不重复声明
文章页不要重新声明完整的Organization，只做引用就够了：Article类型里author指向创始人的@id，publisher指向组织的@id。服务页用Service类型，provider指向组织的@id。
这样数据只有一个来源，改一处，全站都对。
上线前的检查清单
- 把HTML贴进Schema Markup Validator，看graph能否正确解析、各个@id是否真的连上了。
- 对有富媒体结果的类型（Article、FAQ等）跑一遍Google的Rich Results Test。
- 用View source而不是Inspect，确认JSON-LD块在原始HTML里。不少爬虫包括一些AI bot不执行JavaScript，渲染后才插入的schema可能被直接跳过。
- 拿sameAs和真实档案清单对一遍，把已经失效的删掉。
schema只是自报家门
schema说到底只是你自己的声明。搜索引擎和AI还会用外部来源交叉验证：企业档案、新闻报道、论坛里提到你时用的是不是同一套信息。外面没有任何东西对得上，schema写得再漂亮作用也有限。
所以真正要问的是：你给sameAs填了几个档案？有没有遇到过schema明明写对了、AI还是认错品牌的情况？
热门跟贴