GTIN and UPC hygiene: the identifier mistakes that delete you from search

A GTIN is not paperwork. It's the key a machine uses to decide whether your listing is the trusted, canonical version of a product or an unverifiable guess. Get identifier hygiene wrong and you don't get a warning banner, you get silence: fewer impressions, quiet disapprovals, and an AI answer engine that recommends a competitor because it could confirm their product and not yours.

What a GTIN actually does for you

A GTIN, EAN, or UPC ties your SKU to a globally registered record that Google, Amazon, Walmart, and increasingly AI shopping agents can cross-reference against manufacturer data, reviews, and price history. Google is explicit that GTIN is required whenever the manufacturer assigned one, and that submitting it correctly is how a product becomes eligible for the full range of Shopping surfaces rather than a stripped-down listing.

When the identifier is missing, wrong, or shared with another item, the machine has two options: reject the listing outright, or accept it with lower confidence and rank it accordingly. Neither is a fair fight against a competitor whose feed resolves cleanly.

Ask an answer engine

Try asking an AI shopping assistant something like: "find me the 9V 700mAh NiMH battery pack rated for two-way radios, in stock, under $15." The engine is going to try to resolve that spec string to a known product record, usually via GTIN or MPN, before it trusts anything else on the page. If your feed has that exact SKU under three different UPCs across three retailers because someone fat-fingered a digit, the engine can't tell if it's looking at one product or three, and it will default to the version it can verify.

The mistakes that actually delete you

Reused GTINs. GS1 eliminated GTIN reuse across all sectors as of January 2019 — once a barcode is assigned to a product, it can never be reassigned to a different item, even after that product is discontinued. Distributors who dust off an old, unused UPC from a discontinued line to save money on a new one are the single most common source of "GTIN exists but doesn't match this product" disapprovals. The database on the other end still has the old product attached to that number, and now two SKUs are fighting over one identity.

Bad checksums. A GTIN's final digit is a checksum computed from the rest of the number. Truncate a leading zero in Excel, transpose two digits during a migration, or copy a UPC-A into an EAN-13 field without padding it, and the checksum fails silently — the number looks plausible but resolves to nothing. Google runs every submitted GTIN through checksum validation, and a failed check reads the same as a missing field.

Retailer-invented identifiers. When a real GTIN is missing, some catalogs backfill with an internal SKU dressed up to look like a UPC. It passes format validation (right digit count) but fails cross-reference, because no registry has ever heard of it. That's often worse than leaving the field blank, since a fabricated number can accidentally collide with someone else's real product.

Bundles and variants sharing one code. A manufacturer-created multipack has its own GTIN; a retailer-assembled bundle should carry the identifier of the primary item, not the case pack code from the warehouse. Mixing these up means a 3-pack and a single unit can end up indistinguishable to a matching engine, or the case GTIN leaks into consumer-facing feeds and gets flagged as invalid.

Format mismatches between MPN and GTIN. MPN is manufacturer-specific and not globally unique; GTIN is. Feeds that treat them interchangeably, or drop MPN because "we already have a UPC," lose a second matching signal that answer engines and marketplaces both use to disambiguate near-identical SKUs, like color or size variants under one parent.

What clean identifier data looks like

The right-hand column isn't aspirational, it's what a distributor's data should look like coming out of a supplier feed, before it ever hits a channel. The gap is almost never "we don't have the number." It's that the number sitting in a supplier PDF or spec sheet never got extracted, validated against checksum rules, and mapped to the correct variant.

Why this is a maintenance problem, not a one-time cleanup

Catalogs don't stay clean. New SKUs come in from suppliers with inconsistent GTIN formatting, variants get added without their own identifiers, and a merge of two supplier feeds routinely creates duplicate GTINs on unrelated products. A one-time audit fixes what exists today; six months later you have a fresh batch of gaps from every SKU added since.

Anglera treats this as ongoing, not a project. It plugs into whatever you already use to store product data, whether that's Akeneo, Salsify, inriver, Stibo, Syndigo, Pimcore, Informatica, or a flat file with no PIM behind it at all — your PIM stores the data, Anglera does the work of extracting identifiers from supplier documentation, validating checksums and format against GS1 rules, flagging duplicates and reused codes, and writing the correct value back to the right variant. Most catalogs can be live on continuous identifier monitoring in about 30 days, starting from whatever export you can produce today. The point isn't to declare identifiers "fixed forever" — it's to catch the next broken GTIN before an answer engine notices it first.

Sources:

• GTIN attribute requirements — Google Merchant Center Help
• How to fix: Incorrect GTIN — Google Merchant Center Help
• Can I reuse barcode numbers? — GS1 UK