How Many GTINs Can a Product Have? Google Accepts 10

Shopify changed something small this month that most merchants will read as pure relief. A product variant can now hold up to twenty barcodes instead of one, so an item selling under a manufacturer code, a private-label code and a marketplace code can finally carry all three in the same record. On first read I assumed Google would only ever take one of them back, and that assumption was wrong in a way worth writing down, because it points at the wrong culprit.

Google accepts up to ten barcode numbers per product. A Shopify variant now stores twenty and forwards the first one, so the limit everyone assumes sits at Google actually sits in the export.

How many barcodes does Google actually accept?

Ten, per product, and Google states it plainly rather than leaving it to be inferred. The help page for the barcode attribute carries the line “Repeated field: Up to 10” alongside the worked example, which is a product holding both a retail barcode and a book number: “For a product that has a UPC and an ISBN-13, submit the GTIN [gtin] attribute twice, once for each value.”²

A word on the vocabulary, since three acronyms travel together here and they are easy to blur. GTIN is the Global Trade Item Number, the umbrella term for the numbers under a barcode. UPC is the twelve-digit version used across North America, EAN the thirteen-digit European one, and ISBN the book equivalent. They are all GTINs, which is exactly why a single product can legitimately carry several at once.

That ceiling holds through every way of submitting a feed, which is the part I expected to find a catch in and did not.

Does Google accept multiple GTINs in a feed file, or only in the interface?

Both, and only the syntax differs. Google documents three shapes for submitting more than one value in a repeated field.³ An XML feed repeats the attribute, once per value. A Google Sheet or a tab-delimited file either separates the values with a comma and no space, or gives each value its own column.

One line made this genuinely ambiguous for me before I checked, and it sits on a different page from the repeated-field note, which is part of why.

The product data specification’s entry for this field reads “Max 50 numeric characters (max 14 per value),” which sounds like it might be describing a single field with room to spare.⁴ It is describing a per-value cap inside a flat file, and fifty characters across fourteen-digit values is exactly the shape of a field meant to hold several.

Reading that line alone, without the repeated-field note beside it, is how you end up believing Google wants one.

Where does the number of barcodes drop from twenty to one?

The drop happens at the export, and Shopify says so in the same announcement that adds the twenty slots: the first barcode still feeds channels and integrations by default.¹ Twenty values go into the product record and one comes out to any connected channel, which makes the narrowing a platform default and not something Google asked for.

Nothing about that is hidden, and it reads as a sensible default for a platform that had one barcode field yesterday and cannot guess which of your new twenty matters most to a given channel. The consequence still lands on the merchant, because a decision that used to be explicit has quietly become positional.

Consider what that means for a product genuinely carrying three identifiers. Yesterday you picked one for the barcode field and knew you had picked it. Today you record all three, feel more complete than you did, and ship whichever happens to sit first in the list. The completeness is real. The control got weaker.

Why does the wrong identifier cost anything?

A barcode number is how a retailer’s listing gets connected to the same product sold elsewhere, so sending the wrong one breaks a join nobody sees fail. Google’s own guidance explains why in one line: these numbers are assigned by the manufacturer, so “if you sell the same product as another retailer, the UPIs will be identical.”⁵

Send the manufacturer’s code and you land on that shared number. Send your own private-label code and you are, as far as matching goes, selling something that exists nowhere else. Send a marketplace code, which is not a global trade number at all, and the product arrives with nothing to match on.

Google states the consequence carefully rather than promising one, saying a product that has an assigned barcode number but is submitted without it “may have limited visibility.”⁵ None of the three is invalid and all three pass a format check, so a feed audit looking for validity finds nothing wrong.

The same shape turned up earlier this month in a DoorDash research paper, whose catalog agent searches for a barcode first when confirming a product match and then treats that barcode as explicitly optional proof. Seen from the buyer’s side, that is the same gap. A merchant forwarding one arbitrary identifier out of twenty is the same gap from the seller’s.

What barcode ordering is worth checking this week?

Look at which barcode sits first, on the products where you now record more than one. That ordering is doing work it was never designed for, and it is the cheapest thing on this list to verify.

Then decide deliberately, per channel, which identifier you want matched. The manufacturer’s number is usually right for a resold product, because it joins the listing to everything else selling the same item. Where the product genuinely is yours alone, a private-label number is the right one. What you should avoid is the third case, where nobody chose and the answer is whichever number a colleague happened to key in first.

Finally, treat the twenty slots as a record-keeping win and not a distribution one. Storing every identifier a product carries is genuinely useful for reconciliation, returns and marketplace work. It does not, on its own, change what any channel receives, and the announcement does not claim it does.