Beauty catalogs combine product type, skin or hair concern, format, shade, finish, ingredient information, size, and claims. A flat list of product names quickly becomes difficult to browse, filter, localize, and publish to channels. A category model with controlled attributes makes the catalog easier to merchandise and maintain.

A practical top-level structure

Most beauty catalogs can begin with product families such as skincare, makeup, haircare, fragrance, bath and body, tools and accessories, and gift sets. The exact structure should follow the way customers shop and the range the business actually sells.

Keep product family separate from concern, ingredient, finish, and routine step. For example, “Skincare > Cleansers” is a product type. “Sensitive skin”, “fragrance-free”, and “morning routine” are useful attributes or merchandising collections.

Skincare attributes

  • Product type: cleanser, toner, serum, moisturiser, mask, sunscreen, treatment.
  • Skin concern: dryness, oiliness, sensitivity, redness, blemishes, uneven tone.
  • Skin type: dry, oily, combination, normal, sensitive.
  • Format: balm, cream, gel, lotion, oil, mist, stick, powder.
  • Size, net content, application area, routine step, and usage frequency.
  • Controlled claims and compliance-reviewed ingredient data.

Makeup attributes

Makeup shoppers often need shade and finish before they need brand or campaign information. Model product type, shade family, undertone, finish, coverage, waterproof status, and applicator separately. A foundation’s shade should be a variant or controlled option where inventory and price differ; a general finish may remain a product attribute.

Haircare and fragrance attributes

Haircare may need hair type, concern, routine step, hold, texture, and treatment type. Fragrance may need concentration, scent family, notes, gender positioning if used by the business, size, and set contents. Do not force every merchandising concept into the main category tree.

Claims, ingredients, and compliance

Claims such as “vegan”, “dermatologist tested”, “clean”, or “organic” should be governed values with evidence and an owner. They should not be free-text tags added by individual editors. Store source evidence and review dates where the claim can change.

Keep ingredients structured where filters or legal review need them, but avoid treating an ingredient list as a replacement for approved product content. The same product may need different claims or wording by market.

Build category-specific filters

Do not expose every beauty field on every category. A fragrance shopper may need scent family, concentration, and size. A skincare shopper may need concern, skin type, format, and ingredient. A makeup shopper may need shade, finish, coverage, and undertone.

Use canonical values and synonyms so “moisturizer” and “moisturiser” can support the same discovery experience where appropriate. The product attributes guide explains how to build filters that help people decide rather than overwhelm them.

Support channel publishing

Maintain a source taxonomy, then map it to channel categories and required attributes. Google Shopping, storefront search, and marketplaces may each need different representations. Validate product type, identifiers, price, availability, images, and landing-page data before publishing.

Use the Completeness Checker for required fields and the fashion and apparel PIM guide for broader variant and syndication patterns.

A worked example: one beauty taxonomy from root to filter

The structure below is illustrative. Rename branches to match how your customers shop, but keep the principle: each level answers one question, and anything that is a property rather than a place in the tree becomes an attribute.

  • Skincare > Cleansers > Cream cleansers, gel cleansers, cleansing oils and balms, micellar waters
  • Skincare > Moisturisers > Day creams, night creams, gel moisturisers, face oils
  • Skincare > Sun care > Face sunscreen, body sunscreen, after-sun
  • Makeup > Face > Foundation, concealer, powder, blush, bronzer
  • Makeup > Eyes > Mascara, eyeliner, eyeshadow, brow
  • Haircare > Shampoo, conditioner, treatments, styling
  • Fragrance > Eau de parfum, eau de toilette, body mist, discovery sets

Notice what is not in the tree: “sensitive skin”, “vegan”, “morning routine”, “bestsellers”. Those are attributes or collections. Putting them in the hierarchy forces a product to live in one place only, and the same moisturiser cannot sit under both “Moisturisers” and “Sensitive skin” without duplication.

Attribute, variant or collection? A decision table

Most beauty catalog errors come from putting a value in the wrong layer. Use this table when a new field is requested.

ConceptLayerWhy
Foundation shadeVariant optionChanges the purchasable item, usually has its own SKU, GTIN, image and stock.
Size or net content (30 ml, 50 ml)Variant optionChanges price and SKU. Store the numeric value and unit separately.
Skin type, skin concernProduct attribute (multi-value)A decision aid for filters; does not change the SKU.
Finish, coverage, undertoneProduct or variant attributeFinish is often product-level; undertone is often shade-level. Decide once per category.
Vegan, cruelty-free, fragrance-freeGoverned claimNeeds evidence, owner and review date. Not a free-text tag.
Summer glow edit, gift guideCollectionCampaign or merchandising grouping that changes often.
INCI ingredient listStructured field per marketLegal content that may differ by formulation or region.

Handling regional differences

The same product can carry different claims, ingredient wording, warnings and permitted marketing language depending on the market it is sold in. Keep the global product record and the market-specific content separate. A claim approved for one market should not automatically publish in another. At minimum, store for each regulated field: the value, the market, the evidence reference, the approver and the next review date. This is also what lets a compliance reviewer filter for “every product with an organic claim that has not been reviewed this year” without opening a spreadsheet.

Mapping to channel categories

Your internal tree should be the source of truth; each channel gets an explicit mapping. For Google Shopping, map each leaf to the closest Google product category rather than renaming your own categories to match. A leaf such as “Cream cleansers” can map to a broader Google category, and that is fine. What matters is that every leaf maps somewhere, that the mapping has an owner, and that unmapped products show up in an exception queue. For a step-by-step view of the mapping process, see the category mapping guide and the comparison of Google categories and internal taxonomy .

Common beauty taxonomy mistakes

  • Shade names as free text. “Warm beige”, “beige warm” and “W. Beige” become three filter values. Use a controlled shade family plus a display name.
  • One filter set for every category. Showing “scent family” on mascara makes the filter panel look broken.
  • Kits and gift sets modeled as ordinary products. Keep the component relationships so stock, ingredients and claims can roll up correctly.
  • Mixing product type and concern. “Acne treatments” as a category sits beside “Serums” and breaks sibling consistency.
  • Claims added by whoever edits the page. Without ownership, the claims list drifts.

Beauty taxonomy FAQ

Should concern (for example “dry skin”) be a category or an attribute?

An attribute. Concerns overlap, and a product can address several. Use a multi-value attribute and expose it as a filter or a curated collection.

How deep should the hierarchy go?

Three levels is usually enough: family, product group, product type. Anything finer is normally an attribute value.

How do I handle shades across hundreds of SKUs?

Model shade as a variant option with a controlled shade family, an undertone value and a display name. Require one image per shade and validate it before publishing.

Do I need a different taxonomy for each marketplace?

No. Keep one internal taxonomy and maintain a separate, versioned mapping per channel.

Build the attribute template for each beauty category

An attribute template lists the fields that apply to every product in a category, whether each is required, its data type, and its allowed values. Writing the template before importing data prevents most of the clean-up work later.

FieldSkincareMakeupHaircareFragrance
Product typeRequiredRequiredRequiredRequired
Net content and unitRequiredRequiredRequiredRequired
Skin or hair typeRequiredOptionalRequiredn/a
Shade family and undertonen/aRequired (face)Optional (colour)n/a
Finish and coveragen/aRequired (face)n/an/a
Scent family and concentrationOptionaln/aOptionalRequired
Ingredient listRequiredRequiredRequiredRequired
Claims with evidenceIf usedIf usedIf usedIf used

Treat “Required” as a publishing rule. A foundation without a shade family should not reach the storefront or a feed. Validate each template with the Completeness Checker before a large import.

Plan for kits, minis and refills

Beauty ranges produce many related items: travel sizes, refills, bundles and gift sets. Decide up front whether each is a variant of the main product (same product, different size), a separate product that links back (a refill with its own identifiers), or a bundle with component relationships (a gift set containing three items). Getting this wrong makes stock, pricing and ingredient reporting unreliable.

Beauty taxonomy quality checklist

  • Every product has one primary product type.
  • Shade, size, and pack options are modeled consistently.
  • Claims are controlled and evidence-backed.
  • Filters are category-specific and mobile-friendly.
  • Ingredient and compliance values have owners and review dates.
  • Channel mappings and required fields are tested before release.
Structured product categories and attributes in an ecommerce catalog

Structured product categories and attributes in an ecommerce catalog