How to Add Product Type in Shopify When the Field Is Not on the Product Page
If you opened a product, scrolled to the Organization card, and found Category, Vendor and Tags but no Product type, you did not miss it. On 2026-09-05 we read the full text of a product page in the current Shopify admin, including the content inside its shadow roots, and the string "Product type" appeared zero times anywhere you could see or click. That is one admin, on one store, on one day: if yours still shows the field, you are on an admin that has not changed yet, and the one-product route still works for you.
The field still exists. Products still carry a product_type value, and the endpoint that publishes a storefront's catalogue still returns it. The input box is still in that page's markup, but on the day we looked it sat inside a popover set to visibility:hidden — present, and not something you can click. The place it still has one is the bulk editor, which is the better place anyway: nobody with a real catalogue has one product to fix.
Key takeaways
- The Product type field was not reachable on the product page in the admin we read on 2026-09-05. If that matches what you are seeing, the one-product-at-a-time route is closed to you.
- The bulk editor still has a Product type column:
/bulk?resource_name=Product&edit=product_type. - Sorting the Products list by Product type ascending floats every blank one to the top. That finds the gaps without exporting a CSV.
- Product type and the newer Category (Shopify's taxonomy) are two separate fields. Filling one does not fill the other.
- In 42 public storefronts we read on 2026-09-05, 2,054 of 5,937 products had no product type — 34.6% by product, and 13.5% at the median store, and 24 of the 42 stores had some products typed and some not. The two rates answer different questions and are not interchangeable — see the measurement section.
The quick version
Three steps, then you start typing.
Size the job. Open Products in your admin and sort by Product type, ascending. Products with no type sort first, so you can see how many there are and whether they arrived together.
Open the bulk editor on that one field. Your admin URL looks like
admin.shopify.com/store/your-store/products. Replace everything from/productsonward with:/bulk?resource_name=Product&edit=product_typeThat opens a spreadsheet-style grid with a Product type column that accepts typing. It loads its own list of products — the sort you just did does not carry over, so keep the Products tab open if you want to refer back to it.
Type and save. Type the value into the Product type cell, then save.
That is the mechanism. The rest of this page covers the parts that go wrong: which field you are actually editing, how to avoid inventing a pile of near-duplicate types on the way through, and how much of a catalogue this usually affects.
Your catalogue already knows which types are missing
Arvio reads your live catalogue, finds the products with no product type, and proposes one for each based on that product's own title, tags and variants. Nothing is written until you approve it.
Product type and Category are two different fields
This is the single most common way the job gets done wrong, and it costs you the session, because you finish and the blanks are still blank.
Category is Shopify's standard taxonomy. You pick from a controlled tree, the values are the same in every store, and the platform uses it for things that need a shared vocabulary across all of Shopify. Category is on the product page, which is part of why people assume it replaced the older field.
Product type is your own user-defined label. You type whatever you want. Nobody validates it, nothing autocorrects it, and no two stores need to agree on it. It is the field that ends up in your automated collection conditions and in whatever internal filtering you have built for yourself over the years.
Two things follow:
- Setting a Category on a product does not give it a product type. If you spent a session filling in categories and your collections still look wrong, this is why.
- A product with a blank product type is not an uncategorised product. It may well have a Category. Those are different columns, and this page is only about one of them.
So: if your store has automated collections, theme filters or exports that read Product type, the blank rows are the ones behaving strangely. If nothing in your store reads it, blank costs you nothing. Check before you spend the afternoon.
Finding which products are blank without exporting a CSV
The usual advice is to export to CSV, filter the empty column, fix, re-import. That works, and it is also the route with the most ways to damage a catalogue: a re-import writes every column in the file, not the one you meant to change.
The Products list already does the finding part.
Sorting ascending puts empty values first. You now have three things you did not have a minute ago: how many blanks there are, which products they are, and whether they cluster (one supplier, one import, one collection) or are scattered at random. That clustering question decides how you fill them. A block arriving from one supplier feed usually wants a single type applied down the block. The same products scattered across the catalogue are that many separate decisions.
Sorting only changes what you are looking at. The list still holds everything else, so check the order is still the one you set before you trust the top of it.
The bulk editor is where the field still has an input box
Open the URL from the quick version. The edit=product_type part is what makes the grid show that column rather than the default set, which matters: a bulk editor showing every column it can show is that many columns of accidents waiting for a mistyped paste.
Product title is there so you can tell what you are typing about. Product category is there so you can see the taxonomy value beside the user-defined one: a row can carry a Category and still have no Product type, which looks broken until you know the two fields are unrelated.
What to actually type. The value is your answer to "what is this", in the noun a customer would use, at the level that groups several products. Mug groups things; Blue 350ml Stoneware Mug groups nothing. If the label describes an attribute instead of the thing (Sale, New, Summer), it belongs in Tags, because each product gets one product type and spending it on a season leaves nothing durable behind.
How to work the grid without making it worse:
- Reuse before you invent. Check the types your catalogue already uses and copy one of them exactly. Every fresh string you type creates a new product type, and nothing in the store will tell you that you meant the one you created last month.
- Fill in clusters. If a block of products came from one supplier or one import, do that block in one pass while the decision is still loaded in your head.
- Save as you go. Save in batches instead of at the end. The further you get before saving, the more there is to redo if the tab goes.
It gives you the grid, not the answers. Every row still needs a human to decide what this product is and type it. For a short list that is fine. The grid is easy. The list is long. That is where people stop.
The bulk editor gives you the grid. The typing is still yours
Arvio proposes a type for every product that has none, drafted against that product's own title, tags and variants, so the job becomes reviewing a list instead of filling one in. You approve or discard each one.
The same rows, after
Same grid, same rows, after typing and saving. The store in these three screenshots is our own demo store: 19 of its 68 products had no type, 27.9%, and it is not part of the 42-store denominator in the next section.
Two things to check after a save, because the grid says it saved and stops there:
- Go back to the Products list and sort by Product type ascending again. The rows you just filled should no longer be at the top. That is the check that the write actually landed.
- If you have automated collections with a Product type condition, look at their product counts. Filling in types moves products into collections, and that is usually what you wanted, but it should not be a surprise.
How often catalogues actually leave product type blank
How it was measured. On 2026-09-05 we requested /products.json?limit=250 from 43 public storefront domains. That endpoint is anonymous: no login, no browser, nothing authenticated. Of the 43, one did not respond and was excluded, leaving 42 stores and 5,937 products counted. A product counts as blank when its product_type is missing or empty once surrounding whitespace is trimmed.
Whether it looks like you. These 43 domains were collected because they publish machine-readable storefront metadata (UCP / agents.md), which skews the group toward newer and more technically tidy stores. For this particular question that pushes in the conservative direction: if anything, a group like this should have fewer blanks than a random store, not more. This is not a random sample and it is not the web. It is the same batch of public storefronts we used for our other catalogue measurement, not a second independent test of the same thing.
| Measure | Value |
|---|---|
| Stores read | 42 of 43 (1 excluded, no response) |
| Products counted | 5,937 |
| Products with no product type | 2,054 |
| Blank rate, by product | 34.6% |
| Blank rate, median store | 13.5% |
| Stores with nothing typed | 9 of 42 |
| Stores with some typed and some not | 24 of 42 |
| Stores with everything typed | 9 of 42 |
| Stores whose catalogue hit the 250-product read cap | 16 of 42 |
The two rates are not interchangeable. 34.6% is per product, so large catalogues dominate it. 13.5% is the median store, so every store counts once. If you want "how much of the world's product data is untyped", use the first. If you want "what does a typical store look like", use the second. Quoting one as if it were the other is the mistake this table exists to prevent.
What the numbers do not cover. 16 of the 42 stores hit the 250-product cap on that endpoint, and those 16 account for 67% of the counted products, so for two thirds of the products here we read the front of the catalogue rather than all of it. And /products.json does not return the newer taxonomy Category at all, so this measures blank product type only. It is not evidence that these products are unclassified.
The row that matters most is the middle one. 24 of 42 stores had some products typed and some not. Somebody was doing this properly. Then a supplier feed, a migration or a busy month landed a batch of untyped products in the middle of the catalogue. That is the shape the bulk editor is built for, and it is also the shape that is hardest to notice, because the field looks filled in everywhere you happen to look.
Five ways this goes wrong in practice
Near-duplicate types. T-Shirt, T-shirt, Tshirt and Tees are four different product types as far as the store is concerned, and nothing warns you. The cost surfaces later, when a collection condition matches three of the four. Copy an existing value exactly instead of retyping it from memory.
Typing the category into the type column. They sit next to each other in the grid, and the taxonomy values are tempting because they sound official. Copying taxonomy strings into your user-defined field gives you a second, worse copy of a field you already have.
Types that are really tags. If a value describes an attribute rather than what the product is (Sale, New, Summer, Gift), it belongs in Tags. Product type is one label per product, so spending it on a temporary attribute means the product has no durable answer to "what is this".
Too many types. A type that fits one product is just a longer title. If you are creating a type per product, the useful level is one step up.
Assuming the fix propagated. Filling product type does not backfill Category, does not touch tags, and does not rebuild anything you exported earlier. A downstream system that took a copy of your catalogue yesterday still has the blanks.
Three catalogue shapes where this shows up
The supplier feed. Products arrive from a dropshipper or a supplier sheet where the type column was never mapped. They land in one contiguous block, which is the easy case: sorted list, bulk editor, one type down the block, done in a pass.
The migration. A store moves from another platform. The importer maps titles, prices and images cleanly, but has nowhere to put a field the old platform did not have. The result is a catalogue split at the move date, typed on one side and blank on the other. Sorting ascending makes that boundary visible immediately.
The catalogue that outgrew the habit. The early products were typed by hand by whoever built the store. Later, adding a product became something done in a hurry, and this field is the first thing a hurried person skips, because nothing on the product page asks for it any more. This is the 24-of-42 shape above: some products typed, some not, in the same store.
FAQ
Where is the Product type field in the new Shopify admin?
It is not on the product page. When we read the full text of a product page in the current admin on 2026-09-05, including inside its shadow roots, "Product type" did not appear. The field still exists on the product and still has an input box in the bulk editor at /bulk?resource_name=Product&edit=product_type.
Is Product type the same as Category?
No. Category is Shopify's standard taxonomy, chosen from a fixed tree and shared across all stores. Product type is your own user-defined label. Setting one does not set the other, and a product can have either, both, or neither.
Can I edit product type in bulk without touching a CSV?
Yes. That is what the bulk editor URL above does. It edits one field across many products in place, which avoids the main risk of the CSV route, where a re-import writes every column in the file rather than the one you intended to change.
How do I find every product with no product type?
Sort the Products list by Product type, ascending. Empty values sort first, so the blanks collect at the top. No export needed.
Do I have to fill product type in at all?
Only if something in your store reads it: automated collection conditions, theme filtering, exports, or your own reporting.
How many product types should a catalogue have?
Few enough that each one groups several products. A type matching a single product groups nothing. We have not measured this, so treat it as a rule of thumb, not a benchmark.
Is a blank product type the same as an uncategorised product?
No, and our own measurement cannot tell you about the second one. The /products.json endpoint we read does not return the taxonomy Category, so all we can say is that the user-defined product type was empty.
Will filling in product types change my collections?
It can, if you have automated collections whose conditions use Product type. Products that suddenly match a condition will join that collection. Check the product counts on those collections after a bulk save so the change is something you saw rather than something you discovered later.
If the grid is the part that stops you
The bulk editor solves the access problem: the field has an input box again, and you can reach a screenful of products at a time. It does not solve the volume problem. Every row is still a decision, and the decision does not get faster with repetition.
One screen of the grid is quick. The rest of the catalogue is why people stop
Arvio is an AI store operator: it reads the catalogue you already have, proposes the change per product, and waits for you to approve it.
Not ready to install anything? Run the free store audit on your storefront. It needs no account. It does not look at product type — it checks the storefront side: speed, SEO, mobile, checkout, conversion, and how ready the store is for AI shopping surfaces.
Product page field check and the 43-domain catalogue read were both done on 2026-09-05.