Menu
By the ImageSEO Team. ~10 min read.
An image sitemap is a list of your image URLs, written in XML, that you hand to Google. It is not a special kind of file. It is a small set of extra tags you drop inside a normal sitemap. Here is the honest answer on whether you need one: most sites do not. If your images sit in plain <img src="..."> tags in your HTML, Google finds them while it crawls the page. A standard sitemap plus good alt text and filenames does the job. You need image sitemap tags when your images are hard to find — loaded by JavaScript, injected after the page renders, or served from a CDN. This guide covers the syntax, the limits, and how to tell which group you are in.
Google’s own documentation frames image sitemaps as a discovery tool. They tell Google about images it might not otherwise find — and it names JavaScript-loaded images as the main example. That framing matters. An image sitemap does not make an image rank. It makes an image findable. Those are different problems with different fixes.
There are two ways to ship one, and Google treats them the same:
Google’s docs say either approach is equally fine. The choice is about how you want to manage and measure the file, not about how Google treats it.
Here is the smallest correct image sitemap. One page, two images:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:image="http://www.google.com/schemas/sitemap-image/1.1">
<url>
<loc>https://example.com/espresso-machines/</loc>
<image:image>
<image:loc>https://example.com/img/breville-barista-pro-side.jpg</image:loc>
</image:image>
<image:image>
<image:loc>https://example.com/img/breville-barista-pro-detail.jpg</image:loc>
</image:image>
</url>
</urlset>Four things are doing the work here:
xmlns:image="http://www.google.com/schemas/sitemap-image/1.1" is the part people get wrong. It has to match exactly, character for character. It is an identifier, not a page you visit — do not “fix” the http to https. Without it, the image: tags are meaningless and parsers throw them away.<loc> is the page. The HTML page a visitor lands on.<image:loc> is the image file. The actual .jpg, .webp or .png.<image:image> block goes inside the <url> block for the page that shows it. Never outside.A dedicated image sitemap uses the exact same markup. You just put it in its own file and list that file in your sitemap index. The tags do not change.
Google’s documentation now lists two required tags and nothing else: <image:image> and <image:loc>. There are no optional tags left.
That is a real change, not a doc trim. On 6 May 2022 Google announced it was deprecating four image sitemap tags: image:caption, image:geo_location, image:title and image:license. The announcement stated they would have no effect on indexing or search features after 6 August 2022. Google also said leaving them in place causes no harm — so if your plugin still writes them, you have nothing to clean up. They simply do nothing.
The replacements Google pointed to are the ones this site talks about constantly:
image:caption and image:title — write proper alt text and visible captions on the page itself. That is where Google reads meaning now.image:license — Google’s stated advice is to keep licensing data in IPTC photo metadata, embedded in the file.image:geo_location — put the location in the page copy and the alt text, where a reader would expect it.The practical takeaway: an image sitemap carries one signal, the URL. Everything else about the image has to live on the page.
<url> block can hold up to 1,000 <image:image> tags. This is per page, not per site. Most pages carry fewer than 30 images, so it rarely matters. It does matter on gallery pages, archive pages and large category listings.<image:loc> can point at a different domain than <loc>. That is how CDN-hosted images work. Google asks that you verify the CDN domain in Search Console so it can report crawl errors to you.Most of the advice online treats this as a yes/no question. It is not. Here is the honest version, by scenario:
| Your situation | Dedicated image sitemap? | What to do instead |
|---|---|---|
| Standard blog, images inside post content | No | Your SEO plugin already adds image:loc to the normal sitemap. Open the file and check. |
Plain <img> tags on the same domain |
No | Google finds these by crawling. Spend the time on filenames and alt text instead. |
| Gallery, slider or lightbox built by a page builder | Maybe — check first | Most SEO plugins only read images from post content and miss these. Add them with a filter, or list them in a dedicated file. |
| Images injected by JavaScript after page load | Yes | This is the case Google names by name. A sitemap is the reliable route. |
| Images served from a CDN or a media subdomain | Usually not, but verify | image:loc may be cross-domain. Verify the CDN domain in Search Console either way. |
| Large catalogue — thousands of product pages | Often yes | A separate file keeps each sitemap small and lets you track product image discovery on its own. |
| Images set as CSS background images | No — it will not help | Google does not index CSS background images. Move them into real <img> tags first. |
| Single-page app rendered fully in the browser | Yes, as a patch | Also fix server-side rendering. The sitemap treats the symptom, not the cause. |
Google renders pages, so it does see many JavaScript-loaded images. But rendering is a second pass, it is slower, and it can fail. If a gallery only builds its <img> tags after a user clicks or scrolls, those images may never enter the render at all. Listing them in a sitemap gives Google a path that needs no rendering.
A store with 4,000 products and six photos each has 24,000 images. Many sit behind a variant switcher, so only the first photo appears in the initial HTML. The rest load when a shopper picks a colour. Those hidden variants are exactly what a dedicated file is for — and variant photos are often the ones that win in Google Images, because shoppers search by colour and model.
When your images live on cdn.example.com and your pages live on example.com, some plugins rewrite the sitemap URLs correctly and some do not. A dedicated file gives you one place to check. Verify the CDN domain in Search Console so crawl errors on the image host reach you.
This one is underrated. Search Console reports on each submitted sitemap separately. Split your images into their own file and you can watch image discovery move on its own, instead of guessing inside one combined number.
Start with the gap that catches people out. WordPress has generated its own sitemap since version 5.5, at /wp-sitemap.xml. It lists page URLs only. It has no image support at all. If core sitemaps are all you run, you do not have an image sitemap — you have a page list.
The three main SEO plugins all add image tags, and all three do it automatically:
image:loc. Three filters give you control: wpseo_xml_sitemap_img to remove images, wpseo_xml_sitemap_img_src to rewrite the URL for a CDN, and wpseo_sitemap_urlimages to add images the plugin failed to spot.We ran the check on our own site while writing this. Our blog sitemap holds 142 page entries. Only 35 of them carry any image:image tags. The other 107 list no images at all.
That is not a plugin bug. Those posts hold their images inside custom HTML blocks that the plugin’s content parser does not read. The plugin is doing what it was built to do. It just does not see everything. If we had assumed “the plugin handles it”, we would have been wrong about three-quarters of our own pages.
Run the same check on yours. One line, no tools to install:
curl -s https://yoursite.com/post-sitemap.xml | grep -c "image:image"That prints how many image entries exist. Compare it to how many images you know are on those pages. A big gap tells you the parser is missing something. No terminal? Open the sitemap in your browser and use Ctrl+F for image:loc.
Five checks, in the order that finds problems fastest:
& in a filename is the usual culprit — it has to be written as &.sitemap-image/1.1. Missing or misspelled means every image tag is being ignored./img/photo.jpg do not work. Copy three image URLs, paste them into a browser, and confirm each one loads.grep command above. A number far below what you expect means the generator is missing images.One expectation to set: the Search Console Sitemaps report shows fetch status, discovered URLs and errors. It does not give you a separate image count. To see whether images are actually earning anything, use the Performance report and switch Search type to Image.
image-sitemap.xml — and click Submit.robots.txt file as a Sitemap: line. That is how other crawlers find it.Be realistic about timing. Submitting a sitemap is a request, not a promise. Google decides what to crawl and what to keep. Discovery of new images usually takes days to weeks, and some images will never be indexed. If nothing at all is picked up after a month, the problem is upstream — blocked paths, broken URLs, or images Google judges as low value.
A sitemap is one link in a chain. On its own it does very little. Here is how it connects to the other four levers:
<image:loc> value is the filename. Putting IMG_4821.jpg in a sitemap does not improve it. Fix the name first, then list it. See how to name images for SEO.loading="lazy" is safe — the src is in the HTML, so Google reads it. The risk is old JavaScript lazy-load libraries that leave src empty until a scroll event fires. Those images can be invisible to a crawler, and they are the strongest case for a sitemap.src URL only, never the srcset variants. Variants are delivery alternatives, not separate images. Our responsive images guide explains which URL Google actually indexes.Read in order, that is the honest priority list. If your filenames are camera defaults and your alt text is empty, an image sitemap will not save you. Fix those two first — they are what Google reads once it arrives.
ImageSEO handles the two upstream levers automatically on WordPress and WooCommerce: it reads each image and writes descriptive alt text and an SEO filename, in bulk, across an existing media library. Your sitemap plugin keeps generating the XML — it just ends up pointing at images that are worth finding. See how it works on WordPress →
| Mistake | What happens | Fix |
|---|---|---|
Namespace URL changed to https or misspelled |
Every image tag is silently ignored | Use http://www.google.com/schemas/sitemap-image/1.1 exactly |
<image:image> placed outside <url> |
Invalid structure, file rejected | Nest it inside the <url> block for the page that displays the image |
| Relative image paths | Google cannot resolve the URL | Always use full absolute URLs with the protocol |
Listing every srcset variant |
File bloat, no extra benefit | List the src URL only |
| Images sit in a folder blocked by robots.txt | Never crawled, sitemap or not | Unblock the path, then resubmit |
| Expecting a ranking lift from the sitemap alone | Nothing moves | Treat it as discovery; alt text and filenames do the ranking work |
Still hand-writing image:caption and image:title |
Ignored since August 2022 | Harmless to leave, but move that effort to on-page alt text |
| Dedicated file never listed in the index or submitted | Google never fetches it | Add it to the sitemap index, robots.txt and Search Console |
Most sites do not. If your images are in plain <img> tags in the HTML, Google finds them by crawling the page. You need image sitemap tags when images are hard to discover: loaded by JavaScript, revealed only after a click, or hosted on a separate CDN domain. Check your current sitemap before building anything — your SEO plugin may already be adding the tags.
No, not directly. It is a discovery mechanism. It helps Google find images it might otherwise miss. What an image ranks for is decided by alt text, the filename, the surrounding page content and page quality. An image that was already being crawled gains nothing from being listed.
Yes. Google’s documentation says a regular sitemap with image tags and a dedicated image sitemap are equally fine. Add the image namespace to your <urlset> line and nest <image:image> blocks inside your existing <url> entries. Most WordPress SEO plugins already work this way.
Up to 1,000 <image:image> tags inside a single <url> entry. The wider file limits still apply: 50,000 URLs or 50 MB uncompressed per sitemap file. Past either limit, split into several files and reference them from a sitemap index.
Yes, and this is the one place image sitemaps differ from regular ones. The <image:loc> URL may sit on another domain, which is what makes CDN hosting work. Google asks you to verify the hosting domain in Search Console so it can report crawl errors on those images to you.
Core WordPress does not. The built-in sitemap at /wp-sitemap.xml lists page URLs only, with no image support. Yoast SEO, Rank Math and All in One SEO all add image tags automatically, and all three read images from post content — so gallery, slider and background images are commonly missed.
image:caption and image:title?On-page signals. Google deprecated image:caption, image:title, image:license and image:geo_location in May 2022, with no effect after 6 August 2022. Alt text and visible captions carry the meaning now. For licensing, Google points to IPTC metadata embedded in the image file.
Days to weeks, with no guarantee. Submitting a sitemap is a request, not an instruction. Google chooses what to crawl and what to keep. If nothing is picked up after about a month, look upstream: blocked robots.txt paths, broken image URLs, or pages Google has judged as low value.
