Konstantinos Sakkas

I can’t find any instances of the word “indexed” in debug.log at all. For “index” there is a mention for httpdocs/index.php(17): require(‘…’) at #15 of a stack trace, triggered by a different plugin (google-listings-and-ads).

But I think I might have distinguished a pattern in searches. I think all products which are being searched but not being returned are ones which are out of stock. Is there an option to return all products regardless of stock status which I might have overlooked?

Hi @msaari,

Now that 5 days have elapsed, and we have uploaded new products, I can see there are more SKUs which are not being returned in the search, but I can’t find any useful piece of information in our debug.log to help me narrow down the problem.

Could I share the debug.log with you in some way other than pasting it here? I don’t want to risk disclosing any sensitive information in the public domain.

Thank you.

I have added it to the functions.php and enabled debugging. Let us wait for some useful information to appear in the log. I’ll return here soon with more information (I hope).

Hi @msaari,

I have used the action you shared and it seemed to work okay, until this morning when I heard back from the shop manager on this 8445413309906 SKU, which has been imported about a week ago. Today they tried to search for it on the front end, and it is not being returned.

Do you have any additional info that could help maybe?

Thank you.

Kalispera @anastas10s

Thank you for assisting me with this.

You are correct in noticing that there are indeed different variations of the same products among the misinterpreted ones.

I have clicked on the suggested action link, and I’ve read the guide that loads. I don’t think there was any clear instruction on how to address the issue at hand there; only general guidelines on proper product title structure etc.

Kindly note that I have previously started a ticket with Google Merchant. They had replied that they had acknowledged the issue, but they were unable to recognize what had triggered it, and it was not possible to suggest a solution on their end. They had only advised we mark every product as a false positive, asking Google to check and whitelist the products in question. We had, indeed, proceeded with that workaround, and that had started decreasing the number of disapproved products, slowly but steadily. However, when we imported a new batch, the total number of problematic products increased greatly. The next imports have increased that even further, and we are now having some 850+ variations marked as inappropriate.

In fact I am pretty sure we had started our investigation from the very same document you’ve shared from Google’s documentation.

Please find below our site’s configuration. It’s been set to expire after 2 views or 72 hours. Kindly exhaust the 2 views: https://quickforget.com/s/0717adc1099a08208cd55cbfcbefa498198453e08844141c

Please review and advise.

Best regards, Konstantinos.

I got you! Effectively the product variation SKU gets associated with the product, and upon searching for the variation SKU the product gets returned. That is an acceptable behavior, and my team would be greatly satisfied if it can work like this.

I’m worried about the instances of product variation SKU which don’t get indexed automatically when created or imported through the WooCommerce API, like the example SKU I’ve shared.

Do I just need to apply the extra filter you shared in order to index the product variation SKUs automatically – and not having to worry about it again in the near future – or do I have to perform more configuration to address this? I would be happy to do anything that needs be done.

Please keep in consideration that we are very sporadically adding a new product manually. Usually we import an .xls file with the WP All Import Pro plugin (WC API). So we would need a solution that would work for both ways, with extra attention given to the latter.

Thank you again,
Konstantinos.

Doesn’t that filter do the same work as enabling product_variation indexing, with the “Respect exclude_from_search” checkbox unchecked, and with the _sku value set in the custom fields to include in the index though?

If not, how do the two approaches differ?

I’ve set it up like follows.

https://ibb.co/mhYZhyT

I’ve also unchecked the “Respect exclude_from_search” checkbox.

https://ibb.co/zFWBPvP

Hi,

I am returning here to report that at first it appeared like the issue had been resolved. Unfortunately, yesterday I had a new example of an indexed product variation. I did not order a manual index in order for you to be able to check this on your end if you need.

The product variation is created in the back end, and can be found on the WP search, but on the front end it can not be retrieved. The SKU is 1823847991244. The URL is https://bonitoshop.gr/

https://ibb.co/25tZRP5
https://ibb.co/zrr4QYC

Would you kindly check this and advise further?

Thank you,
Konstantinos.

Hi @msaari,

I see. Therefore when importing products with WP All Import Pro, this action would take care of the rest of the custom fields to be indexed. Sounds nice. I’ve put that into my funcitons.php thanks!

Please allow me some time for my shop managers to test this, and then I’ll report back with any plausible further issues, or ideally mark the ticket as resolved.

Kind regards,
Konstantinos.

Hi @moshtafizur01,

I navigated to the path you shared, and changed the closest container value from .summary to .single-product.

I can’t really tell a difference in the output in the All Products page.

Kind Regards,
Konstantinos.

Hi @moshtafizur01,

My initial impression was that it was caused only when importing products via the WP All Import Pro plugin. However I tested it further. I edited a product’s variants directly, and manually assigned each and every variant the same EAN, and this behavior in the “All Products” view occurred yet again, exactly the same way.

Kind regards.

Thank you.

Thanks for the insight. Please mark this thread as solved.

Hey, thanks for the insight. I have run the remove duplicate rows process, and have brought down the sizes of the two tables significantly. trp_dictionary_el_en_us now only takes up 178MB while trp_original_strings just 3MB. Additionally there has been a significant speed bump to the better without any compromises. Cheers!