- Product categorization is three jobs wearing one name: putting an item on a shelf, filling the attributes that shelf demands, and giving it an identity code.
- The cheap error is the wrong shelf. The expensive error is a shelf whose required attributes you cannot fill, because that gets the listing disapproved rather than merely misplaced.
- Google assigns a category automatically. You override it in a short list of cases, and one of them is alcohol.
- You will end up maintaining several taxonomies at once, and they answer to different masters. Trying to keep one is how catalogues rot.
- A model is good at proposing a category and bad at knowing which of your two similar products a supplier row refers to.
- The measurable win is attribute coverage per category, not accuracy on a sample you picked.
Somebody tells you to run the catalogue through a model and get it categorised. Two thousand rows, a spreadsheet exported from whatever you used before, half the descriptions written by a supplier in another language. It sounds like exactly the job a language model should be good at, and in one narrow sense it is.
Then the product feed gets rejected, and the rejection has nothing to do with categories being wrong. It has to do with a category being right and demanding four fields you never collected. This is the shape of the problem, and it is worth understanding before you spend a weekend on it.
What are you actually categorising for?
Three different consumers, with three different tolerances. Sorting them out first saves most of the wasted effort.
Your own site navigation is the forgiving one. If a lamp sits under lighting rather than under home decor, a shopper finds it anyway through a related product or through search, assuming your search box handles the words a customer would use. Nothing breaks, and you can change your mind next month.
The advertising and shopping feeds are strict. Google maintains its own taxonomy and assigns every product to it automatically, so the merchant supplied value is an override rather than a requirement. The documentation names the specific situations where you should override: when a wrong category triggers requirements you cannot meet, when you want a different campaign structure, and for alcoholic beverages, which must sit in a named category. Submit either the numeric id or the full path, not both. Get it wrong in a category with extra mandatory fields and Google disapproves the product rather than quietly filing it elsewhere.
The marketplaces are stricter again, because their categories carry required item aspects. eBay exposes this through a Taxonomy API that returns the category tree, suggests a category, and tells you which aspects to include for an item in that category. There is even an endpoint for expired categories, which tells you something about how often the tree moves under you.
Why do you end up with several taxonomies?
Because each product taxonomy belongs to somebody else and answers a different question. Merchants who try to collapse them into a single tree spend years discovering why that does not work.
The four you will meet
| Taxonomy | Who owns it | What it decides | Cost of getting it wrong |
|---|---|---|---|
| Your own navigation | You | How shoppers browse your site | Mild, and reversible in an afternoon |
| Google product category | Which extra attributes are mandatory | Disapproved products, so no ads run | |
| Marketplace categories and aspects | The marketplace | Which filters your item appears under | Listing blocked, or invisible to filtered search |
| GS1 GPC bricks | GS1 | How trading partners exchange the item | Only matters if you supply retailers |
The GS1 scheme is the one most small sellers can ignore, with one exception. It is a four level hierarchy running from segment down through family and class to brick, with brick attributes carrying the details, and it exists so that a supplier and a supermarket can agree on what a jar of vinegar is. If you sell only through your own site and consumer marketplaces, it is not your problem. If you ever want to sell into a retail chain, it becomes your problem on the first day and it is a far bigger job than a feed.
The practical answer is to hold one internal taxonomy that you control, then maintain mappings out to each external one. The mapping is data, so it can be regenerated when a tree changes. A merged tree cannot, which is why merged trees quietly become wrong.
Which parts can a model actually do well?
Proposal, extraction and normalisation. Not identity, and not judgement about your own catalogue, which is the same line that decides which columns a model may touch during a catalogue migration.
Proposing a category is the natural fit. Given a title, a description and an image, picking the right node in a published tree is a classification problem with a closed answer set, and a decent model does it at a rate well above what a bored human achieves on row eleven hundred. The important design choice is to make it choose from the actual tree rather than write a category name, because a plausible sounding category that does not exist is worse than no answer.
Extracting attributes from prose is the underrated one. Supplier descriptions bury material, dimensions, capacity and compatibility in a paragraph. Pulling those into typed fields is exactly the shape of work models handle, and it is the work that determines whether your listings qualify for filters. Schema.org even has a general mechanism for it: additionalProperty exists precisely for characteristics with no dedicated property, alongside the named ones like material, colour and size.
Normalising values is dull and valuable. Nine spellings of one colour, sizes recorded in three unit systems, brand names with and without a suffix. This is where catalogues actually fail their filters, and it is a job with a right answer you can check.
Which parts will it get wrong in ways you will not notice?
Identity, above all. If a supplier row says black cable 2m and you sell two similar cables, no amount of reading comprehension resolves which one it means. The model will pick one, confidently, and the stock adjustment lands on the wrong product. Identity is a matching problem against your own records, and it needs a code, not a guess. This is what GTIN, MPN and your own SKU are for.
Then there is category drift over time. A model classifies against the tree it was shown. Trees change, categories expire, and nobody re runs the job. Six months later a slice of your catalogue sits in nodes that no longer mean what they meant.
Third, and most insidious, is confident completion of missing data. Asked for a material and given a description that never mentions one, a model will often supply the most likely material rather than an empty value. That is a fabricated product attribute, published on your site, and in some categories it is a compliance issue rather than a tidiness one. Insist on a null option and check how often it gets used. A model that never returns unknown is not being accurate.
Run the whole job on twenty products you know intimately before you run it on two thousand. Not to measure accuracy, which will look fine, but to see the shape of the mistakes. Every catalogue has its own confusions, and yours are more useful to you than any published benchmark.
The variant problem, which is really a modelling problem
Most catalogue pain that gets blamed on categorisation is actually about variants. One shirt in five sizes and three colours is fifteen sellable things and one product a shopper thinks about. Every system you feed has an opinion about how to express that, and the opinions differ.
Google's merchant listing guidance is blunt on the point: variants need separate markup, each with its own distinct URL. Schema.org models the relationship with hasVariant, tying members to a product group. Marketplaces often want the opposite shape, a single listing carrying an aspect matrix. Your own site probably wants one page with a picker. Three shapes, one truth underneath.
The way this goes wrong is invisible for months. Somebody decides variants are just separate products, which is easy to build and destroys the relationship. Reviews scatter across fifteen pages, none accumulating enough to show a rating. Stock reads as fifteen small numbers rather than one product with a size out of stock. Search results show you the same shirt fifteen times. Reassembling the group later is manual work nobody schedules.
So decide the variant model before the categorisation run, not after. A model can help propose which rows belong to the same group by comparing titles and attributes, and it is genuinely useful for that on an inherited catalogue. It should propose, not merge. Two products that differ only in a code you do not understand may be the same item in two packagings or two entirely different items, and the supplier is the only one who knows.
What does this cost in time?
Less than people fear for the pass itself, more than they expect for the parts around it. The classification run over a few thousand products is minutes of compute and a small bill. The review queue is where the hours go, and the size of that queue is set by how clean the source data was, not by which model you picked.
A rough shape from doing this on real catalogues: identity work first, which is tedious and mostly mechanical. The category pass, which is fast. Then the attribute coverage work, which is the long tail and is best done category by category in descending order of revenue rather than all at once. Most shops get the majority of the benefit from their top few categories and can leave the rest at whatever the automated pass produced.
The trap is treating it as a project with an end. Catalogues take in new products weekly, suppliers change their description formats, and external trees move. What you actually want is the same pipeline running on new products at intake, which is a far smaller job once the first pass exists, and a monthly look at the coverage table. A one time cleanup with no intake process is worth about six months, then you are back where you started with a spreadsheet and a weekend.
The order that saves the most work
Sequence matters more than tooling here, because each stage makes the next one cheaper.
Identity codes first. Every product needs a stable internal id and, where one exists, a GTIN or an MPN. Google's structured data guidance lists gtin and mpn among the recommended properties for a merchant listing, alongside brand and sku. Do this before anything else, because every later step joins on it. A catalogue without stable ids cannot be improved incrementally, only redone.
Category path second. One pass over the catalogue, choosing from the real tree, with a confidence value recorded next to each choice. Everything below some threshold goes to a review queue rather than into the feed. The queue is the point: it converts a quality problem into a finite list.
Required attributes third, per category. This is the stage that pays. For each category you actually use, list the attributes it demands, then measure coverage across the products in it. A category at 40 percent coverage is a category where most of your listings are invisible to a filtered search, and no amount of better description writing fixes that.
Everything else last. Longer descriptions, richer copy, better photography. All worth doing, all worth less than the three stages above, and all easier once the structure underneath is right. If you are at that stage, our note on how much editing AI written product copy needs before it ships is the relevant one.
How do you know it worked?
By measuring coverage rather than accuracy, and by measuring it per category rather than across the catalogue.
Accuracy on a sample is the number everyone reports and the least useful one available. It is measured on the products you happened to check, it hides the categories where you are systematically weak, and it tends to look excellent because most catalogues are dominated by a few easy categories.
Coverage per category is harder to fake. For each category in use, the share of products carrying each required attribute. Sorted worst first, that table is a work queue. It also tells you when to stop, which no accuracy figure ever does: a category at full coverage on its required fields does not need more attention, whatever a model scores on it.
The second measure worth keeping is the review queue rate. If the share of products the model is unsure about is falling as you clean the source data, the pipeline is working. If it is flat, you are cleaning the wrong things.
What this has to do with being found
Structured attributes are no longer only a feed concern. When a shopper asks an assistant for a waterproof jacket under a certain price in a certain size, the answer is assembled from structured fields, not from your paragraph about craftsmanship. A product with a category and a full attribute set can be matched to that question. One without cannot, however well it is written.
We went through what that means for page structure in a piece on what AI shoppers read on a product page and where most pages fall short, and the conclusion points the same way as this one: the machine readable layer is now the layer that decides whether you are considered at all. The same logic drives the accessibility work, since alt text and attributes are both descriptions of the thing rather than persuasion about it, and we covered how to triage alt text across a catalogue of thousands of images on the same principle of doing the highest traffic items first.
None of this requires a large system. It requires a stable id, one authoritative internal tree, mappings out to the external ones, and a coverage table you look at monthly. If you are choosing the foundation for that rather than patching an existing one, the case for a store whose catalogue structure and data stay yours is that migrations between platforms are where taxonomies get flattened and attributes get lost, usually silently.
One thing worth being stubborn about
Never let a categorisation pass write directly into the live catalogue. Write to a staging column, review the low confidence rows, then promote. It is an extra hour of setup and it is the difference between a bad run costing you an hour and a bad run costing you a fortnight of finding out which of nine hundred products quietly changed shelf. Catalogues are one of the few places where an automated mistake is both cheap to make and expensive to detect, so the guard rail earns its keep on the first bad run. Keep the staging column after the initial cleanup too, because the intake pipeline will need exactly the same protection every week it runs.