Why an invalid GTIN is worse than none
An empty identifier field costs you matching. A wrong one costs you
the offer: it makes a claim about the product's identity that
validators can check, and they do. WooCommerce checks nothing at save
time — no checksum, no length, 123 goes straight in —
so the field can hold garbage for months while every downstream
system quietly rejects it.
- Google disapproves the offer. Merchant Center validates length, characters, checksum and prefix. A code that fails is not ignored — the offer is disapproved and drops out of Shopping until the code is fixed, a harder penalty than the limited performance a missing code gets.
- Marketplaces block the listing. Channels that check a barcode against the GS1 database before they accept an offer reject an invalid code at creation, not after review. A code that fails there stops the listing at the door.
-
The code silently vanishes from your structured data.
When WooCommerce builds the product's JSON-LD, it emits a
schema.org gtin only for codes of 8 or 12 to 14 digits. Anything
else — Excel's
5,90E+12, a nine-digit fragment, a truncated paste — is dropped from the markup without a trace, so the storefront looks fine while rich results see no code at all. - The damage wears familiar disguises. Scientific notation and stripped leading zeros are the classic spreadsheet round-trip. WooCommerce itself contributed one: versions 9.2 through 10.9 cut the trailing X off ISBN-10 codes on save, leaving nine digits that validate as nothing.
How to find invalid GTINs manually
The code is stored in postmeta under
_global_unique_id. SQL can catch the coarse failures —
wrong length and non-digit characters — with a query like this:
wp db query "SELECT p.ID, p.post_title, m.meta_value AS gtin
FROM wp_posts p
JOIN wp_postmeta m
ON m.post_id = p.ID AND m.meta_key = '_global_unique_id'
WHERE p.post_type IN ('product', 'product_variation')
AND p.post_status = 'publish'
AND m.meta_value <> ''
AND (m.meta_value REGEXP '[^0-9]'
OR LENGTH(m.meta_value) NOT IN (8, 12, 13, 14))
ORDER BY p.ID;"
Adjust the table prefix if yours isn't wp_. The query
will also list valid ISBN-10 codes, since they are ten characters
and may end in X — decide per row whether you are looking at a book.
What SQL cannot do is the checksum. A code of the right length made of digits can still be wrong — one mistyped digit fails mod-10, and that is precisely the error Google catches and this query cannot. Checking it means running the GS1 algorithm over every code, every time the catalog changes, which is a script and a habit rather than a query.
How CatalogLift finds it
Every scan reads each product's identifier field and validates it deterministically: the characters, the length, and the full GS1 mod-10 checksum for GTIN-8, 12, 13 and 14, plus the mod-11 check that recognises a true ISBN-10. A code that fails becomes a finding at high severity, and the evidence names the exact failure — scientific notation from a spreadsheet, a length no GTIN has, a checksum that doesn't match — so you know what happened to the code, not just that it is wrong.
There is no AI on this path, and CatalogLift never repairs a code by guessing: a checksum failure says a digit is wrong somewhere, and a “fixed” code that validates could belong to a different product, which is a worse error than the one you started with. You replace the code with the real one from your supplier or the barcode itself, approve it, and CatalogLift writes it to WooCommerce; the next scan verifies the new code passes. Because CatalogLift keeps watching, the next spreadsheet import that mangles a batch of codes surfaces immediately instead of at the next Merchant Center review, and the first scan costs nothing and needs no card.