GTIN, MPN, SKU, and Brand Markup: Choosing Product Identifiers

Scope and expected behavior

This rule document covers GTIN, MPN, SKU, and Brand Markup: Choosing Product Identifiers inside Product Ecommerce and Merchant Markup. The acceptance boundary is narrow: decide whether this exact entity, property, or workflow is correct on the public page without turning adjacent schema topics into the same rule. The expected state must be observable in rendered HTML or in the public search-facing page, not only in a CMS field, plugin setting, or source template.

Google documents this topic as part of structured data or a related Search feature. Eligibility still requires accurate visible content, crawlable pages, valid implementation, and compliance with feature-specific and general structured data guidelines; display is never guaranteed.

Before changing code, write down the page class, canonical URL, locale, visible source of truth, expected structured-data node, and the system that emits it. Include one valid control page and one edge case. This makes the later PASS/FAIL result about a known behavior instead of a generic validator score.

Data model and evidence to capture

The high-value fields for this topic are gtin, mpn, sku, brand, identifier uniqueness, variant identity. They are not equally important in every feature, but each one should have an explicit source of truth. Store the rendered value, the visible value it describes, the owning application field, and the validation result in the same evidence row.

url,entity_id,property,rendered_value,visible_value,generator,validator,decision
https://example.com/page,#entity,property,value,value,template-v3,checked,PASS

Treat the page, entity, and generator as three separate layers. A valid field in a CMS is not proof that the same value reaches rendered HTML, and rendered HTML is not proof that the value is semantically true.

For nested entities, preserve @id references and parent-child relationships. For values that can change quickly, such as price, availability, job status, event time, or opening hours, also record the crawl timestamp and the business/feed source timestamp. A syntactically valid stale value is still wrong.

Technical diagnosis

Fetch the public URL rather than reading only the application database. Extract every application/ld+json block, parse each block as JSON, and inventory the top-level and nested @type, @id, URL, and topic-specific properties. If the site also emits Microdata or RDFa, include those formats in the inventory so two generators cannot silently describe the same entity differently.

A practical command-line capture can start with:

curl -sS -L --compressed https://example.com/page > page.html
python -m json.tool example.json >/dev/null

The second command is only a syntax check for an extracted JSON object; it does not establish Search eligibility. After parsing, compare the structured values with visible content and with the feature documentation. If a property is optional, do not convert a warning into an error simply because an audit tool lists it.

For GTIN, MPN, SKU, and Brand Markup, explicitly inspect gtin, mpn, sku, brand, identifier uniqueness, variant identity. If the value is generated by a shared template, test at least one other page using the same template. If it is generated by product, event, job, or profile data, compare the structured value with the authoritative record rather than with another derived copy.

Implementation pattern

A minimal topic-oriented JSON-LD example is shown below. It is intentionally incomplete where the feature documentation requires additional properties; copy the modeling pattern, not the sample business data.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "gtin": "0123456789012",
  "mpn": "MPN-1001",
  "sku": "SKU-EXAMPLE-01",
  "brand": "example"
}

Implementation should happen at the smallest reliable source: product model, article template, organization settings, event record, locale transformer, schema graph builder, or server-rendered component. Avoid per-page string patches when the same defect is produced by a shared generator. Preserve stable entity identity across deployments so other nodes can continue to reference the same real entity.

When a field is absent because the business or page genuinely has no such information, omit it rather than inventing a placeholder. Empty strings, copied defaults, fabricated reviews, guessed coordinates, and generic “example” values are worse than a deliberate omission because they create a false machine-readable claim.

Topic-specific failure modes

For this topic, test these failure classes separately:

1. Presence failure: the expected node or property never reaches the rendered public page.
2. Value failure: markup exists but gtin or a related value disagrees with visible content or the authoritative record.
3. Identity failure: two nodes describe the same entity with different @id, URL, name, or identifiers.
4. Eligibility failure: markup is valid Schema.org but the page does not satisfy the Google feature boundary or policy.
5. Freshness failure: cached markup lags behind a price, availability, date, role, location, or status change.
6. Template failure: the generator leaks the same values onto page types where the entity is not actually present.

Do not “fix” a page by adding every recommended property. Required and recommended properties are feature-specific, and even a fully valid object does not guarantee a rich result. The repair should remove the factual or technical mismatch that the evidence actually proves.

Edge cases and when not to change markup

A page can contain several legitimate entities and several JSON-LD blocks. Multiple blocks are not an error by themselves; conflicting descriptions of the same real entity are the problem. Likewise, a warning about a recommended property is not equivalent to an invalid item, and a Schema.org property without a standalone Google rich result can still be useful to other consumers.

Localized pages can translate human-readable text while keeping the same real-world entity identity. Product variants can share a group identity while retaining unique variant identifiers. Article authors can point to stable profile pages. Events, jobs, products, and business profiles can become stale quickly and therefore need stronger freshness controls than evergreen organization data.

If the current markup is accurate but the feature is unavailable, deprecated, limited to a different site class, or not guaranteed to display, the correct action can be no markup change. Document the eligibility boundary and remove misleading internal expectations instead.

Verification and regression test

Re-fetch the same public URL after deployment and compare the extracted node against the saved baseline. Run a generic Schema.org/syntax check, then the Google feature-specific test or Search Console report only when the feature is actually supported there. Verify that values remain visible to users and that canonical, robots, noindex, authentication, or rendering changes have not made the page inaccessible.

For repeated templates, sample the original failure, one known-good control, one intentional exception, and one additional page from the same generator. For data that changes over time, repeat the check after a real data update so you know the structured layer follows the source automatically rather than only after a manual cache purge.

PASS / FAIL criteria

| Check | PASS | FAIL | | --- | --- | --- | | Public output | expected node and values are present in rendered output | data exists only in CMS or source code | | Semantic match | gtin and related values describe visible reality | markup contradicts page or authoritative record | | Identity | stable IDs and URLs describe the same real entity consistently | duplicate/conflicting entity identities are emitted | | Eligibility | feature boundary is understood and documented | valid schema is treated as guaranteed Search appearance | | Freshness | dynamic values update with their source of truth | stale cache or copied values survive changes | | Regression | controls and neighboring templates remain correct | the fix creates new schema on unrelated pages | | Evidence | another reviewer can reproduce the result | PASS depends on an unexplained tool score |

1. Define the page class, entity, locale, canonical URL, and expected GTIN, MPN, SKU, and Brand Markup behavior.
2. Extract rendered structured data and record gtin, mpn, sku, brand together with the owning generator.
3. Parse JSON syntax separately from Schema.org semantics and from Google feature eligibility; do not collapse these checks into one score.
4. Compare every material value with visible page content and the authoritative application/business source.
5. Test one known-good control and one intentional edge case before changing a shared template or graph builder.
6. Implement the smallest source-of-truth fix; omit unavailable data instead of inventing placeholder values.
7. Re-fetch the public page, repeat the same extraction and applicable Google test, then sample neighboring templates/locales for regression.
8. PASS: public markup is syntactically valid, semantically true, correctly scoped to the feature, fresh, reproducible, and maintained by the proper source.