https://support.google.com/merchants/answer/160161?hl=en-GB
Not sure how to resolve this without new fields. SKU is no longer on the list of identifiers. There is a warning in the validator.
The plugin woocommerce germanized adds GTIN and MPN as attributes. Maybe you could adopt it.
@mensmaximus Do you mean include those fields or just see if they are defined?
I personally would define them in WooCommerce and inform the plugin developers about that change, so they can modify their plugins. I would not conditionally check in WooCommerce whether there are plugins that define GTIN or MPN. That might become a never ending task as you would never know how those are defined and how they are named (in Germanized e.g. the attributes are called _ts_gtin and _ts_mpn). I just mentioned Germanized because it does define them and doin it as an attribute works well.
@scottopolis (AppPresser) has published a plugin to add GTIN as well. I guess it would be best to talk to developers that already have solutions and whether one of them can be integrated into WooCommerce.
There's also this which supports MPN/GTIN fields:
This is my plugin that @mensmaximus mentioned, happy to help https://wordpress.org/plugins/woo-add-gtin/
Hi Mike,
On the Structure Tool for product availability the below does not show any warning however in the search console I am getting a warning: Invalid value type for field 'availability' (optional)
'availability' => 'https://schema.org/' . ( $product->is_in_stock() ? 'InStock' : 'OutOfStock' ),
If you use only http however no more warning in the search console and in structure tool also its fine.
'availability' => 'http://schema.org/' . ( $product->is_in_stock() ? 'InStock' : 'OutOfStock' ),
Is there a logic explanation here or it something you think need to be highlighted to google ?
As @siliconforks said, https://woocommerce.com/products/google-product-feed/ adds these as fields to products and variations, including access via CSV import/export & REST API.
It also modifies the output structured data to add these, so it's entirely possible for plugins that create those fields to also include them in the structured data output using the existing filters.
@leewillis77 thats fine. I assume we can just mark those fields as not available in the core feed and then GPF can add specific fields if installed?
I think any plugin that adds the fields to products should also add them to the structured data.
Core shouldn't be responsible for doing that for fields added by plugins. The only debate is whether you want to add those fields into core or not.
@leewillis77 I'm thinking we could add identifier_exists set to no. But plugins would have to remove that if defining GTIN and so on..
Are general sites having issue with identifiers being missing from structured data?
The article linked in the original issue note (https://support.google.com/merchants/answer/160161?hl=en-GB) relates to product feed for submission of product data to Google Merchant Centre which core doesn't have, not on-page structured data. The WooCommerce Google Product Feed plugin already deals with all of this anyway for people who are submitting to merchant centre.
I don't think that there is a structured data tag for "identifier_exists". Even if there were I don't think setting that to "no" is correct anyway.
That specifically means "this product does not have an identifier" (e.g. custom goods, self-manufacture etc.) rather than just "i'm not providing the identifier".
Google's guidance historically indicated (IIRC) that they would penalise incorrect use of this, although it doesn't seem to be that strong now.
Just following up on this. I'm seeing a number of customers over the last few days who are now having warnings reported in Google Search Console (e.g. nothing to do with Merchant Centre / product ads) relating to variable products because there is no product identifier specified.
Unfortunately, with the schema markup that WooCommerce outputs we can't output an identifier as the identifier is specific to the individual variation (which WooCommerce doesn't output as a product), not the overall product.
Given Google's recent changes I think we need to look again at whether we can provide more detailed structured data for variable products. Unfortunately their documentation is a bit lacking as they assume that you're selling a single product only on a any given URL (https://developers.google.com/search/docs/data-types/product) but my interpretation is that for variable products we should be outputting multiple Product records, not a single Product with aggregateOffer to represent high/low price.
For background, see also #17471 (which focussed mainly on Google validating information provided into Google Merchant Centre for Google Ads, but with the flagging of these issues in Search Console it would suggest that good structured data is now required beyond that and for natural SEO as well), #22896, and #23075
This has been mentioned before but I'd just like to note that this document specifically talks about "Products variants":
@leewillis77 Thats problematic. Loading all possible varaitions as you know would cause performance issues.
relating to variable products because there is no product identifier specified.
What is the exact warning for those? I thought that was shown on all product types.
The error you see in the Structured Data Testing Tool is "This product is missing a global identifier (e.g. isbn, mpn or gtin8). Please see documentation for valid identifiers."
As we noted in this thread WooCommerce can't add these itself since it doesn't hold them (so yeas you'd see that on simple products by default with just WC core).
In the case of the Google Product Feed extension, we can fix that for simple products by adding the information we hold (& other extensions could do the same). However, because of the format of the structured data WC is outputting, extensions can't fix this for variable products (without just throwing away WC core's data and creating their own), since the variants don't exists as Product records to attach the identifiers to.
I've been looking at a few alternatives, one was that the product page would have the Product record (as currently), together with ProductModel records that didn't contain any info beyond a link to the variation-specific page which could then show a full record for just that single variation. However I've not seen anything that would suggest it's something Google would support. As @siliconforks pointed out the only documented "solution" is to include a Product record for every variation which as you noted has performance impacts.
I just checked a test Shopify store and it would appear to output an Offer with nested Product records for every variation so it looks like that's probably the way to go - we'd just have to solve the performance issues.
Note: Shopify appears to be limited to 100 variants per-product.
Hello,
Could @mikejolley or someone else from the team reply to @sicarioxy regarding his comment?
If you feel like this is out of the scope, please ask @sicarioxy to set this as a separate issue, because I'm too bothered by this and would really like Google to recognize all my products as 'valid'.
Thank you
@mrusan @sicarioxy Validation issues with https vs http schema links is a different issue to this and should be reported separately.
To add to this, i'm seeing issues with
AggregateRating, Brand, Reviews and the Global Identifier.

@shanejones https://github.com/woocommerce/woocommerce/issues/22896#issuecomment-477074896
@leewillis77 You were correct about those docs I linked being wrong for structured data. identifier_exists is not valid.
It wants gtin8 | gtin13 | gtin14 | mpn | isbn.
Several plugins add these fields so we'd just need to decide if we want to leave it to extensions or include a field(s) in core, and if thats a single field which is labeled differently, or multiple fields per possible property.
Another alternative would be to use attributes and pre-fill the name field with GTIN etc and just detect the attribute.
It wants gtin8 | gtin13 | gtin14 | mpn | isbn.
Not sure if this is useful or not, but I have gtin12 entries that seems to validate fine. Added via google Product Feed.
Several plugins add these fields so we'd just need to decide if we want to leave it to extensions or include a field(s) in core, and if thats a single field which is labeled differently, or multiple fields per possible property.
I'm totally OK with that going into core - I'd suggest a single field. Maybe "barcode" is the right description - I think that covers EAN/UPC/ISBN. (It's what Shopify call their equivalent for reference):

MPN is something different and could perhaps be added as its own field.
However, that's the simple side of this issue. While adding the field will resolve things for simple products, it doesn't solve the issue for variations since you need to be able to output bespoke schema per variation since that's likely the place where the identifier should come from.
Would building that Schema markup on product save be sensible? Could we generate inline in the save request for simple products and products with "small" numbers of variations, and queue up an action to build it in the background for products with larger numbers of variations?
Not sure if this is useful or not, but I have gtin12 entries that seems to validate fine. Added via google Product Feed.
Yes - gtin12 is also valid and would fit in the same "barcode" field.
@leewillis77 I'm thinking we could add
identifier_existsset to no. But plugins would have to remove that if defining GTIN and so on..
Could you please share how to implement this ? Thanks
Thanks for the suggestion @mikejolley.
We'll keep an eye on the popularity of this request :)
Just up'ing this feature request.
If you want to upvote this (or any) feature request add a +1 to the issue description.
+1
ID +1 for EAN
+1
+1
Please click in the :+1: in the thread, just +1 does not take into account.
+1
UPC (12 digits) is commonly used in North America
+1
+1
+1
+1
+1
Please implement this one!
+1
+1
+1
+1
+1
Waiting for it to become native, I'll add it to the next SEOPress update:

+1
+1
I can code this, will send a PR.
+1