“No global identifier provided” in WooCommerce: where the GTIN warning comes from
WooCommerce sends the GTIN to Google by itself — no plugin or code snippet needed. If the field is filled in and the warning stays, the code has the wrong number of digits or the page is a variation without its own code. Below are the cases we tested and what to do with each.
Search Console shows this warning on product pages whose structured data has no product number:
no gtin, mpn or isbn. It is listed as a non-critical issue. The page is not excluded because of
it — Google is simply missing a field it would like to have. So there is no hurry, but the fix is
usually a few minutes of work.
Do I need a plugin or a code snippet?
No, not on WooCommerce 9.3 or newer. Since 9.2 WooCommerce has its own field: open the product and go to
Product data → Inventory, the field under SKU is GTIN, UPC, EAN, or ISBN. Since 9.3 WooCommerce
puts that field in the product page’s structured data as gtin, with no plugin. We checked it on a
product page of a test store: the code from the field is there.
The code snippets you will find for this warning date from before that field existed. The popular one
copies the SKU into gtin8. A SKU is your own number, not a GTIN, so this hands Google a made-up
code — it removes the warning and puts something false in its place.
The field is filled in and the warning stays. Why?
When it sends the code to Google, WooCommerce keeps only the digits and counts them. Only 8, 12, 13 or 14 digits go to Google (since WooCommerce 9.4). Any other code is dropped without a message — not in the product editor and not anywhere else. WooCommerce does not check the check digit, so a code with a wrong last digit goes to Google as it is.
What we got on WooCommerce 11.2.1 (October 16, 2026), case by case:
| In the GTIN field | What goes to Google |
|---|---|
5901234123457 — EAN-13 | 5901234123457 |
590-1234-12345-7 — the same with hyphens | 5901234123457 |
012345678905 — UPC-A, 12 digits | 012345678905 |
96385074 — EAN-8 | 96385074 |
978-83-01-00000-4 — ISBN-13 | 9788301000004 |
12345678905 — UPC-A that lost its leading zero | nothing |
83-01-00000-1 — ISBN-10, also with an X at the end | nothing |
5901234123450 — wrong check digit | 5901234123450, as it is |
5.90123E+12 — a code damaged by a spreadsheet | 59012312, see below |
The last row needs a word. When a 13-digit code is saved as a number, Excel writes it as 5.90123E+12.
When the product is saved, WooCommerce removes the dot, the E and the plus sign and keeps 59012312. That is 8 digits, so it goes to
Google as if it were an EAN-8 — a different number, with a wrong check digit.
Two more things we saw along the way:
- Letters disappear on save. Something like
ABC-5901234123457typed into the field is saved as-5901234123457, without a word, and goes to Google as5901234123457. - The duplicate check compares codes as typed. WooCommerce refuses a code that another product
already has, but
590-1234-12345-7goes through next to5901234123457. Both products then send Google the same number.
What to do:
- 11 digits: it is a UPC-A without its leading zero. Type the full 12 digits, with the 0 in front.
- ISBN-10: type the ISBN-13 of the book — it is printed above the barcode and starts with 978 or 979.
- Wrong check digit or a code from a spreadsheet: type the code again from the packaging. Before importing a CSV file, set the code column as text in the spreadsheet.
Variable products
The product page — the address without attributes — gets the parent product’s code. The codes of the variations are not there. On most variable products the parent has no code, and rightly so: each variation is a separate item with its own number. So Search Console can show the warning on that page. Don’t remove it by copying a variation’s code to the parent — then two items carry one number, which is worse than an empty field. The warning is optional; leave it.
The address of a variation — with the attributes in it, e.g. ?attribute_pa_size=m, the way
product feeds link to variations — has been treated separately since WooCommerce 11.0. It gets only the
variation’s own code. The parent’s code does not carry over to the variation: a variation without
its own code goes to Google without one.
What we tested: a parent with a code and three variations — S with its own code, M with none, L with 11 digits.
| Address | What goes to Google |
|---|---|
| product page | the parent’s code |
| variation S | the code of S |
| variation M | nothing — not even the parent’s code |
| variation L | nothing — wrong number of digits |
What to do: fill in the code on each variation, on the Variations tab, under the variation’s SKU.
How do I see what WooCommerce sends?
Paste the product address into Google’s Rich Results Test
and open the product it finds: if gtin is not there, Google does not get a code from that page. Without
Google’s tool: open the page source and search for "gtin". For a variation, test the address with the
attributes in it.
When the codes are fixed, click Validate fix in the Search Console report. Google checks the pages again on its next visit, which can take days.
The whole catalog at once
Export your products to CSV (Products → Export) and open the file in the GTIN validator. It flags every code from the table above that Google does not get or gets wrong: the wrong number of digits, a UPC without its leading zero (with the full code next to it), an ISBN-10 (with its ISBN-13), scientific notation, a wrong check digit and one code written in two ways. In a WooCommerce export it skips variable products, because their variations carry the codes. The file never leaves your browser.
Inside the store, with no export, Merchlint finds products and variations with no GTIN and two products sharing one. Both checks are in the free WooCommerce plugin.