Product Variants SEO: URLs, Canonicals, Schema

Imagine a jacket sold in four colors and six sizes. The catalog holds twenty-four sellable items, the shopper sees one product, and a search engine may see anything from one page to twenty-four near-identical ones. Which of those it sees depends on decisions that rarely get a design review: how a selected option turns into a URL, which address declares itself the preferred one, and what the structured data says about how the pieces belong together.

This guide is written for ecommerce and marketplace developers, catalog managers and SEO owners. It starts with where variant setups go wrong, compares the URL patterns Google describes, then works through canonical choices for both single-page and multi-page catalogs. After that it covers ProductGroup markup, price and stock honesty, the question of which variants deserve their own page, and a release routine. The factual backbone is three Google Search Central documents: the ecommerce URL structure guide (Opens in a new tab), the product variant structured data documentation (Opens in a new tab) and the guide to consolidating duplicate URLs (Opens in a new tab). No search volume, ranking effect or click-through figure appears here, because none is available to cite. Advice that goes beyond those documents is labelled as judgment.

Why Variants Break Catalogs

A variant is the same underlying product differing in one or more attributes: color, size, material, pattern. The trouble is that a single idea lives in three places at once, and each place has its own rules.

The storefront shows one page with selectors. The server decides what address, if any, each selection receives. The markup tells machines how the items relate. When those three agree, a search engine can crawl the right addresses, group the right items and show the right price. When they disagree, the failures are quiet: no error page, no warning, just the wrong variant ranking, a size you cannot find, or a price in a result that does not match the page.

Typical symptoms, which the sections below address one by one:

• The same content is reachable at several addresses, so crawling effort is spent on copies.
• Links and measurements are split across addresses instead of accumulating on one.
• An unwanted variant, for example one that is out of stock, is the one that surfaces.
• Structured data disagrees with what the visitor sees.
• A variant that people really search for has no page that answers the search.

Variants are related to, but not the same as, filters. A filter narrows a list of different products; a variant is another version of one product. For the list-narrowing side of the problem see ecommerce filter URLs and faceted navigation.

Picking a URL Pattern for Each Option

Google's ecommerce URL guide is direct about variants: give each variant, meaning each combination of attributes such as size or color, its own URL. It names two patterns, a path segment such as /t-shirt/green and a query parameter such as /t-shirt?color=green. Everything else in this section is about choosing between those, and about avoiding the patterns that look like variants but are invisible to a crawler.

Fragments are not pages

If the selected color lives after a hash sign, as in /product/t-shirt#black and /product/t-shirt#white, a search engine treats both as one page. The guide states plainly that Google does not use fragment identifiers in indexing. A fragment can be handy for scrolling or for client-side state, but it cannot make a variant findable on its own.

Query parameters

Parameters are the easier pattern to retrofit onto an existing product page. The guide gives several rules for them. Write key=value pairs instead of bare values such as ?green. Do not repeat the same parameter, because Googlebot may ignore one of the values; use one parameter with comma-separated values instead. Never link internally to temporary parameters such as session IDs, tracking codes, user-relative values like a nearby location, or the current time, and prefer long-term, persistent URLs.

Path segments

A path such as /t-shirt/green reads like a page of its own and is simple to explain to a colleague. In judgment terms, it suits catalogs where variants really are separate destinations, since routing, breadcrumbs and redirects can then treat each as a first-class page. The cost is a bigger routing surface: every new attribute combination becomes a new path to maintain.

Separate product records per color

Many fashion catalogs store each color as its own product record and let the shopper pick the size on that page. Each color then has its own images, description and address, and the relationship between colors exists only in markup. Google's variant documentation handles this as the multi-page case, covered in the structured data section.

Readable, consistent addresses

The guide recommends descriptive words in paths, so /product/black-t-shirt-with-a-white-collar rather than /product/3243. It also asks for one case convention where the server treats upper and lower case the same, and for the same URL form everywhere: internal links, sitemaps and canonical tags. Its own example is a page-one suffix, which should be either always present or always absent. Apply the same discipline to variants: one spelling for each color value, one parameter order, one decision about trailing slashes.

The right-hand column is this guide's judgment, not a rule from Google.

Canonical Rules When Variants Share a Page or Split Across Pages

Duplicate handling starts from the reasons Google lists for caring: choose which address appears in results, consolidate signals such as links, simplify tracking so metrics are not split, and save crawl time for new or updated pages. All four apply to variants.

Signals, not commands

The consolidation document ranks the methods. A permanent redirect is a strong signal that the target should be canonical. A rel="canonical" annotation in the head of duplicate pages is also a strong signal and can map any number of duplicates. Listing a URL in a sitemap is a weak signal. The methods can be combined to raise the odds that your preferred address appears. None of them is mandatory; when you specify nothing, Google picks the version it considers best. The practical reading is that canonical is one voice in a chorus, and the chorus must sing the same note.

What the ecommerce guide says to do

For variants specifically, the ecommerce guide gives two instructions. If optional query parameters identify variants, make the URL without the parameter the canonical URL, which clarifies how variants relate. For products with unique variant URLs, put a canonical tag on every variant page pointing to the main product URL. The result is a consolidating setup: shoppers can land on a variant address, while the parent address collects the signals.

Judgment: a variant with its own search demand, imagery and copy can reasonably carry a self-referencing canonical instead. The guide separately advises a self-referencing canonical on all indexable pages and sitemap entries for them, but it does not tell you which variants qualify. That call belongs to the next-but-one section.

Rules that apply either way

• Use absolute URLs in canonical annotations.
• Never canonicalize to a fragment.
• Do not send conflicting canonicals through different methods, such as a sitemap URL that disagrees with the tag.
• Do not use robots.txt or the URL removal tool to pick a canonical.
• Avoid noindex as a way of choosing a canonical inside one site.
• Link internally to the canonical address.
• If JavaScript is involved, put the canonical in the HTML source and do not let scripts change it.
• Use either the HTML element or the HTTP header, not both.

For a broader checklist of canonical failures, read canonical tag issues, audit and fixes.

A fictional example

Fictional example: a home textiles shop sells one cotton duvet set. The shop's platform produces the base address plus three color-parameter addresses, all with identical copy. The team marks the parameter-free address as canonical, adds a canonical pointing to it on each color address, lists only the base address in the sitemap and updates internal links to the base address. Four signals now agree. No numbers are involved; the example only shows the order of decisions.

Describing Variant Groups in Structured Data

Google's documentation describes how to group the variants of a parent product with ProductGroup, alongside Product markup. The payoff is eligibility for variant information in merchant listing experiences, and ProductGroup can hold shared properties such as brand and reviews so they are not repeated per variant.

The vocabulary

• name is required for the group, and variant names should be more specific.
• variesBy lists the aspects that differ, using full schema.org URLs. Supported values are color, size, suggestedAge, suggestedGender, material and pattern.
• hasVariant nests Product variants under the group; alternatively, a variant can point back with isVariantOf.
• productGroupID is the parent SKU. It can sit on the group or, as inProductGroupWithID, on each variant; if both exist they must match.
• url is the group's address without variant selectors, for single-page sites only.
• Recommended extras include aggregateRating, brand, description, review and hasAdultConsideration.

Single-page sites

When variants are chosen by query parameters on one page, the documentation shows two shapes. In the first, variants are nested under the ProductGroup with hasVariant, which it calls the most compact option, and each variant's Offer carries its own URL. In the second, variants are defined separately and linked with isVariantOf, which the documentation says may be easier for a CMS to generate. In either case the group needs one distinct canonical URL, for example the base product address.

Multi-page sites

When variants live on different pages there is no single canonical group address. Every page then carries a complete ProductGroup. Each page includes its own variants in full, plus stub variants that contain only a url pointing at variants on other pages. The markup of each page must be self-contained, which in practice means your template needs to know the addresses of its sibling pages at render time.

Technical requirements from the documentation

Every variant needs a unique identifier in its markup such as sku or gtin, and every group needs a unique group ID. Product markup should include the properties needed for merchant listings or product snippets. Each variant must be preselectable through its own URL with query parameters, show the right image, price and availability, and be addable to the cart. Product markup belongs in the initial HTML where possible, because JavaScript-generated markup can make Shopping crawls less frequent and less reliable, and the server then needs capacity for the extra Google traffic.

For single-product markup in general, see the product schema markup guide.

Keeping Offers Honest

Structured data must describe what a visitor can actually see. Variants make this harder, because one page may hold many prices and availability states at once.

Each variant's offer should carry that variant's own price and address. Google's documentation requires that a variant be preselectable through its own URL and show the correct image, price and availability. A visitor who opens the red, size-medium address should see the red item, in size medium, at its real price and with its real stock state. If the page falls back to a default color on load, markup and visible content drift apart.

Stock belongs at the variant level. When one size sells out, only that variant's offer should change; the whole group should not suddenly read as unavailable. Removing or redirecting a page because a single size is temporarily gone is usually an oversized reaction. That is judgment, as the documentation contains no variant-specific stock rule. When an entire product is discontinued, the situation changes and is covered in out-of-stock and discontinued product pages.

The sturdiest way to prevent drift is a single source: let the template build both the visible interface and the JSON-LD from the same variant object, rather than reading price from one place and markup from a separate cache. Again this is engineering judgment, not a Google rule.

Fictional example: on a sneaker page, size 42 sells out while other sizes remain. The correct output marks only the size 42 offer as unavailable, shows a sold-out note next to that size and leaves the other offers untouched. The incorrect output marks the entire group unavailable or removes the page. The example has no figures; it illustrates the decision only.

Which Variants Earn a Page of Their Own

Google recommends a URL for each variant, but having a URL is not the same as deserving to rank separately. The framework in this section is judgment, offered as a way to structure a team decision.

Start from the query

If shoppers put the attribute in their search and it decides what they buy, a dedicated page becomes plausible. Color often behaves this way in furnishing and decor, where the color is the product. Size usually behaves like a filter: a shopper looking for size 42 is not looking for a different product. The split varies by category, so avoid applying a single rule to the whole catalog.

Ask whether the page is really different

A separate page is justified when it is different in substance: images specific to that color, a description that mentions the material or finish, its own reviews, a size guide for that cut. A page whose only difference is the hero image is the kind of near-duplicate content that the consolidation guide is about.

Decision grid

Nothing in the grid promises a ranking. Before committing, check your own Search Console query report to see whether the attribute phrases are actually being searched, rather than assuming.

A mixed approach

Many catalogs end up with a hybrid: sizes selectable on the parent page with the canonical on the parent, plus a short list of important colors with self-referencing canonicals and sitemap entries. A hybrid works only if someone records which variant falls into which group, otherwise the rules decay.

Selectors must be crawlable links

The ecommerce guide asks for navigation through a href links, because Googlebot may not detect navigation built purely with JavaScript, and for meaningful anchor text such as the product title rather than generic phrases. A color swatch that only fires a script cannot lead a crawler to the variant address.

Release Checklist and Ongoing Monitoring

Variant defects are silent, so build the checks into the release process. The list below combines the implementation steps in Google's variant documentation, the best practices in the consolidation guide and this guide's judgment.

Before release

1. Request each variant address directly: does it return the correct image, price and availability?
2. Is the canonical absolute, free of fragments and present in the initial HTML?
3. Does the sitemap contain only canonical addresses?
4. Do internal links point to canonical addresses?
5. Does the markup carry a group ID and unique sku or gtin per variant?
6. Do price and availability in markup come from the same source as the visible page?
7. Does the Rich Results Test report no critical errors?

What Google recommends for validation

The variant documentation lists the sequence: add the required properties, follow the guidelines, validate with the Rich Results Test and fix critical errors, deploy sample pages and inspect them with the URL Inspection tool to confirm they are not blocked by robots.txt, noindex or a login requirement, then submit a sitemap and keep it updated, optionally through the Search Console Sitemap API. It also notes that structured data does not guarantee rich results, advises checking Search Console for structured data errors and manual actions, warns that a manual action causes the page's structured data to be ignored, and says to allow several days for recrawling and reindexing.

Ongoing, watch these signals:

• Search Console indexing status for variant addresses, especially cases where Google selects a canonical other than the one you declared.
• Product snippet and merchant listing reports for error and warning trends.
• The gap between the number of sitemap URLs and the number of canonical addresses you expect.
• A manual check of random variant addresses after every catalog import or template change.
• Offer state for sold-out variants, sampled after stock syncs.

Report names inside Search Console change over time, so treat these as categories rather than exact menu labels.

Fictional example: a store redesigns its product template. The new version draws the color selector with a script and writes the canonical after page load, and the first HTML response has no canonical and markup for the default color only. By the documentation's own cautions, that combines two problems: a canonical set by JavaScript and markup missing from the initial HTML. The repair is to render the canonical and markup server-side for every variant address. The example uses no figures; it shows how such a defect hides.

Common Mistakes

• Selecting variants only with fragments: Google does not use fragments in indexing, so variants collapse into one page.
• Repeating a parameter: ?color=red&color=blue invites Googlebot to ignore one value.
• Linking to temporary parameters: session and tracking addresses breed duplicates.
• Letting canonical and sitemap disagree: two signals, two addresses.
• Leaving every variant indexable without a content difference: near-duplicates dilute the catalog.
• Folding every variant into the parent without checking demand: a color people search for may lose its page.
• Omitting group and variant IDs: without productGroupID and unique sku or gtin the grouping falls apart.
• Serving default-variant data on every variant address: price and image then contradict the selection.
• Removing a page because one size sold out: manage stock at the offer level.
• Shipping without testing: variant defects surface late.

Frequently Asked Questions

Does each color and size need its own URL?

Google's ecommerce URL guide recommends that each variant, meaning each combination of attributes such as size or color, has its own URL. A path segment like /t-shirt/green and a query parameter like /t-shirt?color=green are the two patterns it names. Fragments do not count, since Google does not use them in indexing.

Where should a variant's canonical point?

According to the ecommerce guide, if optional query parameters identify variants, the URL without the parameter should be the canonical URL, and for products with unique variant URLs each variant page can carry a canonical pointing at the main product URL. Keeping a variant with its own demand and content as a separate, self-canonical page is a judgment call.

Is ProductGroup markup required?

It is not required, but Google's documentation describes ProductGroup with variesBy, hasVariant and productGroupID as the way to group variants, and it makes products eligible for variant information in merchant listing experiences. The documentation does not guarantee rich results.

How should markup look on a multi-page catalog?

Each page carries a full ProductGroup definition, includes its own variants in full and adds stub variants with only a url for variants that live on other pages. Each page's markup must be self-contained.

Where must price and stock agree?

Each variant's own address should show the right image, price and availability, allow adding to the cart, and match the offer in the markup. Product markup is best placed in the initial HTML.

Conclusion

Handling variants well is a sequence of decisions rather than a single setting. Give every variant a persistent, readable address and do not rely on fragments. Line up the canonical signals so the tag, the sitemap, internal links and any redirect all name the same address. Describe the group with ProductGroup, each item with Product and each variant with a unique sku or gtin. Write price and availability from one source into both the page and the markup. Then decide which variants earn their own page from your own query data and from real differences in content, not from a rule of thumb. None of this guarantees a ranking or a rich result; the aim is that a search engine and a shopper see the same product on the same page.

If your variant-heavy catalog needs original product and category copy that explains color, material and use, Akua Adforce offers SEO content writing; scope and terms are listed on the product page.