Why a valid ISBN-10 still disappears
WooCommerce's GTIN, UPC, EAN, or ISBN field says ISBN right on the label, and it stores a ten-character ISBN-10 without complaint. The trouble starts on the way out: when WooCommerce builds the product's JSON-LD it emits a schema.org gtin only for codes of 8 or 12 to 14 digits. Ten characters is none of those, so the code is dropped from the markup without a word — a silent gap with real costs.
- Rich results lose the identifier. The storefront shows the ISBN, but the JSON-LD that Google reads carries no gtin property at all, so free listings and rich results match the book by title and author instead of by its exact edition.
- Feeds and marketplaces want the 13-digit form. Google's product data, a marketplace's barcode validation against the GS1 database and a comparison engine's product matching all speak GTIN — for books, the Bookland ISBN-13 that begins with 978. The ISBN-10 is the same book in a notation those systems don't accept.
- The field looks correct in wp-admin. The code on the screen matches the code on the copyright page, and nothing marks it as a problem — which is why whole imported backlists sit like this for years.
- The right answer already exists. Since 2007 the ISBN-10 and its ISBN-13 are one number in two notations, and the conversion is defined to the digit. This is the rare identifier problem that needs no research — only the arithmetic, applied.
How to find ISBN-10 codes manually
The code is stored in postmeta under
_global_unique_id. An ISBN-10 is nine digits followed
by a digit or X, so the shape is easy to query with WP-CLI:
wp db query "SELECT p.ID, p.post_title, m.meta_value AS isbn
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 REGEXP '^[0-9]{9}[0-9Xx]$'
ORDER BY p.ID;"
Adjust the table prefix if yours isn't wp_. The regex
matches the shape only — a mistyped code with the right shape lands
on the list too, and only the mod-11 checksum can tell them apart.
Then comes the by-hand part: run the mod-11 check on each hit, convert the true ISBNs to their 978-prefixed ISBN-13 with a recomputed check digit, and paste each result back into the right product. It is mechanical work with no judgment in it — exactly the kind that a hundred backlist titles turn from an afternoon into a week.
How CatalogLift finds it
Every scan validates each product's identifier field deterministically, and a ten-character code that passes the ISBN's own mod-11 check becomes a finding at medium severity — kept apart from broken codes, because this one is right about the book and only wrong about the notation. The evidence shows the passed check and the consequence: in this form, the code never reaches the product's JSON-LD.
Each finding carries the exact ISBN-13 the code converts to — 978, the nine digits, and the GS1 mod-10 check digit computed over the thirteen — arithmetic with one correct answer, so there is no AI on this path and nothing is guessed. You approve the conversion inside CatalogLift, CatalogLift writes the ISBN-13 to WooCommerce, and the next scan verifies the field now holds a code that flows into the structured data. Because CatalogLift keeps watching, the next backlist import full of ISBN-10s surfaces at once instead of sitting invisible for years, and the first scan costs nothing and needs no card.