Product variants SEO is the set of decisions about how size, colour, capacity and similar options are exposed to search engines. The core question is simple to state and easy to get wrong: should each variant be its own indexable page, or should one page represent the product?
Get it wrong in one direction and you have twenty near-identical pages competing with each other. Get it wrong in the other and you miss genuine demand for a specific variant that people actually search for.
The default, and when to depart from it
For most catalogues, one indexable product page with variants selectable on it is correct. Variants differ in a single attribute, share descriptions and images, and would produce near-duplicate pages.
Departing from that default is justified when a variant has genuine independent demand.
- People search for the variant specifically, using terms that name it.
- The variant has meaningfully different content, specifications or use cases.
- It is priced or positioned distinctly enough to warrant its own listing.
- Competitors rank separate pages for it, which indicates the search results expect that shape.
Colour variants of a garment rarely qualify. Capacity variants of a device frequently do, because people search for the capacity by name.
Implementing one page for many variants
- Serve one canonical URL and select variants client-side or via parameters that canonicalise back to it.
- Ensure the default variant’s content, price and availability render server-side, so the page is not empty without JavaScript.
- Where variants use parameter URLs, canonical them to the base product rather than leaving them indexable.
- Include variant terminology in the page copy so the page can match variant-level queries.
- Keep structured data on the canonical page, expressing the price range across variants where relevant. See product schema SEO.
Implementing separate variant pages
Where separate pages are justified, they have to earn their independence rather than merely exist.
- Give each genuinely distinct content, not a template with one word changed.
- Link variants to each other so people can move between them.
- Ensure each is reachable from a category page, not only from a sibling variant.
- Watch for the pages competing with each other for the general product query.
- Consider a parent page owning the general term, with variants owning their specific ones.
Common faults
- Every colour indexed separately, producing near-duplicate pages that split the signal.
- Variant parameter URLs left indexable with no canonical, multiplying the catalogue.
- Variant content rendered only in JavaScript, leaving the indexed page thin.
- Out-of-stock variants returning 404 while the product remains available.
- Structured data describing only one variant’s price on a page offering a range.
- Discontinued variants left live and unlinked rather than redirected.
Frequently asked questions
Should each colour have its own page?
Usually not. Colour variants rarely attract distinct search demand and produce near-duplicate pages that compete with each other. Use one page with colour selection, unless people genuinely search for the colour by name.
What about size variants?
Almost never separate pages. Size is a selection, not a distinct product, and separate size pages are among the fastest ways to bloat a catalogue.
How do I handle out-of-stock variants?
Keep the product page live and indicate the variant is unavailable. Returning 404 for a temporarily unavailable size removes a page that is about to be valuable again.
Should variants appear in structured data?
Yes, on the canonical product page. Express the price range across variants rather than a single variant’s price, so the markup matches what the page actually offers.
Consulting CTA
If your variant pages are competing with each other, or variant URLs are multiplying in the index, book an SEO consultation to agree an indexing model for your catalogue.