没有GTIN能填UPC码吗？GMC里没有UPC这一栏

摘要：把200万个UPC-E码逐个算一遍，其中58%直接填进gtin那一栏，能顺顺当当骗过Google的校验位。末位是5到9的那100万个，一个不落全部通过；末位是3的那20万个，一个都过不去。位数和校验位这两道闸，只拦得住写错的数字，拦不住写成了另一件商品的数字。

后台翻了三遍，属性表里就是没有UPC这一栏。

这大概是做Google购物的人最容易卡住的一分钟。手上明明有一串12位的UPC码，印在包装背面的条形码下方，清清楚楚。可Merchant Center的字段清单里，只有一个叫gtin的东西。于是很多人做了同一个动作：把商品标记成没有唯一标识符，然后接着往下走。

问题就出在这一步。UPC不是GTIN的替代品，它本身就是GTIN。

手上只有UPC码，Merchant Center里该填哪一栏？

GTIN是Global Trade Item Number的统称，中文叫全球贸易项目代码。它不是某一种条码的名字，而是一整个家族的户口本。北美用的UPC、欧洲用的EAN、日本用的JAN、图书用的ISBN、整箱整托盘用的ITF-14，全都是GTIN的不同格式，只是位数和使用地区不一样。

所以答案很简单：有UPC就直接填进gtin，这不是凑合，这就是标准填法。Merchant Center里没有UPC字段，将来也不会有，因为压根不需要。

按Google官方对gtin属性的规定，这一栏接受的位数只有0、8、12、13、14这五种，数据类型是数字，中间的空格和短划线会被系统忽略掉。各种格式对应的位数是这样的：

这张表里藏着两个动作词：转换。8位的UPC-E要转成12位，10位的ISBN要转成13位。它们不是“也可以转”，是提交之前必须转。

很多人不知道UPC-E是什么。它是UPC-A的压缩版，专门给口香糖、单支笔这种没地方印条码的小包装用。压缩的办法是把UPC-A里连成一串的零抽掉，剩下8位。抽掉的零在扫码枪里会被自动补回去，但在Merchant Center的输入框里不会。

表格最后一行的ITF-14也值得单独说一句。它是包装层级码，一箱、一托盘各有各的号，跟零售单品那个码不是同一个东西。工厂发来的资料里经常两个码并排列着，采购顺手把整箱那个填进了feed，商品照样上架，因为14位是合法位数、校验位也算得过。真正的后果要到很久以后才显形：比价的时候，你那件单品被拿去和别人家的整箱装比价格，怎么看都贵得离谱。

分辨方法是看GTIN-14的第一位。零售单品的13位码补零成14位时首位是0，而包装层级码的首位是1到8，代表不同的箱装规格。首位不是零的，基本可以断定不该出现在零售feed里。

8位的UPC-E直接提交，那道闸拦得住吗？

这是保哥这次真正想弄明白的事。

直觉上，Google有一道校验位验证，填错的数字应该会被打回来。校验位就是GTIN最后那一位，它由前面所有数字按固定权重算出来，随便编一个数字，最后一位对不上的概率是九成。听起来挺可靠。

可UPC-E的情况特殊。它是8位，而GTIN-8也是8位。位数这道闸对它完全无效。剩下的就只有校验位那一关了。

所以我把所有可能的UPC-E码穷举了一遍。数字系统位取0和1，后面6位数据从000000排到999999，一共200万个。每一个都按GS1规范展开成UPC-A算出真校验位，拼成商家会从条码上照抄的那8位，再拿GTIN-8的校验规则去验一次。跑之前先用五组公开的标准配对校准了尺子，包括EAN-13的经典示例9780306406157，以及UPC-E 0425261展开成042100005264这一对，全部吻合才开始跑。

结果比我预想的难看得多。

末位是5到9的UPC-E码，直接填进去，校验位验证一次都拦不住。不是概率高，是必然通过。

这不是巧合，是能证明的。UPC-E展开成UPC-A时，末位5到9那一档的规则是在中间插进4个零。校验位算法按从右往左的奇偶位分配3和1两种权重，插进去的零本身不贡献任何数值，而4是偶数，插完之后后面每一位的奇偶都没变。于是两个式子算出来的加权和完全相同，校验位自然也相同。

末位是3那一档，插的是5个零，奇偶全部翻转，而且被抽走的那个3在展开体里根本不出现。两个式子的差固定是个奇数，永远不可能被10整除。所以那20万个码，一个都通不过。

把这两件事合起来说就是：你把UPC-E直接填进gtin，有超过一半的概率不会收到任何报错，商品照常上架，而那个8位数字指向的是GTIN-8编码空间里另一件东西——那是GS1单独分配给小包装商品的号段，跟你的商品没有半点关系。

会报错的那42%，反倒是幸运的。至少它告诉你填错了。

校验位算得过，就等于填对了吗？

顺着上面那条线再往下走一步。既然校验位这道闸在UPC-E面前形同虚设，那它到底能拦住什么？

我又跑了三组对照。

位数不对的那一类，Google一个都不放过。ISBN-10的10位、内部编号的9位和11位，全部被位数闸挡在门外。这道闸虽然笨，但绝对可靠。

中间那一行是重点。把店铺自己的SKU填进gtin，这个错误在独立站里泛滥成灾。随机的12位纯数字，恰好通过校验位的概率是十分之一，再扣掉落在受限前缀里被二次拦下的那部分，还剩7%左右能完整地漏进Google的商品目录。

说到受限前缀，这是Google那道闸的第二层，很多人根本不知道它存在。官方明确写了两条禁止提交的号段：前缀为02、04或2的属于受限范围，前缀为05、98或99的属于优惠券范围。前者是企业内部自用码，超市里现场称重打印的价签就用它；后者是优惠券专用。这两类号在GS1体系里本来就不指向任何一件全球流通的商品。我算了一下，随机生成的合法13位码里有15.06%会落进这两个区间，等于白送一道拦截。

这一层拦截也解释了一个现象：为什么有些卖家在某个中文平台上买了一批“便宜条码”，提交后不报错，过一阵子却被判无效。因为那批码要么本来就在受限号段里，要么早就被别人用过。

顺带说一句站内的实测数据。之前抓了131个海外独立站的商品页，在结构化数据里真填了条码的只有11个站，一共141条，其中25条经不起校验位一算，而这25条集中在4个站——挖开看，填的其实是平台变体ID的后八位。这就是上面那7%在真实世界里的样子。

手上只有MPN，能顶替GTIN填进去吗？

不能。而且这个错法有个很坏的性质：它有小概率不报错。

MPN是厂商自己定的料号，通常带字母、带横线，位数也不按GTIN那套走。填进gtin那一栏，多数情况下当场报invalid value [gtin]，位数闸先把它挡在门外了。

危险的是少数情况：万一你的MPN恰好是纯数字，位数又正好是12位。上面那组对照量过这种概率——纯数字冒充12位UPC，7%能完整漏过去。漏过去之后是什么局面？你提交了一串合法的、但属于别人产品的GTIN。缺一个标识符只是信息不全，提交一个别人的标识符是编造，后者在Google那里的定性严重得多。

MPN有它自己的位置，就叫mpn。填在那里，同时务必把brand也填上。至于identifier_exists，下一节会说它的语义；这里先补一句：这个字段缺省值就是true，所以有品牌有料号、只是没条码的时候，最省事的处理是根本不提交它。

brand加MPN这一组，能顶多少用？

比什么都没有强不少，但要清楚它弱在哪。

GTIN是全球唯一且跨平台通用的，MPN只在“品牌加料号”这个组合下才唯一。机器做跨源合并时，前者是精确匹配，后者要先确认品牌名说的是同一家公司——多一道判断就多一分不确定。后面要讲的评论聚合、比价合并那套价值，MPN只能兑现一部分。

在配件、零部件、工业品这些品类里，厂商料号本来就是行业内通用的检索键，MPN的实际效果会好一些。OpenAI的商品feed规范里也收mpn，同样是可选字段，要求是“保留其标点和大小写”——注意这跟gtin那一栏“不带空格和短划线”的要求正好相反，别用同一套清洗规则处理两个字段。

缺GTIN的代价是有的，只是不像很多人以为的那么重。Merchant Center里有一类专门的提示叫“因缺少值而导致效果受限”，缺gtin是其中最常见的一种。它不是拒登，商品照常投放，但Google没办法把你的商品和目录里的同款对上，覆盖面和展示量都要打折。

代理别人的品牌，码该找谁要？

找供应商。他们手上一定有，只是常常懒得给。

要的时候把用途说具体：Google Merchant Center和AI购物渠道需要这个号，比笼统地说“给我个条码”容易要到得多。前者是一个能落到具体系统的诉求，后者听起来像可有可无的资料整理。

说自己没有GTIN，凭什么Google说了不算？

现在说回最开始那个动作：找不到UPC字段，于是把商品标成没有标识符。

这个开关在feed里叫identifier_exists。它的取值只有yes、true、no、false四个，Merchant API里只收true和false，而且必须用英文提交，写成中文的“否”不算数。这一条看着像废话，但每年都有人栽在本地化插件自动翻译上。

关键在于，这个开关不是你说了算的。

Google官方对“商品标识码不正确”这个问题的说明写得很直白：如果你把这个属性提交成false，而Google认为该商品应该拥有GTIN，商品会被拒登，直到你提供为止。判断依据是那句“我们认为该商品拥有全球贸易项目代码，因为类似的商品/服务会使用此标识码”。

注意这句话的落点。它不是去比对别家商店的同款商品页，而是看你所在的品类通常怎么做。你卖的是量产的电动牙刷，这个品类里九成九的商品都有条码，那你说自己没有，这句话本身就不成立。

这里要区分两种后果，中文教程里经常混为一谈：

• 把identifier_exists错填成no：官方措辞是“将收到警告”，不是立刻拒登。
• 提交了不正确的标识符：官方措辞是“您的商品可能会被拒登”。
• 被判定为“商品标识码不正确”：这条明确写了拒登，直到补上为止。

换句话说，最危险的不是留空，是填了一个错的。这跟大多数人的直觉正好相反——很多人觉得随便填点什么总比空着强，实际情况是空着只挨一句警告，填错了直接下架。

自有品牌到底该填no还是干脆留空？

这是自有品牌卖家最常问的一句，也是被误导得最狠的一句。

先把identifier_exists的真实语义摆出来。Google对这个属性的官方定义说得很清楚：只有在你确定商品没有任何可用的唯一商品标识码时，才能把它设成否。而所谓唯一商品标识码，按Merchant Center对唯一商品标识码的说明，是由GTIN、MPN、品牌这三个属性共同构成的。

三个，不是一个。

所以identifier_exists = no的意思，从来不是“我没有条码”，而是“条码、厂商零件号、品牌，我一样都没有”。一个有自己LOGO、有型号、有品牌注册的自有品牌卖家，去勾这个选项，等于在系统里说自己是三无产品。Google那边看到的是一组自相矛盾的数据：品牌栏填得好好的，却声称没有任何标识符。

官方给出的、可以合理填no的场景其实只有两类，英文原文列得很具体：一类是定制或独一无二的商品，比如定制T恤、艺术品、手工制品；另一类是GTIN制度出现之前的老东西，比如老货、古董、1970年前出版的书。

那自有品牌该怎么填？gtin留空，brand和mpn填满，identifier_exists不动。这样系统读到的是“这件商品用品牌加厂商零件号来识别”，逻辑自洽，不会报矛盾。

但这只是权宜之计。品牌加零件号这套组合的问题在于，它是你自己家的语言。别人家的目录里没有你这套编号，跨渠道对不上，等于每一个渠道都要重新认识你一次。真要长期做，还是得去GS1申请一段属于自己的厂商识别代码，申请流程和材料清单在这篇里写过，走完大概两到四周。

同款不同色，能共用一个码吗？

不能。这句话说了很多年，但落到具体怎么做，还是有人搞混。

GS1的分配规则是一物一码，不同规格、不同包装、不同颜色尺码，厂商分配的本来就是不同的码。红色M码和黑色L码是两件商品，各有各的号。共用一个码不只是不规范，是让Google无法区分你的两件商品，比价的时候会把它们当成同一件来算。

结构化数据这一侧的要求也是配套的。按Google对商品款式结构化数据的规定，商品组必须有一个唯一ID，用productGroupID或者变体上的inProductGroupWithID声明；而每一个款式“在对应的结构化数据标记中都必须具有唯一ID，例如使用sku或gtin属性”。

注意官方这里说的是sku或gtin，两个都行。所以变体层的唯一性不是非要靠条码不可，用你自己的SKU也能满足。但这两条路的效果差得远：SKU只在你家系统里有意义，gtin才能让别人家的机器认出这是同一件东西。

预算有限的时候有个折中办法：给销量前20%的变体买独立的码，剩下的用SKU撑住结构。页面JSON-LD的具体写法和各平台字段差异另有一篇写得比较细，这里不重复。

页面上那几个标识符字段，各自管什么？

前面说的都是feed那一侧。页面的结构化数据里还有一组对应的字段，不少人以为要在它们之间二选一，其实它们是四个平行的属性，有哪个填哪个。

把schema.org官方词汇表拉下来查一遍就很清楚：gtin、mpn、sku三个的定义完全对称，都允许挂在Demand、Offer、Product上，值的类型都是文本；brand的取值类型是Brand或Organization，所以它必须写成一个对象，写成裸字符串是不合规的。

sku那一行值得单独说。它看着最没技术含量，却有个很多人不知道的用途。Merchant Center对结构化数据属性与值的官方说明里写着：“建议在每个注释中提供SKU（ID id属性）或GTIN（gtin属性）。如果您未提供此信息，您着陆页上的商品可能与您的结构化商品数据不匹配。”它是页面和feed之间的那把对齐钥匙——feed里那个id，就是页面上这个sku。

同一份文档里还有两条约束，比字段本身更容易被忽略。第一条是关于生成方式的：“结构化数据标记必须包含在从网络服务器返回的HTML中。页面加载后，将无法使用JavaScript生成结构化数据标记。”第二条是关于取值的：“结构化数据必须与客户所看到的值一致。在商品着陆页上提供不正确的数据属于违反Web开发者指南的行为。”

第一条直接判了一类常见做法的死刑：装一个应用，让它在页面加载完之后往DOM里塞一段JSON-LD。你在浏览器里看得见，Google那边不认。

没有GTIN的时候，那一栏怎么处理？

直接不写。别写空字符串，别写N/A，更别把MPN复制一份塞进去。空值会触发校验错误，假值是编造标识符，两条都比缺字段严重。

还有一件事容易想当然：identifier_exists在schema.org里根本没有对应属性。把词汇表1676个属性翻一遍，没有这个名字——它是Merchant Center feed独有的字段。页面上没办法、也不需要声明“我没有条码”，缺就是缺。某个属性到底能不能挂在某个类型上，有个离线核对的办法，另一篇里写了。

最后是一致性：页面schema里的gtin、mpn、sku必须和feed里的值完全一致。多语言站点尤其容易翻车，一个语言版本改了另一个没跟上，两边就开始互相打架。

GTIN对GEO到底有什么用？

到这里，前面所有关于位数、校验位、开关的话题，才终于连到一起。

Merchant Center那份文档里有一句话，是整件事的地基：制造商会为每种商品指定唯一商品标识码，因此，如果您销售的商品与其他零售商的相同，那么商品的唯一商品标识码也会相同。

这句话读起来平平无奇，但它定义了GTIN在生成式引擎优化里的全部价值。GTIN不是一个用来给你的商品打分的信号，它是一把钥匙，用来判定“你这个商品”和“别处那个商品”是不是同一件东西。

这件事在AI推荐商品的场景里格外要紧。同一个SKU，可能同时躺在你的独立站、亚马逊、几个地区经销商、两三个比价站的目录里。机器要判断这件商品值不值得推荐，会去看它的评论数、评分、价格区间。有统一的GTIN，这些分散在各处的信号才能合并成一个实体的证据；没有，机器眼里就是五六件各自只有零星几条评论的可怜商品，哪一件都不够格被推荐。

更微妙的是，这把钥匙是双向的。同一个机制，往一个方向用，是把好评归拢起来；往另一个方向用，就是前面那条拒登规则——Google之所以能反驳你的“我没有GTIN”，靠的正是它对这个品类里其他商品的认知。能替你聚合信号的那套逻辑，同时也是能戳穿你的那套逻辑。

这算实体消歧，还是别的什么？

圈子里习惯把这件事叫实体消歧，方向没错，但两个概念被合在一起用了，分开看更有指导性。

实体消歧解决的是“一个名字对应好几个候选，该选哪个”——小米是公司还是谷物，苹果是水果还是那家公司。那是文本侧的问题。GTIN干的是另一件事：你官网、亚马逊、经销商站、比价平台上那五条记录，本来就没有歧义，没人搞不清它们各自是什么，问题在于引擎不知道它们是同一件东西。把多条记录合并到同一个现实对象上，这在学术上叫实体归并，是数据侧的问题。

这个区分有实操价值，因为两者的可控性差得远。

GEO里大部分实体工作是概率性的：你写sameAs、建各种条目、让第三方一致地提你的品牌名，引擎把这堆弱信号加权，最后给一个置信度。你能施加影响，但保证不了结果。GTIN是确定性的——字符串精确匹配，要么对上要么对不上，没有打分也没有模糊地带。在这个到处是概率的领域里，能拿到一把硬主键属于稀罕事。

所以它的性价比高得有点不讲道理。同样的人力，补GTIN覆盖率是确定收益，做品牌实体建设是概率收益，先做哪个不用犹豫。

但也别指望它包打天下。品牌层的组织信息、社媒与百科条目之间的对应关系，GTIN一点都管不到；属性层的规格参数、型号名在各处内容里的表述是否一致，它同样管不到。它的主场只有中间那一层：商品与SKU。

顺便说个反面例子。OpenAI早期做ChatGPT购物时，商品信息有相当一部分是靠抓取零售商网站得来的，结果就是库存和运费经常不准，沃尔玛那边对这套体验的抱怨很直接。抓取之所以不准，本质上就是因为缺一把能把两边对上的钥匙——页面上写的和数据库里存的，机器没办法确认是同一件商品。

ChatGPT的feed规范里，gtin并不在必填清单上

这一节要泼一点冷水，因为中文圈里关于这件事的说法大多不准确。

常见的说法是：AI购物的feed有一套pass/fail前置检查，缺必填字段的商品会被静默丢弃，所以GTIN是生死线。前半句对，后半句错。

翻开OpenAI公布的商品feed规范，必填字段一共九个：item_id、title、description、url、brand、seller_name、image_url、availability、price。gtin不在里面，它是可选字段。规范里对它的要求是“exactly 8, 12, 13, or 14 digits, including a valid check digit”，保留前导零，不带空格和短划线，而且明确说明它标识的是具体商品而不是变体组。

两套规范放在一起对照，能看出不少东西：

所以别把Merchant Center那套字段名照搬过去，两边不是一回事。评论字段尤其容易搞错，OpenAI那边叫review_count和star_rating，而且规范要求这两个必须配对出现。

那GTIN在这套体系里到底算什么？它不是准入线，是消歧线。没有它，你的商品照样能进feed；但进去之后，它是一个孤零零的条目，没法跟任何外部证据挂上钩。关于ChatGPT购物推荐从哪里取数、query fan-out怎么把一句话拆成多条意图，之前那篇拆得比较透，可以对着看。

结账那半边停了，发现这半边反而更值钱

2026年3月，OpenAI宣布把站内结账迁到apps里去，重心转回ChatGPT内部的商品搜索与发现。这个转向的背景不太好看：用户在对话里问了大量商品问题，但很少在里面完成购买。沃尔玛测出来的数字是，ChatGPT站内结账的转化率比跳回自己网站差大约三倍。

这件事对做电商的人有个直接推论：别把资源压在agentic checkout上。成交那半边现在是停滞的，而发现那半边活得好好的，并且因为结账退场，它反而成了AI购物里唯一还在跑的环节。

发现环节的全部输入是什么？就是feed，加上页面上机器能读到的东西。这也是为什么保哥这两年给客户做电商SEO诊断时，越来越多的问题最后都指回商品数据本身，而不是页面标题写得好不好、外链够不够。

顺带提醒一句页面这一侧：产品页JSON-LD里的gtin，要和feed里提交的那个值完全一致。两边不一致比只有一边更糟——只有一边是信息不全，两边打架是信息可疑，机器对后者的处理方式通常是两个都不信。

哪些AI问题里，GTIN一点忙都帮不上？

这一节是给自己泼的第二盆冷水，也是我觉得最该讲清楚、却几乎没人讲的一件事。

GTIN起作用的前提，是这次对话里存在一个确定的商品实体。用户说“帮我看看Anker那款737充电宝现在多少钱”，或者“这三款扫地机器人哪个吸力大”，机器要去目录里取具体条目，这时候能不能把你的商品和别处的同款对上，直接决定你出不出现。

可用户也会这样问：“露营用的手电筒怎么挑，需要注意什么”。这句话里没有任何一个可以落到商品条目上的东西。机器这时候要找的是解释、是对比逻辑、是使用经验，它去引用的是评测文章、论坛讨论、品牌自己的内容页。你的feed修得再干净，在这类问题里的权重是零。

怎么快速分辨这两类问题？看那句话里有没有能唯一指向一件商品的锚点：品牌加型号、一组具体参数、一个明确的价格带、某个具体的使用场景加具体的规格要求。有锚点的走目录，没锚点的走内容。

这个分界带来的实际后果是，商品数据和内容这两条腿得分开算账，也得分开投人。保哥见过的一种典型误判是：某个客户把GEO预算几乎全压在feed治理上，半年后确实在比价类问题里露脸多了，可品类教育类的问题一条都没进去——因为那半边根本没人写。

反过来的误判也有，而且更常见：内容团队写了一堆选购指南，商品数据那边条码乱七八糟，结果用户看完AI推荐的指南想买，机器却指不出他家的具体商品。

还有一种情况比信息型问题更隐蔽：商品是同一件，名字却裂开了。官网叫“XX Pro二代”，包装盒印的是“XX Pro II”，亚马逊listing写成“XX Pro 2升级版”，评测视频和论坛里大家一律简称“XX Pro”。GTIN能把feed层面那几条记录焊死在一起，可当用户在对话里问“XX Pro二代比一代强在哪”，机器去检索的是文本语料，那四个名字是不是同一个东西，GTIN根本没参与。

所以型号命名的规范化是跟GTIN并行的另一件事，谁也替代不了谁。见过最常见的失误是市场部改了产品叫法，旧内容和经销商物料没同步，一个型号在语料里裂成三个实体，彼此谁也不认识谁。

一次把自己站上的商品编号盘清楚

说了这么多，落到能动手的事情上其实不多，一个下午够了。

第一步，把feed导出来，跑一遍位数和校验位。下面这段脚本不依赖任何第三方库，直接能跑：

def check_digit(body):
    s = 0
    for i, ch in enumerate(reversed(body)):
        s += int(ch) * (3 if i % 2 == 0 else 1)
    return str((10 - s % 10) % 10)

def audit(code):
    c = code.strip().replace(' ', '').replace('-', '')
    if not c.isdigit():
        return '不是纯数字，多半填了SKU'
    if len(c) not in (8, 12, 13, 14):
        return '位数不合法：%d位' % len(c)
    if check_digit(c[:-1]) != c[-1]:
        return '校验位对不上'
    c13 = c.rjust(13, '0')
    if c13.startswith(('02', '04', '2')):
        return '落在受限号段，不能提交'
    if c13.startswith(('05', '98', '99')):
        return '落在优惠券号段，不能提交'
    if len(c) == 8:
        return '注意：8位码请确认是GTIN-8而不是没展开的UPC-E'
    return 'OK'

最后那条提示是这次实验的直接产物。8位码是唯一一类机器帮不了你的情况，只能人去确认它到底是GS1分配的GTIN-8，还是从UPC-A压缩来的UPC-E。判断办法也简单：问供应商要商品包装上那个完整的12位码。

第二步，把UPC-E展开成UPC-A。规则按末位数字分档：末位0、1、2的，取前两位数据加末位再补4个零再接剩下三位；末位3的，取前三位加5个零加剩下两位；末位4的，取前四位加5个零加最后一位；末位5到9的，取前五位加4个零再把末位接回去。展开完重算校验位，别沿用原来那一位。

第三步，检查identifier_exists有没有被误设。重点看这三类商品：

• 用了本地化插件、字段被自动翻译过的；
• 从别的平台批量迁移过来、迁移工具默认给了false的；
• 自有品牌，当初找不到GTIN顺手勾上的。

第四步，看变体层。母款有码、变体没码是最常见的形态，也是最容易被忽略的——因为Merchant Center不会为此报错，它只是安静地把你的几十个变体当成几十件互相独立、彼此陌生的商品。

站在Shopify上的话，这个字段藏在哪？

不用建元字段，Shopify原生就有，只是不叫GTIN。位置在变体层的库存区块，那一栏写着“条形码Barcode (ISBN, UPC, GTIN, etc.)”。Google与YouTube销售渠道会把变体的条形码直接映射成feed里的gtin，没有别的来源——这一栏空着，feed里的gtin就是空的。

注意它在变体层不在商品层。不同尺码颜色各填各的，只在父级填一个不算数。

这个字段刚刚变过，就在2026年9月8日。Shopify的变更日志说，变体现在最多支持20个条形码，每个可以指定类型，UPC、EAN、ISBN、GTIN、ASIN都能选，也支持自定义类型放内部编号；选了类型之后，Shopify会按那个标准的格式校验数值，输入时就能抓到打字错误。商品CSV里对应的列名是Variant Barcodes，第一个条形码在只需要单个条形码的场景里继续使用，向后兼容。

这条变更之前，那一栏是完全不做校验的——填字母、填内部编号都不报错，于是不少店把它当成了第二个SKU用，直到feed同步过去才发现全是废号。如果你的店还没拿到这次更新，自己写条规则先过一遍：长度是8、12、13或14位，且全是数字。

另外两个字段的对应关系也顺带说清楚：brand映射的是vendor，很多店铺那一栏填的是供应商名字或者干脆留空，这是Shopify站在Merchant Center里被拒的常见原因之一；mpn则没有原生字段，要建一个商品元字段，再在feed应用里映射过去。

最后提醒一句：条形码填了，不等于产品页的结构化数据里就有gtin，那是两套数据。而且按前面引过的那条官方要求，标记必须包含在服务器返回的HTML里，靠应用在页面加载后用JavaScript塞进去的那一段，Google不认。

这四步做完，再去谈GEO的其他动作才有意义。商品身份都没对齐的时候，内容写得再好，机器也不知道你在说哪一件东西。

常见问题解答

UPC和GTIN到底是什么关系？

UPC是GTIN的一种格式，不是并列的两样东西。GTIN是统称，涵盖UPC、EAN、JAN、ISBN、ITF-14五种，分别对应北美、欧洲、日本、图书和整箱包装。所以Merchant Center里没有UPC字段，只有gtin，手上有UPC直接填进去就是正确做法。

8位的条码能直接填进gtin吗？

要看它是什么。GS1分配的GTIN-8可以直接填，从UPC-A压缩来的UPC-E必须先展开成12位。麻烦的是两者位数一样，系统分不出来。实测200万个UPC-E码，58%直接提交能通过校验位验证，末位是5到9的更是100%全过，一点报错都不会有。所以拿到8位码时，最稳妥的办法是问供应商要包装上那个完整的12位码。

identifier_exists填no会不会被拒登？

分两种情况。单纯把它错填成no，官方的处理是发一条警告；但如果Google判定你这个品类的商品本来就该有GTIN，问题会升级成“商品标识码不正确”，后果是拒登，直到补上为止。另外要注意这个字段只收英文值，yes、true、no、false四个，中文的“否”不管用。

手上只有MPN，能填进gtin那一栏吗？

不能。MPN多半带字母和横线，位数也不对，填进去通常直接报invalid value [gtin]。真正麻烦的是万一它恰好是纯数字、位数又正好，校验位有7%的概率侥幸通过，那你就提交了一串属于别人产品的GTIN，性质从信息不全变成了编造标识符。正确做法是填进mpn字段并补上brand，identifier_exists保持缺省的true。代价是缺GTIN会收到“因缺少值而导致效果受限”的提示，商品照常投放但覆盖面打折。

Shopify里的GTIN字段在哪，需要建元字段吗？

不用建，原生就有，只是不叫GTIN。它在变体层的库存区块，那一栏写着“条形码Barcode (ISBN, UPC, GTIN, etc.)”，Google与YouTube销售渠道会把它直接映射成feed里的gtin。2026年9月8日Shopify更新过这个字段：一个变体最多能放20个条形码，每个可以指定UPC、EAN、ISBN、GTIN、ASIN等类型，选了类型之后Shopify会按该标准校验格式，CSV里的列名是Variant Barcodes。真正需要建元字段的是mpn，Shopify没有原生字段。

自有品牌没去GS1申请过码，该怎么填？

gtin留空，brand和mpn填完整，identifier_exists不要动。填no是错的，因为这个开关的真实含义是条码、厂商零件号、品牌三样都没有，而你至少有品牌。长期看还是建议去GS1申请自己的厂商识别代码，品牌加零件号这套组合只在你自己家的系统里通用，跨渠道对不上。

同一件商品在亚马逊和独立站要用同一个GTIN吗？

要，而且必须是同一个。GTIN由制造商分配，同一件商品在哪里卖都是同一个号，这正是不同零售商的目录能对上的原因。给同一件商品在不同渠道分配不同的码，等于亲手把本该合并的评论、评分、价格信号拆成互不相干的几堆。

结构化数据里的gtin和feed里的对不上会怎样？

比只填一边更糟。只填一边是信息不完整，两边不一致是信息互相矛盾，机器通常的处理方式是两个都不采信，页面和feed的可信度一起下降。所以改任何一边的时候，另一边要同步改。

权威参考资料