1

When importing products with CSV searching for one of the products created by the import by name works, but searching for the SKU returns nothing. This is true both in admin and the storefront (using a search plugin that can search by SKU).

The created products are also visible at the top of the product list, and it lists the SKU correctly.

If a product is updated (going into edit or quick edit and just clicking update) it is then searchable by SKU both in admin and the store.

If a product is created manually and then updated with import this is not an issue.

mujuonly
  • 11,370
  • 5
  • 45
  • 75
Forecaster
  • 165
  • 1
  • 8

2 Answers2

1

I had the same problem, and symptoms after WooCommerce's built-in CSV import (wouldn't be found in search until I manually published or updated). It also affected Point of Sale for WooCommerce (could not search SKU to generate barcodes).

I found the solution was to rebuild the WooCommerce index, I went to WooCommerce Settings -> Search -> Index -> Rebuild, then Run the indexer. I believe the indexer is refreshed on each publish, and for some reason isn't refreshed on CSV import.

My admin searches and Point of Sale searches worked after that. This was on WooCommerce 4.0.1.

I also found searches had to have at least three SKU characters in the search field to return results.

0

I had this same problem and I imported products with ImportWP. Admin products search would not find anything by sku, ImportWP stopped working, WooCommerce import would complain about "No matching product exists to update.". This would get fixed by switching SKU from "123" to "1234" and back to "1234" somehow refreshing indexes. I looked in the database and in the table wc_product_meta_lookup the sku field was empty for my newly imported products. I ran the following query and now updates work again.

Update
  wc_product_meta_lookup as C
  inner join (
    SELECT post_id, meta_value as sku FROM `postmeta` where meta_key = "_sku"
  ) as A on C.product_id = A.post_id
set C.sku = A.sku

This is on Wordpress 5.8.3 and WC 6.0.0 so looks like this bug can still occur.