Copy the link for a blue, medium jacket and open it in a private window. Do you still see blue and medium, the correct image and price, the correct stock state, and a button that adds that exact variant to the cart? If not, a variant URL exists in name only.
Google's product-variant documentation describes two workable architectures. A single-page product lets people select variants without a page reload, often with parameters in a link. A multi-page product gives variants separate pages, such as color pages with size parameters. The right choice depends on the browsing experience and the data model; adding markup cannot repair a link that opens the wrong state.
Pick one architecture before writing canonical rules
| Architecture | What the link should do | Google's markup and canonical guidance |
|---|---|---|
| One product page with selectable variants | A parameterized link can preselect a variant while selection stays on the same page. | Google says the overall ProductGroup should have one distinct canonical URL, usually the base URL without a preselected variant. |
| Distinct variant pages | Each page is an equally usable destination with its own selected variant. | Google says there is no single canonical URL for the group in this arrangement; each page needs full, self-contained markup for its entities. |
The second row is easily missed. Making every meaningful color page canonicalize to the same base page can contradict a multi-page design in which each color is meant to stand alone. Conversely, treating every size parameter as a separate canonical destination can create many near-duplicate URLs when the actual experience is one page. Document which state is a page and which is a selection before setting canonicals, feeds, and internal links.
Google's guidance also says each variant must be directly preselectable through a distinct URL, showing its image, price, availability, and add-to-cart option. Use ProductGroup and variant Product data to describe the relationship, with values such as variesBy, hasVariant, and the relevant identifiers. Google recommends product markup in the initial HTML for merchants aiming at Shopping results, particularly when price or stock changes quickly. These are eligibility and understanding aids, not guarantees of a rich result.
Test the commercial path, not just the schema
Run a small matrix: one in-stock color and size, one unavailable combination, and one variant shared from a category or search result. For each, open the URL fresh, check the visible title and image, compare price and availability to the product data, select another variant, go back, and inspect the cart line. Then check the page source or rendered HTML and canonical URL against the chosen architecture. A product feed, if used, should agree with the on-page offer.
The existing article on a wrong variant appearing in the cart addresses transaction state after selection. This article addresses whether a buyer or crawler can reach the intended variant through a stable URL in the first place. A robust implementation needs both checks.
ARCHV can scope the URL and content plan for a commerce experience, but storefront platform constraints, feeds, and variant data require a technical review. Bring the product catalog and one problematic variant URL to a website estimate so the plan starts with a real purchase path.