ImageObject Schema

TL;DR — ImageObject is a way to describe an image to search engines with more than just its web address — who owns it, how it can be licensed, its caption. Most of the time you don’t need it: when a piece of schema asks for an image, a plain URL is enough. You reach for the full ImageObject when you want to attach that extra information — most commonly to earn the “Licensable” badge in Google Images.

What ImageObject is

When you add structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. to a page, you’re labeling your content so search engines understand it. ImageObject is the schema.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor. type that labels an image — not the words on the page, but a picture, described as data a machine can read.

Here’s the part almost every guide skips: ImageObject is rarely used on its own. Its real job is to be the value of another type’s image property. When you mark up a product, an article, or a recipe, each of those has a spot for an image. You can fill that spot two ways:

• With a plain URL — just the web address of the picture. This is all you need most of the time.
• With a full ImageObject — when you want to say more than “here’s the file,” like who took the photo or how someone can license it.

So think of ImageObject less as “a thing that gets its own search result” and more as “a richer way to describe the image inside some other piece of schema.”

When you actually need the full version

You upgrade from a plain URL to a full ImageObject when you want to attach metadata about the image itself — most often for licensing. If you’re a photographer, a stock agency, or a publisher who wants your images to show a Licensable badge in Google Images (a small label that links to where people can buy a license), that badge is the main reason to bother with a full ImageObject.

The single property that unlocks that badge is license — a link to your licensing terms. You can add more (who created the image, a credit line, a copyright notice), but license is the one that flips the switch.

The thing most people get wrong

ImageObject does not earn its own rich result. There’s no “image card” it produces. It either feeds another type’s eligibility (like a recipe’s rich result) or it unlocks the separate Licensable badge — that’s it.

And be very skeptical of any guide promising a specific traffic or click number from adding image schema (“+30% clicks!”). I’ve looked at where those numbers come from, and the honest answer is nowhere — they’re invented. Schema is worth doing, but not because of a made-up percentage.

Want the deep version — the exact properties, how the Licensable badge works, why Recipe images don’t control your thumbnail, and the Product-image myth? Switch to the Advanced tab.

TL;DR — ImageObject (Thing > CreativeWork > MediaObject > ImageObject) is primarily a nested value type, not a standalone destination schema. It’s the value of Product.image, Article.image, Recipe.image, Organization.logo, WebPage.primaryImageOfPage. A plain URL works when you don’t need metadata; upgrade to a full object for licensing/attribution. The Licensable-badge recipe is contentUrl + at least one of creator/creditText/copyrightNotice/license — but license specifically is what makes the badge eligible. Use contentUrl over url (Google calls it more precise). Two commonly-missed facts: Recipe’s image is required but has no impact on your text-result thumbnail (Google, June 2025), and Product’s image is not in Google’s formal required/recommended lists. It’s not a ranking factor — same indirect story as all schema.

Where ImageObject sits, and how it’s actually used

On schema.org, ImageObject sits in the hierarchy as Thing > CreativeWork > MediaObject > ImageObject. That lineage is the whole story of its properties: it inherits licensing and attribution fields from CreativeWork (license, acquireLicensePage, creditText, copyrightNotice, creator, author) and file fields from MediaObject (contentUrl, encodingFormat, height, width, contentSize, uploadDate), plus a few of its own like caption and exifData.

It gets used two ways:

• Standalone — on a page whose whole point is describing one image (a photo-licensing landing page). The reason to do this is almost always the Licensable badge.
• Nested — as the value of another type’s image, logo, or primaryImageOfPage property. This is by far the more common case, and it’s why ImageObject is best framed as the utility type the CreativeWork subtypes quietly depend on rather than a schema type you point people at. (It’s the thematic cousin of the creative-works schema\"Creative Works schema\" is a practitioner label for the schema.org CreativeWork subtypes used to mark up authored content — Article, AudioObject, Book, Course, Dataset, Movie, Recipe, and VideoObject. bucket — Article, Recipe, and VideoObject all lean on ImageObject through their image properties without ever making it their headline.)

The key mental unlock: schema.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor. and Google both accept “a URL or a fully described ImageObject” for an image property. A bare URL string is a perfectly valid ImageObject value. You only pay the cost of the full object when you have metadata worth attaching.

The core properties

contentUrl vs url — use contentUrl

Both point at the image file, but Google is explicit about which to prefer. From the image-metadata documentation: Google uses contentUrl “to determine which image the photo metadata applies to.” And on the choice between the two: “While the url property is not as precise and we recommend you use contentUrl instead, existing markup may still use url.” Translation: contentUrl pins down which image the metadata describes; url is a looser legacy fallback that still works but shouldn’t be your default.

license and acquireLicensePage — the Licensable pair

This is the part with a visible payoff. license links to a page describing the image’s licensing terms; acquireLicensePage links to where someone can actually buy a license. They pair naturally — one says “here are the terms,” the other says “here’s where to buy one” — but they’re not equal in weight, which the next section covers.

creator, creditText, copyrightNotice — the attribution trio

These credit the image. One nuance worth keeping: creator isn’t necessarily a person. Google’s doc: “This is usually the photographer, but it may be a company or organization (if appropriate).”

caption, exifData, height/width, thumbnail

Descriptive and technical metadata. Useful, occasionally surfaced, but none of them trigger a search feature on their own.

Getting the Licensable badge

This is the one exact recipe worth memorizing, because the requirement is subtle.

The required structure: you need contentUrl, and at least one of creator, creditText, copyrightNotice, or license. Google’s doc: “In addition to contentUrl, you must include one of the following properties: creator, creditText, copyrightNotice, license. Once you include one of these properties, the other three properties become recommended in the Rich ResultsRich results (formerly 'rich snippets') are enhanced search listings — stars, images, prices, breadcrumbs, video thumbnails, and more — that Google and Bing build from structured data. They're a display feature, not a ranking factor, and eligibility never guarantees they'll show. Test.”

But the badge itself has a stricter trigger. Passing validation is not the same as being badge-eligible. Google: “If you’re using structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. to specify an image, you must include the license property for your image to be eligible to be shown with the Licensable badge.” So creator or creditText alone will validate fine — and get you no badge. The license property is the switch. Google adds: “We recommend that you also add the acquireLicensePage property if you have that information.”

Structured data isn’t the only path. IPTC embedded photo metadata is an equally valid way to earn the same eligibility — no schema.org markup required at all. But if you use both and they disagree, Google is explicit about the tiebreaker: “If you choose to use both IPTC photo metadata and structured data, and if any information conflicts between the two, Google will use the structured data information.” That’s the reverse of what a lot of people assume (that the file’s embedded metadata is the more “authoritative” source).

One policy that catches people: the image URL has to be reachable. Google’s structured-data policies say “All image URLs specified in structured data must be crawlable and indexable” — block the image host in robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. and the whole thing silently fails.

ImageObject inside specific types

Recipe — required, and the June 2025 clarification

For Recipe, image is required, and it has real guidance: crawlable and indexable, must represent the dish, and Google “recommend[s] providing multiple high-resolution images (minimum of 50K pixels when multiplying width and height) with the following aspect ratios: 16x9, 4x3, and 1x1.”

Here’s the counterintuitive part most guides haven’t caught up to. As of a June 2025 doc update, Google states plainly: “Specifying the image property in Recipe markup has no impact on the image chosen for a text result image.” In other words, your Recipe image governs recipe rich-result eligibility — not the thumbnail that shows next to your normal blue-link result. That’s a separate system entirely (covered below). Barry Schwartz reported this change at Search Engine Land on June 5, 2025.

Product — not formally required (the myth-bust)

Almost everyone asserts that images are “required” for Product rich resultsRich results (formerly 'rich snippets') are enhanced search listings — stars, images, prices, breadcrumbs, video thumbnails, and more — that Google and Bing build from structured data. They're a display feature, not a ranking factor, and eligibility never guarantees they'll show.. They’re not — at least not per Google’s documented lists. The product-snippet doc’s formal Required properties are name plus one of review/aggregateRating/offers; the Recommended list is aggregateRating, offers, review. The image property appears only inside the worked examples, never in the required/recommended tables. Add product images anyway — a listing without a photo converts worse — but know that’s a UX-and-Shopping argument, not a documented schema requirement. (And don’t conflate it with Merchant CenterGoogle Merchant Center (GMC) is a free platform where retailers upload and manage product data so their products can appear across Google — Shopping, organic Search product grids, Images, Lens, and AI surfaces. Since 2020 it powers free (organic) product listings, not just paid Shopping ads.’s separate, stricter product-image resolution rules — a different system from ImageObject entirely.)

Article and Organization

For Article, image is a recommended property that feeds Article’s eligibility; it does not produce a dedicated image card of its own. For Organization.logo, the logo has its own separate requirements (and is the image Google can use for things like knowledge-panel and some rich-result branding) — worth marking up, but it’s a logo-specific job, not general ImageObject licensing.

Controlling your Search / Discover thumbnail

If you actually want to influence the image Google shows as your page’s preview, that’s a different mechanism from any of the above — and Google clarified it in a March 2026 documentation update. From the image-SEO best-practices doc: “Google’s selection of an image preview is completely automated and takes into account a number of different sources to select which image on a given page is shown on Google.”

Three parallel, non-exclusive signals feed that choice:

1. The schema.org primaryImageOfPage property on your WebPage.
2. An image property attached via mainEntity / mainEntityOfPage.
3. The og:image meta tag.

Google’s guidance for all three: “Choose an image that’s relevant and representative of the page. Avoid using a generic image (for example, your site logo) or an image with text in the schema.org markup or og:image meta tag.” Matt G. Southern covered the update at Search Engine Journal on March 2, 2026, noting the key point: schema markupSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor. and og:image both count — they’re parallel inputs, not an either/or.

C2PA / “About this image” — adjacent, not ImageObject

One forward-looking sibling worth a mention, clearly scoped as separate from ImageObject licensing: C2PA content-provenance metadata (embedded in the image file, not schema.org). Google: “If an image contains C2PA metadata, Google can extract those details and may show information in the ‘About this image’ feature, such as how the image was created or if it was edited with AI tools.” This is an AI-provenance signal on the same “About this image” surface as licensing info — but it lives in the file’s manifest, not in your ImageObject markup. Don’t fold the two together.

Is ImageObject a ranking factor?

No — same indirect story as all structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding.. The standing Google position (Gary Illyes, John Mueller) is that schema helps engines understand content and can unlock eligibility for features, but it isn’t a direct ranking input. For ImageObject specifically, the wins are concrete but narrow: the Licensable badge (via license), rich-result eligibility for parent types like Recipe (via a valid image), and thumbnail-selection input (via primaryImageOfPage). None of those is “rank higher,” and Google’s own troubleshooting guidance is explicit that even a fully valid image-metadata block isn’t guaranteed to display. The same reviewed sources don’t establish an AI-citation effect from ImageObject either — I haven’t foundA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore. a source that shows it improves your odds of being cited in an AI answer. Anyone selling you a specific percentage traffic lift from image schema is quoting a number that traces to no source.

Common mistakes

• Using url instead of contentUrl. Both work; Google prefers contentUrl as more precise.
• Forgetting license specifically. The other three attribution properties validate but don’t trigger the Licensable badge.
• Assuming Recipe’s image controls your text-result thumbnail. It doesn’t (Google, June 2025) — it only affects recipe rich-result eligibility.
• Assuming Product images are formally required schema. They’re not in Google’s documented lists (still add them for UX/Shopping).
• Blocking the image URL. A robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere.-disallowed or noindexed image host means the markup silently fails Google’s crawlable-and-indexable requirement.
• Repeating invented performance stats. Nearly every competing guide cites an uncited “+X% CTR/traffic” figure. None trace to a source.

Where this fits

ImageObject is a deep dive in the structured-data sub-cluster, alongside its sibling schema-type articles (article-schema, recipe-schema, product-schema, videoobject-schema, organization-schema). Thematically it’s the utility type the creative-works schema\"Creative Works schema\" is a practitioner label for the schema.org CreativeWork subtypes used to mark up authored content — Article, AudioObject, Book, Course, Dataset, Movie, Recipe, and VideoObject. family leans on, and it lives under the Structured Data for SEOStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. hub. For the broader picture of alt textAlt text is the value of the `alt` attribute on an HTML `<img>` element — a short text substitute chosen for the image's purpose and context, not a literal description of what it shows. It makes images accessible to screen-reader users and helps search engines understand images, mainly for image search., formats, image sitemapsAn image sitemap is a sitemap (or an extension added to an existing sitemap) that lists the images on your pages using Google's image namespace, helping Google discover images it might otherwise miss., and lazy-loading, that’s a separate image-SEO topic; this article is specifically the “how do I describe an image as data” piece those others quietly depend on.

AI summary

A condensed take on the Advanced version:

• ImageObject is a nested value type, not a standalone rich result. Hierarchy: Thing > CreativeWork > MediaObject > ImageObject. It’s the value of Product.image, Article.image, Recipe.image, Organization.logo, WebPage.primaryImageOfPage. A plain URL is a valid image value; upgrade to a full object only when you have metadata to attach.
• Licensable badge recipe: contentUrl + at least one of creator/creditText/copyrightNotice/license to validate — but the license property specifically is what makes the badge eligible. Add acquireLicensePage too if you have it.
• contentUrl over url — Google says contentUrl is more precise for pinning down which image the metadata describes; url is a legacy fallback.
• IPTC is an equal alternative path to the same eligibility — but if IPTC and structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. conflict, Google uses the structured data.
• Recipe: image is required (50K px² min; 16x9/4x3/1x1) but has no impact on your text-result thumbnail (Google clarified June 2025).
• Product: image is not in Google’s formal required/recommended lists — add it anyway for UX/Shopping, but it’s not a documented schema requirement.
• Thumbnail control is a separate March 2026 mechanism: primaryImageOfPage, main-entity image, and og:image as three parallel signals.
• C2PA feeds “About this image” (AI-provenance) but lives in the file, not in ImageObject markup — don’t conflate.
• Not a ranking factor — indirect at most, display itself isn’t guaranteed, and no source establishes an AI-citation effect either; ignore invented “+X%” stats.

Official documentation

Primary-source documentation from Google and schema.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor..

Google

• Image Metadata (Google Images SEO) — the core ImageObject/licensing doc: required properties, contentUrl vs url, the license/Licensable-badge rule, IPTC-vs-structured-data conflicts, and C2PA.
• Structured Data General Guidelines — the crawlable-and-indexable and relevance requirements that apply to any image in structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding..
• Recipe structured data — image required, the size/aspect-ratio guidance, and the “no impact on the text-result image” clarification.
• Product snippet structured data — the formal Required/Recommended property lists (note image is in neither).
• Image SEO best practices — primaryImageOfPage, main-entity image, and og:image as thumbnail-selection signals.

schema.org

• ImageObject — the type definition, hierarchy (Thing > CreativeWork > MediaObject > ImageObject), and full property list.
• contentUrl · license · acquireLicensePage — the properties Google’s licensing guidance leans on.

Quotes from the source

On-the-record statements from Google. Each link is a deep link that jumps to the quoted passage on the source page.

Google — contentUrl vs url

• “Google uses contentUrl to determine which image the photo metadata applies to.” — Google Search Central docs. Jump to quote
• “While the url property is not as precise and we recommend you use contentUrl instead, existing markup may still use url.” Jump to quote

Google — the required structure and the Licensable-badge trigger

• “In addition to contentUrl, you must include one of the following properties: creator, creditText, copyrightNotice, license.” Jump to quote
• “If you’re using structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. to specify an image, you must include the license property for your image to be eligible to be shown with the Licensable badge.” Jump to quote
• “We recommend that you also add the acquireLicensePage property if you have that information.” Jump to quote

Google — IPTC vs structured data, and creator

• “If you choose to use both IPTC photo metadata and structured data, and if any information conflicts between the two, Google will use the structured data information.” Jump to quote
• On creator: “This is usually the photographer, but it may be a company or organization (if appropriate).” Jump to quote

Google — image policy, Recipe, and thumbnail selection

• “All image URLs specified in structured data must be crawlable and indexable.” Jump to quote
• “Specifying the image property in Recipe markup has no impact on the image chosen for a text result image.” Jump to quote
• “Specify the schema.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor. primaryImageOfPage property with a URL or ImageObject.” Jump to quote

Plain URL or full ImageObject? And which feature am I even after?

The most common real question with ImageObject isn’t “how do I write it” — it’s “do I need the full object at all, and if so, why.” Answer for the image you’re marking up.

ImageObject — cheat sheet

Standalone vs. nested

The Licensable-badge recipe

contentUrl vs url

Image property by parent type

Fast facts

• Hierarchy: Thing > CreativeWork > MediaObject > ImageObject.
• Not a ranking factor — earns eligibility, not rank.
• IPTC is an equal path to the badge; on conflict, structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. wins.
• Image URLs must be crawlable and indexable or the markup fails silently.
• Thumbnail control = primaryImageOfPage / main-entity image / og:image (March 2026), a separate mechanism.
• C2PA ≠ ImageObject — it’s file-embedded provenance for “About this image.”

Anti-patterns — the ImageObject mistakes I see most

Adding creator or creditText and expecting the Licensable badge. The most common near-miss. Those validate, but the badge is gated on license specifically. Credit without a license link earns you nothing visible.

Reaching for a full ImageObject when a URL string would do. If you have no metadata to attach, a bare URL is the correct value for an image property — schema.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor. and Google both accept it. Wrapping every image in a full object just adds surface area to get wrong.

Using url because a generator emitted it. Plenty of tools still output url. It works, but Google prefers contentUrl for precision. Prefer contentUrl in new markup.

Believing Recipe’s image sets your search thumbnail. It’s required for the recipe rich resultRecipe schema (schema.org/Recipe) marks up a cooking recipe's image, name, ratings, times, ingredients, and nutrition so the page can earn Google's recipe rich result — a visual card with star ratings and cook time, plus carousel and recipe-filter eligibility., but Google explicitly says it has no impact on the text-result thumbnail. If you want to influence that image, that’s a separate job (primaryImageOfPage / og:image).

Treating Product images as a required schema field. They’re not in Google’s documented required/recommended lists. Add them for conversion and Shopping, but don’t cite “required schema” as the reason — and don’t confuse this with Merchant CenterGoogle Merchant Center (GMC) is a free platform where retailers upload and manage product data so their products can appear across Google — Shopping, organic Search product grids, Images, Lens, and AI surfaces. Since 2020 it powers free (organic) product listings, not just paid Shopping ads.’s separate image-resolution rules.

Blocking the image host. A robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere.-disallowed or noindexed image URL fails the crawlable-and-indexable requirement. The markup can be perfect and still do nothing.

Repeating invented percentage stats. “ImageObject schemaImageObject is the schema.org type that describes an image as structured data. It's rarely used alone — its main job is as the value of an image or logo property nested inside another type (Product.image, Article.image, Recipe.image, Organization.logo). You upgrade a plain image URL to a full ImageObject when you want to attach metadata: who owns the image, how it can be licensed, its caption, or its dimensions. Adding the license property is what makes an image eligible for Google's Licensable badge. gives a 30% CTR lift” and friends trace to no source. Schema is worth doing on its actual merits (eligibility, understanding), not a made-up number.

Conflating C2PA provenance with ImageObject licensing. “About this image” AI-provenance info comes from C2PA metadata in the file, not from your schema. Two different systems on the same surface.

Implementation examples

Two patterns cover almost everything: a standalone licensing image, and an ImageObject nested inside a parent type.

1. Standalone photo-licensing image (chasing the Licensable badge)

The license property is what makes this badge-eligible; acquireLicensePage, creator, creditText, and copyrightNotice round it out.

{
  "@context": "https://schema.org/",
  "@type": "ImageObject",
  "contentUrl": "https://example.com/photos/harbor-at-dawn.jpg",
  "license": "https://example.com/licenses/standard/",
  "acquireLicensePage": "https://example.com/photos/harbor-at-dawn/buy/",
  "creator": {
    "@type": "Person",
    "name": "Alex Rivera"
  },
  "creditText": "Alex Rivera / Example Studio",
  "copyrightNotice": "© 2026 Example Studio",
  "caption": "The harbor at dawn, long exposure",
  "width": 2400,
  "height": 1600
}

2. ImageObject nested inside a Product

Here the ImageObject is the value of Product.image. Note that image isn’t a formally required Product property — this is the “attach metadata” upgrade over a plain URL string.

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Trailhead 30L Backpack",
  "image": {
    "@type": "ImageObject",
    "contentUrl": "https://example.com/products/trailhead-30l.jpg",
    "license": "https://example.com/licenses/product-photography/",
    "creditText": "Example Gear Co."
  },
  "offers": {
    "@type": "Offer",
    "price": "129.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  }
}

3. When a plain URL is the right answer

If you have no metadata to attach, don’t over-engineer it — a bare URL string is a valid image value:

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Trailhead 30L Backpack",
  "image": "https://example.com/products/trailhead-30l.jpg",
  "offers": {
    "@type": "Offer",
    "price": "129.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  }
}

Validate any of these in the Rich Results Test and the schema.org validator before shipping.

Tools for building and checking ImageObject markup

Check it with the Schema Markup Validator: paste your JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. (or a full HTML page, or fetch a live URL) and it detects the ImageObject block — standalone or nested inside Product, Article, or Recipe — and flags issues by severity. It’s the fastest way to check the exact patterns from the Examples tab: does it catch contentUrl vs. url, is license present (not just creator/creditText/copyrightNotice), and does a nested Product.image parse correctly as an ImageObject rather than a bare string when you meant to attach metadata.

Then confirm eligibility with the Rich-Result Eligibility Checker: validating clean JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. isn’t the same as being eligible for a feature. Run the URL through this checker to see whether the parent type (Recipe, Product) actually reports as eligible for its rich result — useful since, as covered in Advanced, Product’s image isn’t a formally required property and a missing or malformed one can silently sit outside Google’s required/recommended lists without failing validation.

Third-party — Google’s Rich Results Test: the source Google itself points to for the Licensable-badge requirements quoted throughout this article. Use it as a second check on badge eligibility specifically, since that’s a stricter bar than passing basic JSON-LD validation (you need license, not just one of the other three attribution properties).

Validation tests — did your ImageObject change actually take effect?

Proof that a specific ImageObject edit shipped correctly, not just that it looks right in the source.

Test 1 — The JSON-LD parses with no errors

• Test to run — Paste the page’s JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. (or fetch the live URL) into the Schema Markup Validator.
• Expected result — The ImageObject block (standalone or nested) is detected with no syntax/parse errors, and contentUrl resolves to the field you intended.
• Failure interpretation — A parse failure usually means a templating bug — a malformed nested object where Product.image should hold an ImageObject but got broken JSON, or a stray string where an object was expected.
• Monitoring window — Immediate.
• Rollback trigger — The validator can’t detect the ImageObject at all after a template deploy — the markup isn’t renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM.; roll back the change.

Test 2 — Licensable-badge validation passes (but check the stricter trigger)

• Test to run — Run the same URL through the Schema MarkupSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor. Validator or Google’s Rich Results Test, checking specifically for contentUrl plus at least one of creator/creditText/ copyrightNotice/license.
• Expected result — The image-metadata block validates with no required-property errors.
• Failure interpretation — the “validates but no badge” mode: validation passing is not the same as badge eligibility. If you added creator or creditText but not license, the block will validate cleanly and still never show the Licensable badge — Google’s doc is explicit that license specifically is the trigger. Don’t read a validation pass as confirmation the badge will appear.
• Monitoring window — Immediate for validation; the Licensable badge itself can take longer to surface in Google Images after a successful crawl, so allow a few weeks before concluding it’s missing.
• Rollback trigger — If license is present, validation passes, and the badge still hasn’t appeared after a reasonable crawl window, check that the image URL itself is crawlable and indexable (a robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. block on the image host makes the markup fail silently) before assuming the markup is wrong.

Test 3 — Recipe eligibility isn’t confused with thumbnail control

• Test to run — For Recipe pages, run the URL through the Rich-Result Eligibility Checker to confirm the recipe rich resultRecipe schema (schema.org/Recipe) marks up a cooking recipe's image, name, ratings, times, ingredients, and nutrition so the page can earn Google's recipe rich result — a visual card with star ratings and cook time, plus carousel and recipe-filter eligibility. reports eligible, separately from checking which image shows next to your normal text result in Search.
• Expected result — The recipe rich result shows eligible with a valid image present. Separately, the text-result thumbnail is whatever primaryImageOfPage, main-entity image, or og:image selects — not necessarily the same image.
• Failure interpretation — If the recipe rich result is ineligible, the problem is the image property on the Recipe type itself (missing, wrong aspect ratio, not crawlable). If the text-result thumbnail looks wrong, that’s a separate signal entirely (per Google’s June 2025 clarification, Recipe’s image doesn’t control it) — check primaryImageOfPage and og:image instead.
• Monitoring window — Rich-result eligibility can be checked immediately after a successful crawl; thumbnail selection is automated and can take longer to settle in live Search results — allow a few weeks before troubleshooting further.
• Rollback trigger — Recipe rich-result eligibility drops after a template change — roll back and re-check the image property’s crawlabilityCrawlability is how well search engine crawlers can discover, access, and fetch a site's pages. A crawlability issue is any technical condition — blocked access, broken links, server failures, or bloated URL inventory — that stops pages from reaching the index. and size.

Resources worth your time

My related writing

• Structured Data: What It Is and How to Use It — my Ahrefs guide to schema typesSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor., formats, validation, and the sameAs entity angle; the broader context ImageObject sits inside.
• The Beginner’s Guide to Technical SEO — where structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. (and images) fit into the bigger technical picture.

My speaking

• How Search Works (SlideShare) — my walkthrough of crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor., renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM., indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., and how markup feeds understanding. (My standing disclaimer applies: “This is my understanding of systems… not going to be 100% complete or accurate.”)

Official

• Google’s Image Metadata doc — the canonical ImageObject/licensing reference.
• Google’s Recipe and Product snippet docs — for the required/recommended property realities.
• Google’s Image SEO best practices — the primaryImageOfPage / og:image thumbnail-selection guidance.
• schema.org/ImageObject — the type definition and full property list.

From around the industry

• Google updates Event and Recipe structured data (Barry Schwartz, Search Engine Land, June 5, 2025) — the source for the “Recipe image doesn’t affect the text-result thumbnail” clarification.
• Google clarifies how it picks thumbnails for Search & Discover (Matt G. Southern, Search Engine Journal, March 2, 2026) — the primaryImageOfPage / main-entity image / og:image thumbnail update.
• Quick guide to IPTC Photo Metadata and Google Images (IPTC) — the IPTC-field-to-schema.org mapping for the alternative licensing path.
• Yoast — the Image schema piece (Yoast developer portal) — a solid technical reference for ImageObject inside a JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. @graph, referenced by @id when the same image is reused.
• r/TechSEO — the community for structured-data and image-markup debugging.

Test yourself: ImageObject Schema

Five quick questions on how ImageObject actually works. Pick an answer for each, then check.

ImageObject schema

ImageObject is the schema.org type that describes an image as structured data. It's rarely used alone — its main job is as the value of an image or logo property nested inside another type (Product.image, Article.image, Recipe.image, Organization.logo). You upgrade a plain image URL to a full ImageObject when you want to attach metadata: who owns the image, how it can be licensed, its caption, or its dimensions. Adding the license property is what makes an image eligible for Google's Licensable badge.

Related: Structured Data, Creative Works Schema, Image SEO

ImageObject schema

ImageObject is the schema.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor. type that represents an image file as structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding.. It sits in the schema.org hierarchy as Thing > CreativeWork > MediaObject > ImageObject, which is why it inherits licensing and attribution properties from CreativeWork (license, acquireLicensePage, creditText, copyrightNotice, creator) and file properties from MediaObject (contentUrl, height, width, encodingFormat).

Most of the time you don’t need it. When a property just wants a picture — Product.image, Article.image, Recipe.image — schema.org and Google both accept “a URL or a fully described ImageObject,” and a plain URL string is enough. You reach for a full ImageObject when you want to describe the image itself: its licensing terms, its photographer, its caption, its EXIF data. So ImageObject is best understood as a nested value type, not a standalone schema that earns its own rich result.

The one visible search feature it directly unlocks is the Licensable badge in Google Images. Per Google’s image-metadata documentation, you need contentUrl plus at least one of creator, creditText, copyrightNotice, or license — but the license property specifically is what makes an image “eligible to be shown with the Licensable badge.” Google recommends contentUrl over the looser legacy url property because it more precisely identifies which image the metadata describes. Like all structured data, ImageObject is not a direct ranking factor.

Related: Structured Data, Creative Works Schema, Image SEO

Changelog