Structured data for images and products
Structured data is where your images acquire meaning that no amount of pixel quality can supply. A photograph tells a machine what a thing looks like. Markup tells it what the thing is, what it costs, whether it can be bought, and how it relates to everything else you sell.
In section 3, I showed what this looks like in practice: the difference between an image result that carries a brand, a price and a stock status, and one that carries a title and a link. This section covers what to implement, what has been retired, and — in one consolidated table — the actual image specifications, verified against current documentation rather than inherited from older guidance.
What died
A significant amount of structured data advice still circulating refers to rich results that no longer exist. The retirement schedule since 2023:
Type | Status |
|---|---|
HowTo | Deprecated — mobile August 2023, desktop September 2023 |
FAQ | Restricted to government and health sites August 2023; fully deprecated 7 May 2026. Search Console reporting and Rich Results Test support removed June 2026; API support August 2026 |
Book Actions | Retired June 2025 |
Course Info | Retired June 2025 |
Claim Review | Retired June 2025 |
Estimated Salary | Retired June 2025 |
Learning Video | Retired June 2025 |
Special Announcement | Retired June 2025 |
Vehicle Listing | Retired June 2025 |
Two points worth drawing out.
Deprecated is not the same as harmful. Markup for a retired type no longer produces a rich result, but it is not a penalty, and it still describes your content to systems that parse schema.org, including AI systems that consume structured data as a signal rather than as a rich-result trigger. There is no urgency to strip it. There is, however, no reason to build new implementations against it.
The direction of travel is consistent. Google has retired the types that produced decorative enhancements and retained — indeed heavily extended — the types that describe commerce. Product markup has gained variants, loyalty pricing, return policies, shipping policies, certifications and 3D models in the same period that nine other types were removed. That asymmetry is the clearest available signal of where Google’s structured data investment sits.
Turn visual search data into actionable insights
Advanced Web Ranking gives you a clearer view of visual search performance, from rankings in Google Images to image results in Universal SERPs and visibility across major AI engines.
Product snippets vs merchant listings
Product markup now splits into two classes, and choosing the wrong one is a common and consequential error.
Product snippets are for pages where the product cannot be bought directly — editorial reviews, comparison articles, aggregator pages. This class supports richer review handling, including pros and cons.
Merchant listings are for pages where the customer can purchase from you. This class supports detailed commercial data: pricing structures, apparel sizing, shipping and return policy.
There is overlap between them, but the eligibility differences are real. Merchant listings require a nested Offer — not AggregateOffer — because you must be the seller, and they require a price greater than zero. Merchant listing markup is what makes a page eligible for the shopping knowledge panel, Google Images, popular product results and product snippets.
Google’s own recommendation is worth quoting plainly: providing both page structured data and a Merchant Center feed maximizes eligibility and helps Google verify your data. These are not alternatives. The feed and the markup corroborate each other.
Required properties for a merchant listing:
name
image — repeated ImageObject or URL
offers — with price (or priceSpecification.price) and priceCurrency
Recommended, in rough order of commercial value:
availability · brand.name · description · gtin (most specific applicable variant) · sku · mpn · aggregateRating · itemCondition · color · material · pattern · size · audience · hasCertification · hasMerchantReturnPolicy · shippingDetails
Note how many of those are the attributes multisearch and AI refinement queries operate on — color, material, size, pattern, condition. Before, I argued that visibility in AI shopping is decided across the refinement rather than at the first answer. This list is that argument’s implementation detail.
Three technical constraints must be considered:
Product rich results support pages focused on a single product (or variants of one product). Category and listing pages are not eligible.
Multiple currencies — Google asks for a distinct URL per currency. The merchant listing guidelines are explicit: a product sold in Canadian and US dollars should use two URLs, one per currency. Worth knowing that Merchant Center's own documentation is looser, permitting several currencies on one landing page — via multiple
Offerobjects each with its ownpriceCurrency— provided the currency in your product data is the default and prominently displayed. The two sets of guidance do not quite agree. Distinct URLs remain the safer architecture, and they give you a cleaner base for canonicals, hreflang and market targeting. If you do serve multiple currencies from one URL, the thing that actually breaks is consistency: feed, markup and rendered page must agree, or you collect price-mismatch disapprovals in Merchant Center.Return and shipping policies belong at the `Organization` level, not per-product. Nest a global policy under Organization and override at product level only where a specific product genuinely differs. Product-level policies support only a subset of the available properties.
And the guideline that matters most for anyone running a JavaScript storefront, in Google’s own words: put `Product` structured data in the initial HTML for best results. Google warns explicitly that dynamically-generated markup makes Shopping crawls less frequent and less reliable — a problem precisely for fast-changing fields like price and availability, which are the fields that make the result worth having.
ProductGroup and variants
Variant markup was introduced in February 2024 and remains under-implemented relative to its value.
The model is straightforward. A `ProductGroup` represents the product as a concept — the chair, the lamp, the jacket. Individual `Product` entries represent the buyable variants — the chair in oak, in walnut, in black.
The connecting properties:
Property | On | Purpose |
|---|---|---|
|
| Lists the variant products |
|
| Declares which attributes vary (colour, size, material) |
|
| The group’s identifier |
|
| Points a variant back to its group |
|
| References the parent ProductGroup |
Why this matters for a visual guide specifically: variants are usually visual differences. Colour, finish, pattern, material; these are exactly the attributes a shopper resolves by looking rather than reading. Variant markup lets Google connect this photograph to this specific purchasable option, which is what produces color swatches and per-variant pricing in Shopping surfaces, and what allows a visual match to resolve to the right SKU rather than to a generic product page.
Variants need a distinct URL — but not necessarily a distinct page. Google supports two architectures. On a single-page setup, all variants sit under one ProductGroup with hasVariant, and there is one canonical URL for the group (typically the base URL with nothing preselected). The site must still be able to preselect any individual variant through a distinct URL, normally via query parameters. On a multi-page setup, each variant has its own page and self-referencing canonical, pointing back to the group with isVariantOf or inProductGroupWithID, and each page must carry complete, self-contained markup. Don't mix the two patterns on one page.
Google is explicit about what a preselecting URL has to resolve correctly: the right image, the right price, the right availability, and it must let the shopper add that specific variant to the cart. For a guide about visual search, note that the image is named first among the three. Variant imagery isn't decorative here; it's part of what makes the variant addressable at all.
The failure mode is therefore not JavaScript but unaddressable variants. A color picker that swaps the photograph through in-page interaction, with no URL that reproduces that state, leaves the green one unreachable. If a shopper can't link to it, Google can't crawl it, and that variant's imagery never becomes independently retrievable.
Turn visual search data into actionable insights
Advanced Web Ranking gives you a clearer view of visual search performance, from rankings in Google Images to image results in Universal SERPs and visibility across major AI engines.
Beyond the still image: 3D models
Current Product markup supports linking a 3D model to a product, via the subjectOf property and the 3DModel type. Only glTF format is supported — files must carry a .gltf or .glb extension, and at most one 3DModel may be specified per product.
This belongs in a visual search guide because it is the logical extension of everything in section 2. A still photograph gives a recognition system one viewpoint. A 3D model describes the object’s geometry from every angle, and it is the asset behind AR "view in your room" experiences, which are visual search’s most literal expression of will this work for me.
Adoption is currently concentrated in furniture, footwear and consumer electronics, where the underlying models often already exist from product development. If your business has 3D assets sitting in a CAD or product-design pipeline, this is a route to search visibility that costs comparatively little to open.
Image metadata and the Licensable badge
The image licensing structured data remains supported, and it has gained a route that did not exist when it launched.
Originally, credit and licensing information had to be embedded as IPTC photo metadata inside the image file. That path still works and still has a distinct advantage: the metadata travels with the image wherever it is copied, which is exactly the property you want if your images are being redistributed.
Since late 2022, the same information can also be supplied through structured data on the ImageObject type — creditText, creator and copyrightNotice — which is considerably easier to implement at scale from a CMS.
The full picture:
Signal | Where | Status |
|---|---|---|
license | Structured data | Required for the Licensable badge |
acquireLicensePage | Structured data | Recommended — where a user can obtain a license |
creditText, creator, copyrightNotice | Structured data or IPTC | Recommended |
Web Statement of Rights | IPTC embedded | Supported |
Licensor URL | IPTC embedded | Supported |
Where structured data and IPTC metadata disagree, Google prefers the structured data values.
Requirements are unchanged: images must be accessible without login, Googlebot must be able to reach the containing pages, and licensable images should appear in an image sitemap.
For ecommerce this is less about selling licenses and more about attribution surviving redistribution — a theme section 9 develops, and one that has become more consequential as image provenance becomes a search feature in its own right (section 8).
The specifications table
Here is the consolidated reference, verified against current Google documentation.
The general rules, which apply to every type:
Crawlable and indexable | Every image URL in structured data must be both. Verify with the URL Inspection tool. |
Relevant | The image must genuinely represent the marked-up content. |
Supported format | Any format supported by Google Images. |
Formats accepted | BMP, GIF, JPEG, PNG, WebP, SVG, AVIF |
That last row resolves a contradiction that troubled image SEO for years: performance guidance recommended modern formats while structured data documentation appeared to accept only JPEG, PNG and GIF. The contradiction no longer exists. WebP is accepted, SVG is accepted, and AVIF was added in August 2024. There is no longer any tension between serving a fast image and serving an eligible one.
Per-type image specifications:
Type | Required? | Quantity | Specification | Aspect ratios |
|---|---|---|---|---|
Product / merchant listing | Required | Multiple recommended | Minimum 50,000 px (width × height); high resolution; product clearly shown, ideally on white | 16:9, 4:3, 1:1 — supply all three |
ProductGroup / variants | Per variant | One or more per variant | As Product; distinct imagery and distinct URL per variant | As Product |
3D model | Optional | One per product | glTF only (.gltf / .glb) | n/a |
Image metadata / Licensable | - | - | Accessible without login; in an image sitemap | n/a |
For the Product row, note something that runs against the general pattern of this guide: this specification has not changed. The 50,000-pixel minimum and the three aspect ratios are current, live guidance. Where most of the old numbers in circulation have gone stale, these have not.
Two notes on reading it well:
50,000 pixels is a floor, not a target. It is satisfied by an image of roughly 224 × 224. That is nowhere near adequate for a Lens match, an OCR extraction, or a Merchant Center feed — which now requires 500 × 500 minimum and recommends 1500 × 1500 (section 5). Treat the structured data minimum as the eligibility threshold and the Merchant Center recommendation as the operating standard.
Supply all three aspect ratios. Google asks for 16:9, 4:3 and 1:1 because different surfaces crop differently: a wide carousel, a square grid tile, a portrait mobile card. Supplying one ratio means letting Google crop it, and an automatic crop that removes the product’s defining feature is a recognition problem as well as an aesthetic one.
Structured data declares what the image means; the technical layer determines whether the image can be reached, read and rendered at all. Perfect markup pointing at an image Googlebot cannot fetch is worth nothing.
Continue the guide
Images in AI Search ← Previous · Next → Technical SEO for Images
Article by
Gianluca Fiorelli
With almost 20 years of experience in web marketing, Gianluca Fiorelli is a Strategic and International SEO Consultant who helps businesses improve their visibility and performance on organic search. Gianluca collaborated with clients from various industries and regions, such as Glassdoor, Idealista, Rastreator.com, Outsystems, Chess.com, SIXT Ride, Vegetables by Bayer, Visit California, Gamepix, James Edition and many others.
A very active member of the SEO community, Gianluca daily shares his insights and best practices on SEO, content, Search marketing strategy and the evolution of Search on social media channels such as X, Bluesky and LinkedIn and through the blog on his website: IloveSEO.net.
