一个让海外买家误判产地的真实场景

今年 8 月底，我一个做工业阀门出口的独立站客户找我排查一个问题。他们产品页写得很规整：品牌名、口径、压力等级、材质全有，但通篇没有一个字提到「工厂在哪、谁造的」。有海外买家在 AI 搜索里问「某某品牌阀门 where is it made」，AI 给出的答案是这家公司在德国有办事处，产品大概率产自德国——实际上工厂在浙江，只是每年从汉堡港走一部分货。

我把同一个问题分别丢给 Perplexity、ChatGPT 和 DeepSeek，换了 10 种问法（含英文、德文），统计下来 30 次回答里产地答错 21 次，引用来源清一色是第三方 B2B 目录站和行业黄页。AI 引擎没有从你的页面上读到「制造商是谁、原产国是哪」，就只能拿别人的二手信息来拼答案。

这就是生成式引擎优化（Generative Engine Optimization, GEO）里最典型的一类丢分项：你的页面缺少可被机器直接读取的供应链实体。AI 爬虫不缺你产品参数，缺的是「工厂」这个实体本身。补法也不玄学，就是在 Product 结构化数据里把 manufacturer 和 countryOfOrigin 两个属性写扎实。

Product 页面上要补的两个实体属性

Schema.org 的 Product 类型预留了一组供应链属性，其中和产地、厂家直接相关的是 manufacturer（制造商）和 countryOfOrigin（原产国）。我见过最多的错误写法是只给一个字符串，比如 "manufacturer": "ACME Valve"。字符串在 AI 引擎眼里只是一段文字，构不成实体。

manufacturer 要写成带 @id 的 Organization

正确做法是把 manufacturer 写成一个完整的 Organization 对象，并给它一个全局 @id。JSON-LD 完整示例如下（下面代码里的注释行只是讲解用，实际输出到页面时请删掉注释）：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  // 产品名保留完整型号，便于 AI 与目录站做区分
  "name": "ACME A-300 Industrial Ball Valve",
  // sku 是产品级实体标识，同款不同规格不要共用
  "sku": "A300-DN50",
  // 原产国用 Country 类型，不要只写 "CN" 这种裸代码
  "countryOfOrigin": {
    "@type": "Country",
    "name": "China"
  },
  // manufacturer 必须是 Organization，不能写成字符串
  "manufacturer": {
    "@type": "Organization",
    // @id 是这个工厂实体在全网的全局标识
    // 它不随语言或页面路径变化
    // AI 引擎靠它把多处提及合并回同一实体
    "@id": "https://www.acmevalve.com/#organization",
    "name": "ACME Valve Manufacturing Co., Ltd.",
    // 官网首页作为实体的规范来源 url
    "url": "https://www.acmevalve.com/",
    // logo 参与 AI 回答里的品牌卡片展示
    "logo": "https://www.acmevalve.com/logo.png",
    // 地址块补全到城市级，别只留国家
    "address": {
      "@type": "PostalAddress",
      // countryName 是 AI 读取产地最直接的锚点
      "addressCountry": "CN",
      "addressLocality": "Wenzhou, Zhejiang"
    },
    // sameAs 指向能交叉印证工厂身份的权威页面
    // sameAs 只留能互相印证的权威页面
    // 领英公司主页是最常用的一条等价边
    "sameAs": [
      "https://www.linkedin.com/company/acme-valve",
      "https://www.facebook.com/acmevalve"
    ]
  },
  // 报价块虽与供应链无关，但属于 Product 必备上下文
  "offers": {
    // Offer 类型与货币、库存状态都要写全
    "@type": "Offer",
    "priceCurrency": "USD",
    "price": "89.00",
    // 库存状态用 Schema.org 官方枚举值
    "availability": "https://schema.org/InStock"
  }
}
</script>

几个关键点拆开说：

• @id 建议固定为官网域名下的一个稳定片段地址（比如 /#organization），英文站、德语站、西语站共用这一个，后面细讲。
• address.addressCountry 建议同时保留 ISO 代码，Country 的 name 写完整国名，两处信息互为校验。
• sameAs 只放真正能证明工厂身份的页面，领英公司主页、官方 GitHub、行业认证机构名录都行；塞一堆不相关的社交链接反而稀释置信度。

countryOfOrigin 与 countryOfAssembly 别混

这两个属性经常被搞混。countryOfOrigin 指产品原产国，直接影响海关归类和买家对「Made in where」的判断；countryOfAssembly 指组装地。如果你的工厂在浙江、在越南只有一条组装线，两个属性要分开写清楚，别用一个含糊的产地描述打发。AI 引擎对这类属性的容错很低，写混了它就任选一个来回答。

多语言站：一个 @id 走 en/de/es

我那个客户站有英、德、西三个语言版本，最早三个版本的 JSON-LD 各写各的，连公司英文名都拼出了两种。这在 AI 引擎眼里就是三个不同的组织。改法很直接：

• 三个语言版本共用同一个 @id，即 https://www.acmevalve.com/#organization。@id 不带语言路径，它是实体标识，不是页面地址。
• 每个语言版本的 name 字段可以本地化（德语站写公司注册名的德文形式），但 @id、url、logo、addressCountry 保持一致，让 AI 引擎通过 @id 把三个版本合并回同一个工厂实体。
• 页面层面配好 hreflang，让爬虫知道这些页面互为翻译，进一步辅助对齐。

德语站的实际输出长这样（仅展示与实体一致性相关的字段）：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  // 德语产品名本地化，sku 与英文站保持一致
  "name": "ACME A-300 Industrieller Kugelhahn",
  "sku": "A300-DN50",
  // 与英文站完全相同的 @id，实体在此合并
  // 原产国用 Country 类型，德语站同样写完整国名
  "countryOfOrigin": {
    "@type": "Country",
    "name": "China"
  },
  "manufacturer": {
    "@type": "Organization",
    // @id 不随语言变化，这是多语言对齐的核心
    "@id": "https://www.acmevalve.com/#organization",
    // 注册名保持官方拼写，不强行翻译
    "name": "ACME Valve Manufacturing Co., Ltd.",
    // url 指向德语首页，@id 不变
    "url": "https://www.acmevalve.com/de/",
    // 地址国家与英文站一致，互为印证
    // 地址块与英文站逐字段一致
    "address": {
      "@type": "PostalAddress",
      "addressCountry": "CN",
      "addressLocality": "Wenzhou, Zhejiang"
    },
    // sameAs 同一套链接，三站指向同一批权威页面
    "sameAs": [
      "https://www.linkedin.com/company/acme-valve"
    ]
  }
}
</script>

多语言站的实体输出架构可以用下面这张图表示，爬虫从三个语言入口进来，最终都归并到同一个工厂实体：

flowchart LR
  subgraph 站点层
    EN[英文站 /en/products/a300] --> LD1[JSON-LD<br/>@id: /#organization]
    DE[德语站 /de/produkte/a300] --> LD2[JSON-LD<br/>@id: /#organization]
    ES[西语站 /es/productos/a300] --> LD3[JSON-LD<br/>@id: /#organization]
  end
  LD1 --> CRAWLER
  LD2 --> CRAWLER
  LD3 --> CRAWLER
  subgraph AI引擎侧
    CRAWLER[AI 爬虫抓取] --> ALIGN[实体对齐模块]
    ALIGN --> MERGE[(同一工厂实体<br/>ACME Valve Manufacturing)]
    MERGE --> ANSWER[回答产地/厂家问题]
  end

原理剖析：AI 引擎怎么做实体对齐（entity linking）

为什么 @id、url、sameAs 这三个字段比「把公司名多写几遍」有用得多？要理解 AI 引擎侧的实体链接（entity linking）机制。

AI 引擎在抽取页面信息时，并不是把文本切片存进向量库就完事。对组织、地点、产品这类强实体，检索管线里有一条专门的实体抽取与归一路径：先从页面抽候选实体（这里有家公司叫 ACME Valve，地址在温州），再到实体库里找这个候选跟已知实体的对应关系，把分散在多个页面的提及聚合成一个知识图谱节点。聚合的依据就是锚点：

• @id 是强标识锚点。两个页面输出同名实体但 @id 不同，管线倾向于当成两个实体；@id 相同，则基本可以判定是同一个。这是跨语言、跨页面合并实体的最可靠信号。
• url 是规范来源锚点。Organization 的 url 指向官网首页，AI 引擎会把它当成这个实体的规范来源，引用产地时会优先回到这个域名查证。
• sameAs 是等价边锚点。领英公司主页本身在 AI 引擎的知识库里往往已是独立实体，sameAs 相当于在你的实体和它的实体之间画了一条「这是同一个东西」的边，置信度是乘法叠加的。

还有一个容易被忽略的点：AI 爬虫对 Product 页的抓取频率和普通搜索引擎不同。Perplexity、GPTBot、字节和智谱的爬虫在 9 月我们观察的那个站上，对产品页的平均回访周期在 9 到 14 天，结构化数据改动后实体库更新明显滞后于 Google 收录。所以改造后别急着下结论，观测周期至少给到四周。

整个过程可以用一张图概括：

flowchart TB
  A[页面 mention<br/>文本与 JSON-LD] --> B[候选实体抽取]
  B --> C{锚点判定}
  C -- "@id 相同" --> D[合并为同一实体]
  C -- "url 指向同域名" --> D
  C -- "sameAs 等价边" --> E[与领英等外部实体相连]
  E --> D
  C -- "仅 name 字符串相似" --> F[低置信度<br/>可能被当成新实体]
  D --> G[(知识图谱节点)]
  G --> H[AI 回答中引用正确厂家与产地]
  F --> I[AI 引用第三方目录站<br/>产地答错]

字符串匹配走的是低置信度路径，一旦你的实体只能靠 name 去猜，AI 引擎就很可能引用第三方 B2B 目录页里那个同名的其他公司——这就是开头那个客户产地答错的直接原因。

改造前后 6 周的一手观测对照

9 月 1 日我把三个语言站的 Product 模板统一改完：manufacturer 换成带 @id 的 Organization、补齐 address 与 sameAs、countryOfOrigin 改用 Country 类型，领英主页同步更新了官网链接。之后每周固定用 30 个产地/厂家问法（中英德三种语言各 10 个）在 Perplexity、ChatGPT、DeepSeek 上测一轮。需要说明：这是单站观测，样本只覆盖一个工业品独立站，数据仅供参考，不构成普适结论。

有两点经验值得单独记下来。第一，转折点出现在第 3 周前后，恰好是领英公司主页的「Website」字段指向官网被 AI 引擎的等价边采纳之后，说明 sameAs 这类外部印证不是摆设。第二，各引擎的进度差很大，Perplexity 第 3 周就开始稳定引用官网，DeepSeek 拖到第 5 周，不同引擎的实体库刷新节奏完全不同，不要用单一引擎的表现评判改造效果。

误区澄清与后续衔接

按这轮改造和后续几个站点的复现，整理三个高频误区：

• 误区一：写了 manufacturer 字符串就算数。 字符串没有 @id、没有 url、没有地址，实体对齐管线拿不到任何锚点，等于没写。
• 误区二：sameAs 越多越好。 我见过一个站往 sameAs 里塞了十几个链接，其中一半是早已失效的页面。等价边指向失效或无关页面，不仅不加分，还会拉低整个实体的置信度。控制在三五个能互相印证的权威页面即可。
• 误区三：只在英文站补结构化数据。 德语、西语站如果 @id 各写各的，AI 引擎在回答德语问题时抓到的是一个孤立的新实体，前面英文站的功夫白费一半。

趋势上看，主流 AI 引擎对组织类实体的对齐正在从「文本相似度兜底」转向「结构化标识优先」，@id 与 sameAs 的权重只会越来越高。趁现在多数同行还没做，先把锚点钉牢，成本很低。至于传统搜索侧的收录与排序优化，那是另一条管线的事，后续篇目再展开。

欢迎在评论区交流你观测到的各引擎实体库刷新速度，尤其是非工业品类目的数据。

参考与延伸

• Schema.org manufacturer 属性定义：https://schema.org/manufacturer
• Schema.org countryOfOrigin 属性定义：https://schema.org/countryOfOrigin
• Schema.org Organization 类型定义：https://schema.org/Organization
• Google 搜索中心结构化数据通用指南：https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data

GEO、AI优化AIO、manufacturer 实体对齐、countryOfOrigin、sameAs、JSON-LD、独立站 AI 流量、实体识别