Using Product Brands in WooCommerce
Brands are a separate taxonomy for a reason. Folding them into the category tree looks tidy for a week and then quietly breaks navigation, filtering and every category-based rule in the store.
A brand is a taxonomy, not a category. That one decision determines whether brand pages can rank on their own, whether filtering behaves, and whether you spend next year untangling a catalogue tree in which "Running Shoes" and a manufacturer name sit as siblings.
Recent WooCommerce releases absorbed the standalone Brands extension into core, so a current install has a Products → Brands screen and a product_brand taxonomy with no extra plugin. Check for that screen first. If it exists, adding a third-party brands plugin gives you two competing taxonomies and a migration nobody asked for.
Four structures that are not interchangeable
| Structure | Question it answers | Hierarchy | Archive page |
|---|---|---|---|
Category (product_cat) |
What kind of thing is this? | Yes, and used | Yes |
Brand (product_brand) |
Who makes it? | Supported, rarely needed | Yes |
Tag (product_tag) |
What else is this about? | No | Yes |
Attribute (pa_*) |
What size, colour, material? | No | Only if archives are enabled |
The trap is using a category because it is the structure you already understand. It costs you immediately: breadcrumbs read as though the brand is a product type, the shop menu doubles in length, every product sits under two unrelated parents, and any category-scoped rule — a shipping class condition, a coupon restriction, a sales report grouped by category — starts treating a manufacturer as a product class.
Attributes fail differently. They are built for variation-forming properties and layered navigation, so a pa_brand attribute filters well but gives a thin archive that themes rarely template, and it clutters the attribute list on every product that will never vary by brand.
What the brand taxonomy actually gives you
Registering brands as their own taxonomy buys you things a category cannot:
- A dedicated archive with its own base in the permalink structure, editable description and image, so the brand page is a real landing page rather than a category listing with a manufacturer name on it.
- Assignment where you work — the product editor, Quick Edit and bulk edit, plus a column in the products list showing coverage at a glance.
- Importer and API support. Brands travel with the product CSV importer and are exposed through the REST API alongside categories and tags, which matters when you read and write products programmatically.
- Clean filtering. Product query and collection blocks can filter by a taxonomy term, so a brand becomes one more axis in product filtering without borrowing the category tree.
Migrating an existing brand structure
Most stores arrive here with brands already living as categories or as an attribute. The safe route is a round trip through the CSV importer rather than a database find-and-replace.
- Export the catalogue, including the column holding the current brand values.
- Create the brand terms first, so the import maps to existing terms rather than generating near-duplicates from inconsistent spellings.
- Re-import in update mode, matching on ID or SKU, mapping the old column to Brands. The mechanics are the same as any catalogue update — see importing products with CSV.
- Verify a sample of products in the editor before touching the old terms.
- Only then remove the old category terms or attribute.
Step five is where sites lose traffic. Old brand pages sat under the product category base and the new ones sit under the brand base, so every one of those URLs changes. Add a 301 redirect per term before deleting anything, then re-crawl the site to catch what you missed, using the approach in finding and fixing broken links.
If brand values were stored as a variation-forming attribute, check what removing it does to existing variations before you delete it. That is a different and more destructive operation than dropping a category — the rules are covered in product variations.
Displaying brands without wrecking the archive
Three placements earn their keep: the brand name on the single product page near the title, a logo strip on the shop landing page, and the brand archive itself with real copy at the top.
Everything else is usually noise. A logo on every card in the grid competes with the product image for the only decision being made on that screen; if you add one, keep it small and consistent and check what it does to card height across the grid.
Brand archives inherit the shop loop, so anything you have changed about columns, sorting or the surrounding template applies to them as well. The controls are the same ones described in customising the product archive — there is no separate brand loop to configure.
Decide the structure before the next import
If brand currently lives in the category tree, move it while there are fifty redirects to write rather than five thousand. If brand never appears in navigation, filtering or reporting — a single-brand store, for example — a plain text field on the product is cheaper than a taxonomy nobody queries.
What you should not do is keep both. A brand category and a brand taxonomy running in parallel guarantees half your products are tagged in one and half in the other, and no report will ever agree with another.
Frequently asked
- Current WooCommerce versions include brands in core, so check for a Products then Brands screen before installing anything. If it is there, a third-party brands plugin adds a second competing taxonomy and a migration you did not need.
- Neither, if a brand taxonomy is available. A category puts the manufacturer into the same tree as product types and pollutes breadcrumbs and category rules; an attribute is designed for variation-forming properties and gives you a weaker archive.
- Yes, unless you redirect them. Old brand pages live under the product category base and the new ones sit under the brand base, so add 301 redirects from each old term URL to its replacement before removing the category terms.