How to Choose URLs and Canonicals for Product Variants

When a product comes in options such as colors or sizes, choose URLs that let shoppers and search engines reach the option they want. Then choose a canonical URL, the URL you want search results to show for that page. A canonical is a signal that tells search engines which URL should stand for duplicate or very similar pages. It does not guarantee that Google will select that URL.

For a product with selectable colors or sizes, a stable base product URL is a useful default. Add a distinct, shareable URL for each selected variant when shoppers need to link directly to it. If variant pages differ only in details such as color, price, or availability, point their canonicals to the base product URL. Treat variants as separate search landing pages only when they serve distinct purposes and have genuinely distinct page content.

Give each variant a stable URL

A variant URL should load the option it names. For example, /coat?color=green should open the coat with green selected and show the matching image and price, state whether it is available, and provide the purchase option. Google recommends making each variant identifiable by its own URL, using either a path such as /coat/green or a named query parameter such as ?color=green. Its ecommerce URL guidance also recommends avoiding temporary parameters, such as session IDs, in URLs you use for internal links.

Check the URL by opening it directly in a fresh browser session. Confirm that the selection stays in place after the page loads and that the shopper can buy the selected option. A URL that opens the default color instead, or loses the selection after a reload, does not reliably address that variant.

A URL that changes the selector without reloading the page can still provide a shareable variant address, as long as the address reliably restores the selection. Do not use a fragment such as #green as the only way to distinguish a variant for search. Google generally does not use URL fragments to identify separately indexed pages.

Choose a canonical based on the search page you want

If variants are alternative views of one product page, use the base product URL as the canonical for variant URLs. For example, if /coat?color=green and /coat?color=blue show the same coat with different selections, the base URL /coat is the straightforward choice for the representative search result. Google recommends this approach when optional URL parameters identify product variants.

A canonical tag tells Google which URL you prefer, but Google can choose a different one. Google considers other signals, including page content and redirects. It also considers sitemap entries. Keep the canonical, internal links, and sitemap consistent with the URL you want to represent the product. Google’s explanation of canonical selection describes how it chooses a representative from duplicate or very similar pages.

The decision gets less clear when each variant has its own page and the store wants each page to appear independently in search. Google’s guidance on product information formatted for search engines, product-variant structured data guidance, describes a setup with a separate page for each variant and no single canonical URL for the ProductGroup entity. That statement concerns the product group in structured data. It does not, by itself, settle which HTML canonical each page should use. Google’s separate ecommerce URL guidance recommends a product canonical on variant pages.

Use the base product canonical when variant pages mostly repeat the same product information and differ mainly in the selected option. Consider separate search pages when each variant serves a distinct search purpose and the page provides distinct primary information. Google does not publish a minimum content difference that guarantees separate indexing, so verify the result in Search Console rather than assuming a self-referencing canonical will secure it.

Product-variant structured data helps Google understand which variants belong to a product group. If you use it, give each variant a unique identifier and keep its details consistent with the page. For separate variant pages, follow Google’s variant markup guidance for the entities on each page. Correct markup can make a page eligible for supported search features, but it does not guarantee a rich result or a ranking improvement.

Check the signals shoppers and Google receive

Review a representative URL for each type of variant page. Check that the URL loads the right option, returns the intended page, and does not redirect shoppers to a generic or unrelated product. Then inspect the canonical in the page’s HTML and compare it with the URLs used in internal links and the sitemap. If JavaScript changes the selection or canonical, inspect the original HTML and the page after JavaScript runs. Google’s JavaScript SEO guidance explains why the page after JavaScript runs matters.

Use URL Inspection in Search Console to compare the canonical your page declares with the canonical Google selected. If they differ, check whether the pages are too similar or whether redirects, links, sitemap entries, or rendered markup point to conflicting URLs. Google’s canonical troubleshooting guidance says Google can take time to review changes. A group of pages it treats as duplicates can persist for up to two weeks. That is a troubleshooting timeframe, not a guarantee that every change will be processed within that period.

Keep product variants separate from category filters. A product URL that selects a color describes a specific product option; a category URL filtered by color, brand, and price describes a changing set of products. Filters can generate many URL combinations. Decide which filtered pages deserve search visibility and manage the rest as a crawl-control issue. Google’s guidance on faceted navigation warns that canonical tags alone are generally less effective for controlling crawling than its primary crawl-control options.

If you submit products through Merchant Center, distinguish the shopper’s landing-page URL from the feed’s canonical_link attribute. A landing-page URL can open a preselected variant. Merchant Center describes canonical_link as the URL Google should associate with the product in Search and recommends a stable base product URL for that purpose. See Google’s Merchant Center instructions.

Avoid canonical and crawling shortcuts

Do not point every variant to the homepage or to a different product. A canonical should represent the same or very similar content. Do not block a URL in robots.txt expecting that to tell Google which duplicate to use; blocking controls crawling, and Google may still index the URL without seeing its contents. Likewise, noindex removes a page from Search rather than selecting a preferred canonical. Google explains these distinctions in its guidance on specifying canonicals.

The available Google documentation explains how to set up variant URLs, canonicals, and structured data. It does not quantify a ranking or traffic advantage for one variant URL design, or define a content threshold that guarantees independent indexing. It also establishes no special AI-search benefit from choosing a particular variant URL. Accurate, accessible product information remains the sound implementation goal, without a promise of a particular search result.

Key Takeaways

• Make variants addressable: Use stable URLs that open the intended selection. Each URL should also show its image, price, availability, and purchase option.
• Consolidate near-duplicates: When variant pages differ mainly by selection, use the base product URL as their canonical.
• Separate markup from canonicals: A ProductGroup in structured data and an HTML canonical serve different purposes; Google’s multi-page markup guidance does not resolve every indexing decision.
• Verify Google’s choice: Compare declared and selected canonicals in Search Console, and check redirects, internal links, sitemap entries, and rendered pages.
• Manage filters separately: Category filters can create large URL spaces, so canonical tags alone do not replace a crawl-control plan.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com