没有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%在真实世界里的样子。

说自己没有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的具体写法和各平台字段差异另有一篇写得比较细，这里不重复。

GTIN对GEO到底有什么用？

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

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

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

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

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

顺便说个反面例子。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推荐的指南想买，机器却指不出他家的具体商品。

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

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

第一步，把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不会为此报错，它只是安静地把你的几十个变体当成几十件互相独立、彼此陌生的商品。

这四步做完，再去谈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四个，中文的“否”不管用。

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

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

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

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

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

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

权威参考资料