GTIN, brand, and identifiers in structured data: getting matched by Google and AI

Google, Bing, and AI shopping agents don't recognize a product by its title — they recognize it by its identifiers. When the GTIN, MPN, and brand in your page's structured data are missing, malformed, or inconsistent with your Merchant Center feed, the product effectively becomes anonymous: matched loosely by name if at all, or not matched at all. This guide covers where those fields belong in Product structured data, the format rules that trip teams up, and how to confirm the markup is actually reaching Google's parser.

Why identifiers decide the match

GTIN (Global Trade Item Number), MPN (Manufacturer Part Number), and brand are what Google calls unique product identifiers (UPIs). They're the join key between three separate things: your on-page structured data, your Merchant Center product feed, and GS1's global registry of manufacturer-issued barcodes. When all three agree, Google can confidently attribute reviews, pricing history, and availability signals to the correct SKU — and increasingly, so can AI agents that lean on the same structured data and feeds to compare products across retailers.

When identifiers are missing or wrong, the failure mode isn't a warning label — it's silence. Google's guidance is direct that GTINs should never be invented: "Only provide a GTIN if you are sure it is correct. When in doubt do not provide a GTIN" (GTIN attribute spec). A guessed or reused GTIN is worse than no GTIN, because it actively mismatches your product to someone else's listing, reviews, or price history.

The three fields, and the schema.org properties behind them

In JSON-LD, these map to specific Product properties, not free text:

• gtin, or the digit-specific variants gtin8, gtin12 (UPC), gtin13 (EAN/JAN), gtin14 (ITF-14 for cases/multipacks) — all Text type, numeric digits only.
• mpn — the manufacturer's part number, required as a fallback when a product genuinely has no GTIN.
• brand — a Brand object (or a plain string, though the object form is preferred), naming the manufacturer or house brand, not the retailer.

Google is explicit that GTIN values must be plain digits: "Make sure the GTIN value is in the numerical form; we don't support the URL form for GTINs" (no https://gtin.info/... links, no formatting characters left in). A minimal example, built from the field names and value formats Google's own merchant-listing documentation uses, looks like this:

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Nice trinket",
  "sku": "trinket-12345",
  "gtin14": "00012345600012",
  "mpn": "925872",
  "brand": {
    "@type": "Brand",
    "name": "ACME"
  },
  "image": ["https://example.com/photos/1x1/trinket.jpg"],
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/trinket",
    "priceCurrency": "USD",
    "price": 39.99,
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  }
}

name, image, and offers are the properties Google actually requires for merchant listing eligibility. GTIN, MPN, brand, and SKU sit in the recommended tier — but "recommended" undersells it: Google's own product data blog post frames identifiers as the mechanism for matching and verifying listings across Search and Shopping, and pages without them are markedly harder to attribute correctly, especially for branded products sold by more than one retailer.

When there's genuinely no identifier

Not every product has a GS1-issued barcode — custom, handmade, or made-to-order items often don't. For the Merchant Center feed side, Google provides identifier_exists (set to false) so you're not penalized for a legitimate absence rather than a data gap. On the structured-data side, there's no direct JSON-LD equivalent of identifier_exists; the practical approach is to omit gtin and mpn entirely rather than submit an empty string or a fabricated value, and make sure brand and a well-formed sku are still present so the product isn't identifier-less across the board.

Keep the page and the feed telling the same story

If you run a Merchant Center feed alongside on-page structured data, Google explicitly recommends doing both together: providing structured data on the page and a feed in Merchant Center maximizes eligibility for rich experiences and lets Google cross-check one against the other. The failure pattern worth watching for is drift — a feed updated with a corrected GTIN or MPN while the PDP template still renders an old or blank value in JSON-LD. Google treats mismatches between feed and structured data as a verification failure, not a tiebreak, so the stale side effectively cancels out the correct one.

Common gaps that quietly break discovery

• GTIN in URL form instead of digits (a leftover from copy-pasting a barcode lookup link).
• Wrong digit count — a 13-digit EAN submitted as gtin12, or a checksum digit dropped during a CSV export.
• Reused or invented GTINs, most often when a retailer sets up a private-label SKU and pastes in a competitor's barcode as a placeholder.
• Brand set to the retailer's name instead of the manufacturer — this breaks matching for multi-retailer branded products specifically.
• Variant-level gaps — a parent product has a GTIN but color/size variants inherit a blank or duplicated one, which is exactly the case Google's product variant guidance calls out separately.

Any one of these is enough to push a product back into "unverified" territory, where AI shopping agents and Google's own matching logic fall back to fuzzy title/price comparison — noticeably less reliable than an identifier match.

How to validate

• View-source vs. rendered DOM: search view-source for "gtin and "mpn — if they're absent in view-source but present in the rendered DOM, they were injected client-side and may not be visible to crawlers that don't execute JS. Compare against the browser's Elements panel to confirm.
• curl the raw HTML: curl -s https://example.com/product/sku-123 | grep -A2 '"gtin' confirms exactly what a non-JS fetcher sees, which is closer to how many AI crawlers and comparison agents ingest pages.
• Rich Results Test: run the URL through Google's Rich Results Test to confirm the Product block parses without errors and that gtin/mpn/brand are recognized fields, not silently dropped for a typo in the property name.
• Merchant Center's "Needs attention" tab: for feed-connected catalogs, check the Needs attention section under Products (the successor to the older Diagnostics tab in Merchant Center Next) for item-level GTIN warnings — a mismatch here usually means the feed and the on-page JSON-LD have drifted apart.

Verified as of July 2026 against Google Search Central's Product structured data and merchant-listing documentation and Google Merchant Center Help.

None of this matters if the underlying data isn't there to put in these fields in the first place — plenty of catalogs are missing GTINs, have inconsistent brand naming, or never had MPNs recorded at all. That's the enrichment problem Anglera is built to solve: it fills in and standardizes identifiers, attributes, and specs across your catalog on an ongoing basis, sitting on top of whatever PIM or commerce platform already holds your product data. Once that data is accurate and complete, the structured-data implementation above is what turns it into something Google and AI agents can actually match.

Sources:

• GTIN attribute — Google Merchant Center Help
• Product structured data (merchant listing) — Google Search Central
• Intro to Product structured data — Google Search Central
• Providing better product information for shoppers — Google Search Central Blog
• Identifier exists [identifier_exists] — Google Merchant Center Help
• The Needs attention tab — Google Merchant Center Help