SKU and URL strategy for product variants

Decide whether variants stay on one canonical product page or merit separate landing pages. This guide gives a SKU naming pattern, the tests to run in WooCommerce and the checks to make before publishing variant links.

Editorial illustration: pale mint background with an off‑white product browser card and overlapping product SKU cards, navy and teal accents, soft shadows.

If two T-shirt colours differ only in fabric colour and size, keep one canonical product page and give each variation its own SKU for inventory and feeds. Publish a distinct landing URL for a variant only when the variant is materially different — different description, price band, shipping or customer audience. The rest of this guide shows how to set a deterministic SKU convention, how to confirm WooCommerce exposes per-variation SKUs in exports and APIs, and how to test whether your theme or plugin produces a shareable variant URL.

In this guide

Decide your strategy

Make a decision per product, not per store. Use one canonical product page when variants are routine customer choices (colour, size, minor trim). Keep the SKU authoritative at the variation level so orders, packing slips and marketplace feeds can identify the exact item.

Consider separate public pages when a variant is materially different: it needs a different product description, unique shipping rules, markedly different images, or it targets a separate keyword/audience. Separate pages should not be created just to have more indexed URLs.

Official WooCommerce docs explain variable products and the normal workflow for variations: WooCommerce variable product guide.

Confirm variation SKUs in the admin

  1. Open the product in the WooCommerce Product editor and switch to the Variations panel.
  2. For each variation, check the SKU field, price and stock controls. Each SKU should be unique across the store—WooCommerce enforces store‑wide SKU uniqueness in the editor. See the product editor reference: Product editor settings.
  3. Record one test product’s parent ID, variation IDs and SKUs so you can use them in later export/API checks.

SKU naming convention (copyable pattern)

Pick a deterministic pattern and apply it consistently. A clear, machine-friendly convention keeps inventory, packing slips and marketplace feeds in sync.

Pattern example: BASESKU-ATTR1-ATTR2[-OPTIONALCODE]
Example: TSH-100-RED-S
Rules:
- Base SKU: stable product identifier (TSH-100)
- Attributes in fixed order (colour then size)
- Uppercase letters, hyphen separator
- Avoid spaces and punctuation other than hyphen
- Reserve an optional suffix for marketplace or region code (e.g., -EU)

If you have many products, consider a bulk generator extension to apply the pattern: WooCommerce Bulk SKU Generator.

Verify exports and API fields

Confirm how variation-level fields appear to integrations.

  1. Export a small CSV of the test product (or use the REST API) and check that each variation row includes either a separate SKU column and the post_parent/variation row indicators. WooCommerce documents CSV import/export layout: Import & export docs.
  2. Use the variations REST resource to confirm the fields your integration needs are present. The REST endpoint /wp-json/wc/v3/products/<product_id>/variations returns variation resources with fields such as manage_stock, stock_quantity, stock_status and sku. See the API reference: Product variations REST API.
  3. If a marketplace feed or shortcode appears to output the parent SKU rather than the variation SKU, test a sample order and check the exported order CSV or feed to see which SKU was used. If the behaviour is wrong, consult the plugin’s docs or author—some feed tools have settings to include variation SKUs.

Test front-end variant URLs

Front-end behaviour is theme- and plugin-dependent. There is no single WooCommerce-guaranteed permalink format for selected variants, so you must test your own store.

  1. Open the product page in a browser. Select a variation (colour/size).
  2. Watch the address bar and record whether the URL changes in one of these ways:
    • URL fragment (example: /product/tshirt#red-s)
    • Query parameter (example: /product/tshirt?variation_id=123 or ?attribute_pa_color=red)
    • Path change (rare with core WooCommerce; usually plugin-driven)
    • No visible URL change — selection only stored in JavaScript state/history API
  3. Open a private/incognito window and paste the observed URL. Does the page load with that variation pre-selected? If yes, the URL is shareable; if not, the selection is probably client-only and won’t survive bookmarks or social links.
  4. Repeat the test with any variation-permalink or UX plugin active. Test on desktop and mobile.

Because this behaviour depends on theme and plugins, test before relying on shared variant links. The WooCommerce variable product guide describes how variations are configured but not how every theme exposes shareable variant URLs: Variable products.

Publishing variant pages & structured data

If you decide variants should have separate public pages, ensure each page has unique metadata, clear content and correct structured data. Use the schema.org sku property on whatever page represents the purchasable item so crawlers and feeds can associate the SKU with that page: schema.org/Product.

Prefer explicit pages for materially different items. If you use canonical tags to reduce duplicate content, make sure the canonical points to the intended primary page and that structured data reflects the public SKU shown on that page.

When to keep one canonical product When to publish variant landing pages
Variants differ only by colour/size, same price, same shipping and same marketing message. Variant has different description, pricing, shipping or targets a distinct audience/keyword.
Inventory and order systems require distinct SKUs, but customers can choose on one page. Each variant needs unique title/meta or rich content to earn search visibility.
You want simpler navigation and fewer pages to maintain. Marketplaces or campaigns require stable, shareable URLs for each purchasable item.

Quick checklist

  • Decide strategy for one representative product (single page vs separate pages).
  • Confirm each variation has a unique SKU in Products → Variations (admin).
  • Apply a deterministic SKU naming pattern consistently across similar products.
  • Export CSV and call the REST /variations endpoint to confirm variation-level sku, stock and id fields are present.
  • Test front-end selection in a private window to see if the URL preselects a variation (fragment/query/path or not).
  • If publishing variant pages, add unique metadata and schema.org sku on each page.

Fictional example

Imagine a T-shirt product with base SKU TSH-100 and two variants. The store keeps one canonical product page at /product/tshirt but uses per-variation SKUs for inventory and packing slips:

TSH-100-RED-S
TSH-100-BLU-M

The shop owner tests the front-end and sees that selecting a colour+size updates the URL to /product/tshirt?variation_id=456. Pasting that URL into a private window opens the product with the same variation pre-selected, so those URLs are usable in marketing links. If that pre-selection had not worked, the owner would keep the single canonical page for public links and rely on the variation SKUs for inventory and feeds.

Further reading

Decide the strategy for a single representative product and run the admin export/API and front-end URL checks above. Those three observations (variation SKU present, variation fields visible in exports/API, and whether a shareable URL pre-selects the variant) give you the evidence to act with confidence.