Attributes are the least visible part of a WooCommerce store, yet they do the most work. They power the filters on category pages, create product variations, fill the spec table on the product page and, by extension, the feed sent to Google. A well-designed attribute structure barely gets noticed. A sloppy one always shows eventually: a “Color” filter offering “Blue”, “blue” and “Navy blue” side by side, or a spec table where weight is sometimes in grams and sometimes in kilos.
The question that comes up most often is simple: should you create global attributes or custom attributes? The answer depends less on WooCommerce than on what you intend to do with the information.
What an attribute is in WooCommerce
An attribute describes a characteristic of a product. It consists of a name, such as “Material”, and values that WooCommerce calls terms: “Solid oak”, “Teak”, “Aluminum”. Where a category places a product in a family and a tag associates it with a theme, an attribute describes what the item is, in a way that can be compared from one product to the next.
Take a fictional outdoor furniture store, Atelier Sorel (atelier-sorel.example). A garden table there carries a category (“Tables”), possibly some tags (“Riviera Collection”), and a series of attributes: tabletop material, frame material, length, number of seats, finish. These attributes are what will let a visitor filter for “teak tables for eight people”, and what lets the product page display a clean spec table.
WooCommerce offers two ways to create an attribute. The official documentation draws a clear line: attributes can be defined globally, so they are available on every product in the store, or individually, at the product level, in which case they exist only for that product.
Global attributes vs custom attributes: the real difference
A global attribute is created under Products > Attributes. Technically, WooCommerce turns it into a taxonomy, prefixed with pa_, where each term is registered once and then linked to the relevant products. A custom attribute is created directly in the Attributes tab of the product page: you type a name, then values separated by a vertical bar (|). It is stored with the product and exists nowhere else.
This difference in storage has practical consequences.
| Global attribute | Custom attribute | |
|---|---|---|
| Reusable on other products | Yes, with the same terms | No, re-entered every time |
| Store filters (filter blocks, layered navigation) | Yes | No |
| Archive pages per value | Possible, if the option is enabled | No |
| Variations | Yes | Yes |
| Correcting a value | Once, for the whole catalog | Product by product |
The deciding factor is filtering. A custom attribute can be displayed on the product page and used to create variations, but it cannot power the store’s filters, since it is not a shared taxonomy. A store that entered all its colors as custom attributes discovers this detail the day it wants to add a color filter.
Choosing between global and custom
The rule comes down to one question: will this information be compared from one product to another?
If so, the attribute should be global. That covers everything used for filtering (material, color, size, capacity, power), everything that creates recurring variations, as well as everything that will go into a product feed. The color of an Atelier Sorel chair must use the same terms as the color of a table, otherwise the filter cannot bring them together.
If the information belongs to a single product, a custom attribute is enough. A compatible spare-part reference, a limited-edition note, an assembly detail that will never appear on another product page: turning these into a global taxonomy would clutter the admin without giving the visitor anything.
In between, the temptation is to create everything as global “just in case”. That is the opposite mistake. A global attribute made up only of unique terms, one per product, filters nothing and weighs down the editing screen. Twenty global attributes used everywhere beat a hundred used once.
Building a structure that lasts
An attribute structure is designed before data entry begins, ideally in a spreadsheet listing each attribute, its definition, its unit and its permitted terms. A few principles prevent most of the rework.
One attribute, one dimension
“Dimensions: 180 x 90 x 75 cm” is readable for a human but useless for a filter. Three attributes, “Length”, “Width” and “Height”, work better, or at the very least isolate the dimension customers actually filter on. Likewise, “Material” often becomes “Tabletop material” and “Frame material” as soon as a product combines several.
Normalized terms
Each term should exist in a single form. Fix the capitalization (“Solid oak”, never “solid Oak”), singular or plural, the unit (“75 cm” everywhere, not “0.75 m” on some pages) and how numbers are written. For numeric attributes, WooCommerce offers numeric sorting of terms, which avoids seeing “10 seats” listed before “4 seats”.
Plain names and short slugs
The attribute name is displayed as is on the product page: it must be understandable without context. The slug serves as a technical identifier and appears in filter URLs. WooCommerce limits it to 28 bytes and rejects certain words reserved by WordPress, such as “page”, “category” or “search”. A short slug, without accented characters, chosen once and for all, avoids unpleasant surprises during a CSV import.
No overlap between attributes and categories
If “Tables” is a category, there is no reason to create a “Furniture type” attribute with the term “Table”. Each piece of information should have exactly one place where it lives.
Attributes and variations
A variable product is built on its attributes: each variation corresponds to a combination of terms, such as “Teak / 180 cm” and “Teak / 220 cm”. In the product’s Attributes tab, you need to tick the box that allows the attribute to be used for variations, then generate the variations from the Variations tab.
The WooCommerce documentation recommends defining every attribute for each variation, rather than letting a variation stand for any value of an attribute. In that case, WooCommerce picks the first matching variation in list order, which can display an unexpected price or stock level if the order was not carefully set.
Attributes that do not vary, such as the frame material when it is identical across all versions, remain plain descriptive attributes, visible on the product page. There is no need to declare them as variation attributes.
What attributes feed beyond the product page
A properly filled attribute serves far beyond the spec table.
Filters and archives. Global attributes feed WooCommerce’s filter blocks and, if the archive option is enabled, pages listing every product for a given value. This is the foundation of faceted navigation.
The Google Merchant Center feed. For apparel in several markets, France among them, Google requires color, size, gender and age group. A feed built from normalized attributes fills itself almost automatically; a feed built from free text gets corrected by hand. The subject is covered in detail in the article on Google Merchant Center and WooCommerce.
Structured data. For merchant listings, Google recommends properties such as color, material or size. WooCommerce’s native product markup does not expose them, but an SEO plugin or supplementary markup can pull them from the attributes. They still need to be clean: that is the subject of the article on Product structured data in WooCommerce.
Copywriting. A description written from verified attributes stays consistent with the spec table. Conversely, a text that announces a “teak tabletop” when the attribute says “acacia” destroys trust in a single line.
Auditing an existing structure
On a store that is already live, the structure has often grown through successive imports. An audit runs in four steps.
- Export. The product CSV export shows every attribute, global or not, with its values. Custom attributes that should be global are easy to spot there.
- Group. List the terms for each attribute and identify variants of the same value: capitalization, plural, typo, unit.
- Merge. Choose the reference form, reassign the products, then delete the orphaned terms. On a large catalog, this step is done by import rather than by hand.
- Fill in. The longest part remains: filling the empty attributes from the supplier’s spec sheets. This is also the moment to note where each value comes from, so it can be justified later.
An attribute structure is never final. A new supplier, a new range or a new sales channel will call for adjustments. What matters is that every addition follows the rules written down at the start.
Attributes sourced before they are written up
Fichewise starts from the attributes to write product pages, not the other way around. Each value is extracted from supplier documents, manufacturer pages or competitor pages, then paired with a reliability score and its sources; when two sources disagree, the merchant decides. The retained values are written into WooCommerce’s global attributes, which makes them available for filters, the Shopping feed and markup. The documentation describes how this works step by step.