Adobe Commerce B2B Features: What Magento Gives You Natively, and Where Custom Work Starts
Category
eCommerce Tips & Trends
Most catalogs do not fail because the products are wrong. They fail because nobody decides what a category is and what an attribute is, so “waterproof” became a subcategory, “12V” became a tag, and now the filters return empty pages.
An eCommerce product taxonomy is the decision layer that keeps those things separate. Once a catalog passes roughly a thousand SKUs, the cost of skipping it shows up in site search, in paid feeds, and in the support tickets from buyers who cannot find a part they know you stock.
This is how we structure one, drawn from catalog rebuilds across BigCommerce, Shopify Plus, Adobe Commerce, and CS-Cart.
Quick Answer
An eCommerce product taxonomy is the structured system of categories, subcategories, and attributes that organises a catalog so shoppers, site search, filters, and external feeds all find the same product. A working taxonomy separates what a product is (its category) from what a product has (its attributes), stays under four levels deep, and maps cleanly to Google's product taxonomy so Merchant Center accepts the feed.
Key Takeaways
- A category is what a product is; an attribute is what a product has – mixing the two breaks faceted filtering
- Three levels suits most B2C catalogs, four suits most B2B and industrial ones, and past four you need attributes instead
- Name categories in the language buyers search, not the language your ERP uses
- Map to Google product taxonomy while the tree is still on paper, not after 40,000 SKUs are live
- Build the old-to-new redirect map before you change a single category URL
- Taxonomy without an owner drifts – the owner belongs in merchandising, with SEO and engineering input
What Is Product Taxonomy in eCommerce?
Product taxonomy is the classification system behind your catalog. It defines the categories a product can belong to, the parent-child relationships between those categories, and the attributes that describe products within them.
The plain definition: taxonomy answers the question “where does this product live?” Everything else in the catalog – filters, search facets, breadcrumbs, feed mappings, related-product logic – reads from that answer. Get it wrong and every downstream system inherits the mistake.
It matters more than it sounds because taxonomy is the one piece of catalog architecture that three different audiences depend on simultaneously. Shoppers browse it. Your site search indexes it. Google, Amazon, and marketplace feeds consume it.
Those three want the same structure to behave in three different ways, and reconciling that is the actual work.
Taxonomy, Categorization, Hierarchy, and Attributes – What's the Difference?
These four terms get used interchangeably in vendor documentation, which is where most catalog structures start going wrong. They describe different things.
Taxonomy: the whole classification system – categories, relationships, and attributes together. Example: the complete structure behind a 40,000-SKU industrial catalog.
Categorization: the act of assigning a product to a category. Example: filing a solenoid valve under Pneumatics → Valves.
Hierarchy: the parent-child nesting of categories only. Example: Pneumatics → Valves → Solenoid Valves.
Attributes: properties a product has, independent of where it sits. Example: voltage, port size, body material, certification.
The distinction that saves the most rework is this: a category is what a product is; an attribute is what a product has. If a merchandiser can put “stainless steel” in the category tree, someone eventually will – and then every material becomes a category, the tree balloons to nine levels, and filtering stops working because the facets have nothing left to filter on.
The test is simple. If a value could sensibly apply to products in several different categories, it is an attribute. Colour, size, voltage, finish, and certification are attributes. Valves, monitors, and running shoes are categories.
What Poor Taxonomy Actually Costs You
The symptoms rarely arrive labelled as a taxonomy problem. They arrive as five separate complaints from five different people.
- Merchandising says the filters return empty result sets
- SEO says category pages are not ranking and the internal linking looks random
- Paid says Merchant Center is disapproving items over category mismatches
- Support says customers phone in for parts the site definitely stocks
- Ops says the same product exists three times under three names
All five trace back to the same root. When categories and attributes are mixed, faceted filtering has no clean data to build on, and the filter combinations that should narrow a result set instead produce nothing.
An ecommerce taxonomy problem also compounds quietly. Every new SKU gets filed against the existing structure, so a tree that was awkward at 500 products becomes unworkable at 5,000 – and by then, changing it means changing thousands of URLs.
How to Build an eCommerce Product Taxonomy in 7 Steps
This is the sequence we run on catalog rebuilds. The order matters, because several steps cost little to do early and a great deal to retrofit.
Step 1: Audit the Catalog You Actually Have
Export every product with its current categories, tags, and custom fields. Count how many categories hold fewer than five products and how many hold more than two hundred.
Both extremes signal a structure that grew by accretion rather than design. Note every product sitting in more than one branch – those are your hardest decisions later.
Step 2: Separate Categories from Attributes
Take the flat list of everything currently acting as a category and sort it into two columns using the test above. Expect to move about a third of it.
This single pass is what makes faceted filtering possible, and doing it before you draw the tree saves redrawing the tree.
Step 3: Choose Your Depth – and Stop at Level Four
Three levels handles most B2C catalogs. Four handles most B2B and industrial ones.
Past four, breadcrumbs get unwieldy on mobile, URLs get long, and shoppers lose track of where they are. If you need more depth, you almost always need more attributes instead.
Step 4: Name Nodes the Way Buyers Speak, Not the Way ERP Does
ERP categories are built for finance and inventory, so they carry internal product-line names and cost-centre logic that mean nothing to a buyer.
Pull the actual language from your site search logs and your paid keyword data. A category named for the term buyers search is a category that can rank.
Step 5: Design for Faceted Filtering Before You Design the Tree
Decide which attributes will become filters on which categories, and confirm that each facet has enough populated values to be useful.
A filter that appears on a category where 80% of products have no value for it produces the empty-results problem faster than a bad tree does.
Step 6: Map to External Standards Early
Every product needs a Google product category if you run Shopping, and marketplace channels have their own required taxonomies.
Deciding the mapping while the tree is still on paper is straightforward. Reverse-engineering it across 40,000 live SKUs is not.
Step 7: Plan Redirects Before You Touch a Live Store
Category URL changes are the part that damages rankings. Build the old-to-new URL map first, keep it one hop, and handle the categories that split into two or merge into one deliberately rather than pointing everything at the homepage.
Product Taxonomy Examples: B2C, B2B, and Multi-Storefront
Three worked structures, each shaped by a different buying behaviour.
B2C apparel – shallow tree, heavy attributes. Women → Outerwear → Jackets, then colour, size, fit, material, and season as attributes. Three levels, because apparel shoppers browse visually and filter down rather than navigating deep.
B2B industrial – deeper tree, specification-driven. Pneumatics → Valves → Solenoid Valves → 3-Way, then voltage, port size, body material, and certification as attributes. Four levels, because a B2B buyer arrives knowing the specification and needs to narrow by it, not browse toward it.
We built exactly this structure for Countrywide Sports, a North Carolina wholesale ammunition dealer, where the B2B store pairs gated pricing with faceted filters on price, availability, caliber, brand, and review rating. Revenue rose 52.03%, from $2.13M to $3.24M, and conversion rate rose 22.31%, from 2.51% to 3.07% – see the Countrywide Sports build.
Multi-storefront – one taxonomy, several presentations. A shared master tree in the back end, with each storefront exposing a subset and its own labels for region or brand.
The rule that keeps this maintainable: storefronts may hide categories and rename them for display, but they never restructure the master hierarchy. When they do, product data stops reconciling across stores. The same discipline applies to BigCommerce multi-storefront setups running several brands from one back end.
Mapping to Google Product Taxonomy and Merchant Center Feeds
Google product taxonomy is Google's own fixed classification list, and Merchant Center uses it to understand what you are selling. Your internal tree and Google's list will never match one to one, so the mapping is a deliberate translation layer, not an export.
Three rules make it hold up:
- Map at the most specific Google category that is genuinely accurate, rather than reaching for depth you cannot defend
- Store the mapping as a field on the category record, not in a spreadsheet a person maintains
- Treat variants as a separate problem from categories – variant mapping is where most feed disapprovals actually originate
That variant layer is its own discipline. For Fine Art Canvas we automated the Shopping feed alongside 3D product rendering and variant mapping across tens of thousands of SKUs, correlating every attribute combination – frame style, border colour, dimensions – with its generated image URL through Google's Content API for Shopping. Conversion rate rose 344% and average order value 40% – see how the Fine Art Canvas feed automation works.
If you are running Shopping campaigns against a catalog whose taxonomy is mid-rebuild, sequence the feed work after the tree is stable. Feeds re-approve faster than rankings recover.
Platform Notes: Shopify, BigCommerce, and Adobe Commerce
The concepts are constant; the mechanics are not.
Shopify ships a Standard Product Taxonomy that maps to categories and product types, with metafields carrying the attributes that become filters. The Shopify product taxonomy is genuinely useful as a starting skeleton, but treat it as a reference rather than your finished structure – it is built for breadth across all merchants, not for the depth a specialist catalog needs.
BigCommerce separates categories from product options and custom fields, which makes the category-versus-attribute discipline easier to enforce. The trade-off is that faceted search behaviour depends on how those fields are configured, so filters need designing alongside the tree rather than after it.
Adobe Commerce gives the most control and the most opportunity to over-build. Attribute sets and anchor categories are powerful, and a tree that inherits attributes inconsistently across sets produces filter behaviour that is very hard to debug later.
Across all three, the same question decides where the structure should live: does the taxonomy belong in the platform or upstream in a PIM? If you sell through more than one channel, upstream – the platform becomes a consumer of the taxonomy rather than its owner, alongside the rest of your eCommerce integrations.
eCommerce Product Taxonomy Best Practices (and the Mistakes We Fix Most)
The practices worth enforcing are short, and most of them are refusals.
- Keep attributes out of the category tree
- Cap depth at four levels
- Give every category a single canonical URL even when a product appears in several
- Name categories in buyers' language
- Populate attribute values before exposing a filter
- Version the taxonomy, so a change is a decision with a date rather than an edit someone made on a Tuesday
The recurring mistakes are equally consistent:
- Categories that mirror the ERP product-line structure
- Trees six and seven levels deep because nobody would delete a node
- Filters shown on categories where most products have no value for them
- Redirect maps written after launch
- Taxonomy owned by nobody – which is why it drifts
That last one is the real fix. Structure decays without an owner, and the owner should sit in merchandising with input from SEO and engineering, not the other way round.
Taxonomy Rebuilds in Practice
Three engagements where the structure was the work.
Bony Levy, a luxury fine jewelry brand, came to us for a BigCommerce revamp built around a complete information architecture overhaul – reconstructing the product taxonomy and expanding navigation from seven items to thirty. Revenue rose 32.12%, conversion rate 55.43%, and average order value 154.73% – see the Bony Levy rebuild.
Outdoor Limited, an ammunition retailer, migrated to BigCommerce with custom faceted filtering, AI-driven search, and review aggregation on top of a reworked catalog structure. The native filtering could not support the 12+ dynamic filters per category the catalog needed across caliber, brand, grain weight, and packaging, so we built the filter logic as a separate backend app. Orders rose 120% and revenue 177.72%, and support tickets about product findability dropped – read the Outdoor Limited build.
Anderson Pens, a fine writing instruments retailer of 36 years, needed product discovery that category browsing could not deliver, so we built ink and nib comparison tools filtering on brand, colour family, and nib width. Those tools only worked because the properties were modelled as attributes rather than buried in category names. Conversion rate rose 14% and revenue 18% – see the Anderson Pens comparison tools.
The pattern across all three: the taxonomy work was invisible in the final site, and nothing else would have worked without it.
Frequently Asked Questions
Product taxonomy is the classification system that organises a catalog into categories, subcategories, and attributes. It determines where each product sits, how categories relate to one another, and which properties describe products within them. Site search, faceted filters, breadcrumbs, and external feeds all read from it, so it sets the ceiling on how well any of those can work.
Taxonomy is the system; categorization is the act of using it. The taxonomy defines which categories exist and how they nest. Categorization is assigning an individual product to one of them. You design a taxonomy once and revise it deliberately; you categorize continuously as new products arrive.
A hierarchy is only the parent-child nesting of categories. A taxonomy includes that hierarchy plus the attribute model and the rules governing both. Note that “product hierarchy” also carries an unrelated meaning in ERP systems like SAP, where it describes internal product-line coding rather than customer-facing catalog structure.
Three levels suits most B2C catalogs; four suits most B2B and industrial ones. Beyond four, breadcrumbs become unwieldy on mobile and shoppers lose their place. If you feel you need a fifth level, the thing you are trying to express is almost always an attribute rather than a category.
Google product taxonomy is Google’s fixed list of product categories, used by Merchant Center to classify your items. You do not have to restructure your catalog around it, but you do need to map your categories to it if you run Shopping campaigns. Store that mapping as a field on the category record rather than in a manually maintained spreadsheet.
If you sell through one storefront, the platform is usually enough. If you sell across several storefronts, marketplaces, or regions, the taxonomy should live upstream in a PIM, with each channel consuming it. That way one structural change propagates everywhere instead of being re-entered per channel.
Allow it, but pick one canonical home. The product can appear in several categories for browsing, while a single canonical URL prevents duplicate-content problems and keeps analytics clean. Decide the canonical rule once and apply it consistently rather than case by case.
Start from a standard where one exists for your channel – Shopify’s Standard Product Taxonomy or Google’s list are reasonable skeletons. Then adapt. Templates are built for breadth across all merchants, so a specialist catalog will need depth and attributes the template does not anticipate.
Category pages are often a catalog’s strongest ranking assets, and taxonomy determines what those pages are, what they are called, and how internal link equity flows between them. A tree named in buyers’ language produces category pages that match real queries. A tree named after ERP product lines produces pages nobody searches for.
Category URLs, internal links, saved filters, feed mappings, and any hardcoded category references in themes or apps. Rankings are the slowest to recover, which is why the redirect map should be built before the change rather than after. Keep redirects to one hop and handle merges and splits deliberately.
Shopify provides a managed taxonomy that maps products to categories and product types, with metafields carrying the attributes that drive filtering. It gives you a consistent starting structure and helps with channel integrations. Most merchants extend it with their own attributes rather than using it unmodified.
Maintain one master taxonomy and let each storefront expose a subset with its own display labels. Storefronts may hide and rename categories; they should not restructure the master hierarchy. Once storefronts diverge structurally, product data stops reconciling across them and reporting becomes unreliable.
It depends far more on catalog size and data quality than on platform. The structural design is usually the shortest phase; auditing and cleaning existing product data, then building and testing the redirect map, takes the bulk of the time. We scope it against SKU count, channel count, and how much attribute data already exists.
Ready to Fix the Structure Under Your Catalog?
Taxonomy is the least visible part of a catalog and the one that decides whether search, filters, and feeds do their jobs. If your filters return empty pages, your Merchant Center feed keeps getting disapproved, or your category pages have stopped ranking, the structure underneath is usually where the answer is.
WebDesk Solution has spent 14+ years rebuilding catalogs on Shopify Plus, BigCommerce, Adobe Commerce, PrestaShop, and CS-Cart, for 500+ clients from our offices in New York and Toronto. We are certified partners across those platforms and a Google Partner for the paid side, which matters here because taxonomy work touches both.
Related Posts
