If skus follow a strict convention then in tools like spreadsheet software you can use wildcards, or regex, etc to filter only.
And on platforms like shopify it’s base apis allow querying product-variants based on sku; but not on suboptions.
https://shopify.dev/api/admin-graphql/2022-07/objects/productvariant#query-productvariants
Which also means hypothetically if a some sort of bulk variant selection (*)was ever a native feature in the admin this posts problem would be obsoleted as long as the search syntax query allowed wildcards for variants.
For example, in a very naïve sku scheme , skus start with a color letter for the color option.
Blue products variant skus start with b.
And there is a size option too so some skus have an affix “-xs” to signify extra small garments.
So in the products admin is use the search syntax:
- Find all blue skus with starting letter b using a prefix query
- sku:b*
- There is no affix or pure wildcard search, or regex search.
- Find all skus that contain the letters xs
Combine the above two queries(connective)
Example url https://store.myshopify.com/admin/products?selectedView=all&query=sku%3Ab%2A%20and%20sku%3Axs
What currently doesn’t work in the admin search is searching by other variant properties like options or the variant.title .
So potion:small, option1:small or title:small,etc does not work.
But the product admin search is promiscuous for some things.
So it will match all products that have the string “small” somewhere in it’s data, or something as simple as 12 if i’m searching shoe sizes but I’ll only get good results if 12 isn’t in product descriptions,titles,etc. So it’s easy to get false positives and false negatives.
There’s more to it but it’s just poorly documented for merchant use so can require experimentation to tell if a sku convention will work in the admin product search.