ImageObject Schema and Licensable Images: The Markup Google Actually Reads

There is a large gap between the image structured data that exists in the schema.org vocabulary and the image structured data Google actually does anything with. Most implementation guides describe the first and imply the second, which is how sites end up with hundreds of validating ImageObject nodes and no change whatsoever in Search Console.

This is a map of which is which, as of August 2026.

The two things image markup can do

Image structured data serves exactly two purposes in Google Search, and neither of them is ranking.

Eligibility for a feature. A product image can appear in shopping surfaces. An article image can be used as a rich-result thumbnail. An image with licence information can carry a "Licensable" badge in Google Images. In each case the markup makes the image eligible for a treatment it would not otherwise receive.

Disambiguation. On a page with a dozen images, markup tells Google which one is the product, which is the author's headshot and which is decorative. Without it, Google guesses, and its guesses are reasonable but not always the one you would pick.

What it does not do is raise a page's position for a query. Treat any guide promising otherwise with suspicion, and check whether the case study it cites changed something else at the same time.

The markup that carries weight

Markup	What it enables	Worth doing when
Product.image	Product appearance in shopping and rich results	You sell physical goods — near-mandatory
Article.image / BlogPosting.image	Thumbnail selection for article results and Discover	You publish editorial content
ImageObject with license + acquireLicensePage	The Licensable badge in Google Images	You licence or sell photography
ImageObject standalone, on ordinary content images	Nothing user-visible	Rarely — it is inventory, not a feature
Recipe.image, Event.image, LocalBusiness.image	Feature-specific image slots	You already use that entity type

The pattern is that the image property is almost always a sub-property of something else that matters. A well-formed Product with a good image value does work. A free-floating ImageObject describing a stock photo in your sidebar does not.

Product images: the requirements people miss

If you run an ecommerce site, Product.image is the highest-leverage image markup you will implement, and it fails for boring reasons.

Google requires that the image URL in your markup is crawlable and indexable. That single requirement kills more implementations than any schema syntax error, because image directories are frequently disallowed in robots.txt for reasons nobody remembers, or the URL in the markup points to an origin server behind a CDN rewrite.

The other frequent failures:

• Relative URLs. Structured data needs absolute URLs. /images/widget.jpg will validate in some tools and fetch in none.
• A different image from the one on the page. Google's guidance is explicit that structured data must represent the page's main content. A markup image that a visitor never sees is a mismatch.
• Placeholder or lazy-load source. If your <img> carries a 1×1 transparent GIF in src until JavaScript swaps it, make sure the markup references the real file, not the placeholder.
• Too small. Very low-resolution images are technically valid and practically ignored.

The wider set of decisions around product photography — variants, galleries, category pages — is a bigger topic than markup alone; the ecommerce product image SEO guide covers what to shoot and in what order before you get to describing it.

The Licensable badge, honestly assessed

Google supports two ways of declaring licence information for an image: structured data on the page, or IPTC photo metadata embedded in the file.

In structured data, the relevant fields sit on an ImageObject:

• license — a URL pointing to the page describing the licence terms
• acquireLicensePage — a URL where someone can actually obtain a licence
• creditText, creator, copyrightNotice — attribution fields that can be surfaced

In embedded IPTC metadata, the equivalents are the Web Statement of Rights, Licensor URL, Creator, Credit Line and Copyright Notice fields. Google reads both. The embedded route has one genuine advantage: metadata written into the file travels with the file, so a copy that ends up on another site still carries your attribution. The practical guide to EXIF and IPTC metadata covers how those fields are written and what survives a typical CMS upload.

Now the honest part. The Licensable badge is valuable to a specific group — stock agencies, working photographers, illustration marketplaces — and close to worthless for everyone else. If your images exist to support your own pages, marking them licensable tells Google to advertise them as available for licensing, which is not a business you are in. Implement the attribution fields if you want the credit; skip acquireLicensePage unless someone can genuinely licence the image.

Article images and the ratio question

For editorial content, Article.image (or BlogPosting.image) determines what thumbnail Google can use.

Google's article guidance asks for high-resolution images, supplied where possible in three crops — 16x9, 4x3 and 1x1 — so it can pick a shape appropriate to the layout it is rendering. Most content management systems supply one image and let Google crop. That works until the crop cuts the subject in half, which happens most often with wide hero images that put the meaningful content at one edge.

Two practical consequences:

1. Compose hero images with the subject roughly centred, so that a square crop still contains it.
2. If your CMS can generate multiple ratios, supply them in the image array rather than relying on automatic cropping.

The same file is usually also the Largest Contentful Paint element for the page, so the choice interacts with performance work — the image side of Core Web Vitals matters more to the page's outcome than the markup around it does.

Where structured data and sitemaps do different jobs

These two are frequently confused, and they solve different problems.

An image sitemap is a discovery mechanism: it tells Google that image URLs exist and are worth crawling, which matters most on sites where images are loaded by JavaScript or live on a separate hostname. Structured data is a description mechanism: it tells Google what an already-discovered image is.

Neither substitutes for the other, and neither fixes an image Googlebot cannot fetch. If images are missing from Google Images entirely, markup is the wrong place to start — work through the discovery and indexing causes first, then describe what is being crawled. The image sitemaps guide sets out when a sitemap genuinely earns its maintenance cost, which is less often than it is recommended.

Where the markup goes, and in what shape

Three implementation details decide whether a technically correct block does anything.

Use JSON-LD, in the head or the body. Google's stated preference is JSON-LD, and it can appear anywhere in the document. Microdata and RDFa are still parsed, but they interleave markup with presentation, which means a template change silently breaks structured data. If you are starting fresh, there is no reason to choose them.

Nest the image inside the entity, do not orphan it. The single most common structural mistake is a standalone ImageObject block sitting beside a Product block, with nothing connecting them. Put the image in the parent entity's image property — either as a plain URL string or as a nested ImageObject when you need extra fields such as caption or creditText. A URL string is sufficient for most cases and is easier to keep correct.

One graph per page beats many blocks. A page carrying five separate script tags with overlapping entities is difficult to reason about and easy to duplicate. A single @graph array with explicit @id values lets entities reference each other — the organisation, the article, the author, the image — without repeating them. Most modern SEO plugins and frameworks emit this shape by default, and hand-written markup should match it.

If the page is rendered client-side, confirm that the JSON-LD exists in the HTML Google actually receives. Structured data injected after page load is sometimes picked up and sometimes is not, and the Rich Results Test is the fastest way to find out which is happening on your stack.

Validating without fooling yourself

Two tools, used in this order:

Schema Markup Validator (validator.schema.org) checks that your JSON-LD is syntactically valid and uses real vocabulary. It will happily approve markup that is technically perfect and functionally useless.

Rich Results Test (search.google.com/test/rich-results) checks whether Google can actually derive an eligible rich result from the page, fetching it as Googlebot. This is the one that catches blocked images, unreachable URLs and mismatched content.

Then, after deployment, Search Console's Enhancements reports show what Google found across the whole site rather than one URL — which is where you discover that the template works and forty legacy pages do not.

One caveat worth stating: a green result in the Rich Results Test means eligible, not guaranteed. Google decides at query time whether to render a rich result, and a valid implementation that never displays is common and not a bug.

A short implementation order

For most sites, in descending order of return:

1. Product.image on product pages, with crawlable absolute URLs matching the on-page image.
2. Article.image on editorial content, composed so an automatic square crop still works.
3. LocalBusiness.image if you have location pages, using an image of the actual premises.
4. Attribution fields — creditText, copyrightNotice — where you want credit, ideally embedded in the file as well as declared on the page.
5. license and acquireLicensePage, only if you genuinely licence images.

Everything below that line is optional. Markup rewards precision about a small number of important images far more than completeness across all of them — and it is worth remembering that structured data describes rights and function, not origin. If you also need to declare that an image was generated rather than photographed, that is a separate set of fields entirely.

SEOpix writes the attribution and copyright fields into every generated file at creation time, so the metadata half of this is already done before the image reaches your CMS. See what each plan includes, or start on the free tier if you want to check what lands in the file.