Image schema has a reputation it does not entirely deserve. Plenty of guides treat ImageObject markup as a universal must-do, something to bolt onto every image on the site. In practice, most editorial images do just as well with a good og:image tag, and the effort of marking up everything is effort that could go somewhere with a bigger payoff.
This is the honest version: the four cases where image structured data genuinely earns its place, the cases where it does not, and the 2026 update that added a real new lever. It builds on the schema layer of our complete guide to image SEO in WordPress.
What structured data does for an image
Structured data describes an image to a search engine in machine-readable terms: this is the image, here is its URL, here is its caption, here is who made it, here is its licence. The standard type is ImageObject, and the format Google prefers is JSON-LD — a block of structured JSON in the page head or body, separate from the visible content.
The payoff is eligibility for richer treatment: licensing badges in Google Images, better thumbnail selection, clearer attribution, and a cleaner signal to AI search engines about what the image is and who owns it. The word “eligibility” matters — schema makes you eligible for these results; it does not guarantee them.
The four cases where it matters
1. Product images
Product schema with image URLs feeds Google Shopping, product rich results, and the image carousels that increasingly sit above organic results. For an online shop this is among the highest-value markup you can add. We cover the e-commerce specifics in image SEO for WooCommerce product pages.
2. Recipe images
Recipe rich results lean heavily on the image, and the recipe schema type expects one. If you publish recipes, the image is doing visible work in the SERP, and the markup is what makes it eligible.
3. Article hero images (large-image results)
For news and feature articles, a properly marked-up hero image can earn the large-image treatment in Google Discover and top stories. This is where the March 2026 preferred-image update is most useful — it lets you nominate which image represents the page.
4. Licensable images
If you license your photography, the licensing metadata fields (license and acquireLicensePage) earn the “Licensable” badge in Google Images and a link to your licensing page. For photographers and stock libraries this is a direct route to revenue, and almost nobody outside that world needs it.
The cases where it does not matter
A decorative blog photo. A team headshot. A section-divider graphic. A stock-style atmospheric image. For all of these, a good og:image tag plus solid alt text and a caption does the same job, and adding ImageObject markup to each one is effort with no measurable return. The skill is not “add schema to everything” — it is knowing which images are doing SERP work and marking up only those.
The ImageObject properties worth knowing
- contentUrl — the direct URL to the image file. The one property you cannot get wrong.
- caption — a human-readable description, often the same as the visible caption.
- creator — who made the image, as a Person or Organization.
- license and acquireLicensePage — the licensing fields that earn the Licensable badge.
- primaryImageOfPage — added prominence in 2026; nominates the image that represents the page.
The 2026 update: the preferred image
In March 2026, Google Search Central documented how to specify the image used for thumbnails in Search and Discover. You can signal it three ways: structured data (primaryImageOfPage or mainEntityOfPage), the og:image meta tag, or the page’s clear main image. Before this, thumbnail selection felt arbitrary. Now there is a documented lever — and it is the kind of thing most sites have not touched yet, which makes it a quiet edge.
Do this now. List your page types (product, blog post, portfolio item, recipe, landing page). Mark which fall into the four cases above. Add ImageObject schema to those types only, test each with Google’s Rich Results Test, and leave the rest to og:image and good alt text. You will spend your effort where it converts to results.
JSON-LD vs Microdata vs RDFa
There are three ways to write structured data. JSON-LD is a self-contained block, separate from your HTML. Microdata and RDFa weave attributes into the visible markup. Google supports all three, but recommends JSON-LD, and it is far easier to maintain because it is not tangled into your templates. Use JSON-LD unless you have a specific reason not to.
What ImageObject markup actually looks like
It is less intimidating than it sounds. A complete, valid ImageObject for a licensable photograph is just a small block of JSON-LD in the page:
{
"@context": "https://schema.org",
"@type": "ImageObject",
"contentUrl": "https://example.com/navy-linen-wedding-suit.jpg",
"caption": "Navy linen three-piece wedding suit, tailored fit",
"creator": { "@type": "Person", "name": "Your Studio" },
"license": "https://example.com/licence",
"acquireLicensePage": "https://example.com/buy-licence"
}Strip the last two lines and you have a perfectly good ImageObject for a non-licensable image. The structure is the same whether you write it by hand or a plugin generates it — knowing the shape helps you sanity-check what your tools produce. Note the absolute contentUrl: that is the field that breaks most often, and it has to be the full https:// path, not a relative one.
Testing it, and the failures that hide
Schema fails silently. There is no error message when it is wrong — the rich result simply never appears, which is the worst kind of bug because nothing tells you it is broken. So testing is not optional; it is the only way to know your markup works. Two tools do the job: Google’s Rich Results Test (paste a live URL, see whether the image fields are detected and valid) and the Schema Markup Validator (checks the syntax against the schema.org spec). Test the live page, not a staging copy, because a relative URL that resolves on staging can break in production. Beyond the broken contentUrl, the failures that hide are: duplicate schema (two plugins each emitting a block, which can produce conflicting or invalid output), a contentUrl pointing at an image that has been deleted or moved, and schema describing an image that is not actually on the page. Catch all of these by testing the real, published URL.
Adding image schema in WordPress
Three routes, in rough order of effort. By hand, writing JSON-LD into the page — full control, most work, easiest to get a URL wrong. Through an SEO plugin’s schema controls — Rank Math and others can output ImageObject as part of article or product schema. Or through a gallery plugin that generates it automatically for the galleries it manages. A note on the SEO-plugin route: it often already emits ImageObject as part of the Article or Product schema for a page, so before you add a second block by hand, test the page and see what is already there — you may find the work is done, or that adding more would create the duplicate-schema problem above.
That last route is where the effort question resolves itself for image-heavy sites. FotoGrids generates Schema.org ImageObject and ImageGallery markup for every gallery automatically in its Pro tiers, alongside Open Graph tags and an image sitemap — so the four-cases decision is made once at the gallery level rather than image by image. Whichever route you choose, the rule from earlier holds: mark up the images doing SERP work, test them, and leave the rest.
Tip. The most common schema failure is a broken contentUrl. A wrong or relative URL silently kills the rich result with no error. Always use the full absolute URL and test the live page, not a staging copy.
Key takeaways
- Image schema matters for four cases: products, recipes, article heroes, and licensable images.
- For everything else,
og:imageplus good alt text does the same job. - The 2026 preferred-image update is a real new lever most sites have not used.
- Use JSON-LD, mark up only the images doing SERP work, and always test the live URL.
Does every image need structured data?
No. Schema earns its place on product, recipe, article-hero, and licensable images. For decorative or editorial images, a good og:image tag and alt text do the same job with far less effort.
JSON-LD or Microdata for image schema?
JSON-LD. Google recommends it, and because it is a self-contained block rather than attributes woven into your HTML, it is much easier to maintain.
What is the most common image schema mistake?
A broken or relative contentUrl. It kills the rich result silently, with no error message. Always use the full absolute URL and test the live page with Google’s Rich Results Test.