Most advice on how to create image sitemap files starts with the markup and skips the question that matters: does your site need one? Plugins generate them by default, audit tools flag their absence, and the result is that plenty of sites maintain an image sitemap that tells Google nothing it did not already know.
The format is simple, and it got simpler when Google deprecated most of its optional tags. The decision about whether to bother is where the real work is, so this piece covers that first and the markup second.
What an image sitemap is for
Google states the purpose in one sentence on its image sitemaps documentation: “Image sitemaps are a way of telling Google about other images on your site, especially those that we might not otherwise find (such as images your site reaches with JavaScript code).”
The key phrase is “might not otherwise find”. An image sitemap is a discovery aid. It does not rank images, it does not describe them, and it does not compensate for a page Google cannot index. If Googlebot already sees an image in the HTML of a page it crawls, listing it again adds little. Our guide to XML sitemaps and SEO makes the same point about page sitemaps: they help discovery, not ranking.
Do you need one? The honest answer for most sites
Generally, no. A site whose images are in plain img tags, on pages that are crawlable and indexed, is already exposing those images to Google in the most direct way possible. That covers most blogs, most brochure sites and many shops built on standard themes.
The cases where an image sitemap earns its place are the ones Google’s own wording points at. Galleries that build their markup with JavaScript, lightboxes that load full-size images only on interaction, infinite-scroll grids and images served from a separate domain are all places where discovery can fail. If your images matter for traffic, our guide to Google Images SEO covers the factors that decide whether they rank once found.
| Situation | Image sitemap useful? | Why |
|---|---|---|
| Images in plain img tags on indexed pages | Usually not needed | Google finds them in the HTML |
| Images reached with JavaScript | Yes | Google’s own example of images it “might not otherwise find” |
| Images hosted on a CDN domain | Can help | Allowed if both domains are verified in Search Console |
| Pages with many images | Possible | Up to 1,000 image tags per page element |
| Wanting captions, titles or licence data in the sitemap | No | Those tags are deprecated |
The pattern in that table is consistent: the sitemap matters in proportion to how hard your images are to find without it. Start by checking whether Google already sees them, for example by inspecting a gallery URL in Search Console and looking at the rendered HTML, before you build anything.
How to create image sitemap markup
You do not need a separate file. Image entries can sit inside an existing page sitemap: each page gets its usual url element, and the images on that page are listed inside it. Two things are required: the image namespace declared on the root element, and the two image tags.
- <image:image> wraps the information for one image.
- <image:loc> holds the image URL.
A minimal image sitemap example looks like this:
The namespace must match exactly: http://www.google.com/schemas/sitemap-image/1.1. A typo there and the image tags are not read as image tags. Each url element can carry up to 1,000 image entries, which is more than almost any real page needs.
The tags you can stop using
Older guides, and some plugins, still output four optional tags that Google has deprecated: <image:caption>, <image:geo_location>, <image:title> and <image:license>. If your sitemap still contains them, they do no harm to discovery, but they do no work either. Removing them makes the file smaller and easier to check.
The deprecation is a useful signal about where image context now comes from: the page. Captions belong in the page markup, descriptions belong in alt text, and licensing belongs in structured data on the page. Our guide to image alt text covers the part of that most sites get wrong.
CDN images, JavaScript galleries and submission
Images served from a CDN are a common reason to want an image sitemap, because the image URLs sit on a different host from the page. Google allows that, on one condition: both domains must be verified in Search Console. If the CDN hostname is not verified, do not assume the cross-domain entries will be trusted.
JavaScript galleries are the other case. If a gallery only inserts its images after a click or a scroll, Google may never see them in the rendered page. Our piece on lazy loading and SEO explains which loading patterns keep images visible to Googlebot; fixing the loading is better than papering over it with a sitemap, but the sitemap is a reasonable backstop.
Once the file exists, reference it from robots.txt or submit it in Search Console like any other sitemap. If you are auditing a site you did not build, our guide on how to find a website’s sitemap shows where image entries usually hide.
Validating the file, and what it cannot tell you
Validate the XML before submitting it. A malformed file, a wrong namespace or image URLs that return errors will undermine the entries that are correct. Check that every image URL resolves, that it is not blocked by robots.txt, and that the page each image is listed under is itself indexable.
Then keep expectations straight. An image sitemap helps Google find images; it does not promise that Google will index them, show them in results, or rank them above anything else. That is the limitation worth stating plainly: Search Console can tell you a sitemap was read, but it will not tell you whether an individual image in it was found because of the sitemap or would have been found anyway. You cannot measure the sitemap’s marginal effect, which is a further reason to build one only where discovery is a real problem.
For most sites, the better use of an afternoon is making sure images are in the HTML, load without interaction and carry useful alt text. Do that, and the image sitemap becomes what Google describes it as: a way to cover the images it might otherwise miss.
Frequently asked questions
Does every site need an image sitemap?
No. Sites whose images are in plain img tags on indexed pages generally do not. Google describes image sitemaps as a way to tell it about images it might not otherwise find, such as those reached with JavaScript.
Which tags does an image sitemap need?
The image namespace on the root element, plus <image:image> for each image and <image:loc> for its URL. Caption, title, geo location and licence tags are deprecated.
Can images in the sitemap be on a CDN?
Yes, if both your site’s domain and the CDN’s domain are verified in Search Console.
How many images can I list per page?
Up to 1,000 image tags per page element, according to Google’s documentation.
The takeaway An image sitemap is a discovery aid for images Google might miss. Build one for JavaScript galleries and CDN-hosted images, use only the two required tags, and skip it if your images already sit in plain HTML.
