What an image sitemap still does
Google discovers most images by parsing <img> tags during a normal crawl. If your images sit in plain HTML on pages that already get crawled, an image sitemap adds close to nothing, and it is honest to say so.
It earns its place in 3 situations:
- Images loaded by JavaScript. Lazy-loaded galleries, carousels that inject sources on scroll, anything behind a click. If the URL is not in the initial HTML, the sitemap may be the only place Google sees it.
- Deep or rarely crawled pages. Product images on page 40 of a catalog get discovered slowly. Listing them shortens that path.
- Images on a separate host. A CDN domain that has few inbound links of its own benefits from being named explicitly.
If none of those describe your site, spend the time on alt text and file naming instead. Those still move image search results; an image sitemap for well-linked images mostly moves nothing.
One URL entry per page, all its images inside
The structural rule people get wrong: image entries are children of a page, not siblings. Every image belongs to the page it appears on, and each page gets exactly one <url> element carrying all of its 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://www.example.com/tours/patagonia</loc>
<lastmod>2026-07-14</lastmod>
<image:image>
<image:loc>https://cdn.example.com/img/patagonia-hero.jpg</image:loc>
</image:image>
<image:image>
<image:loc>https://cdn.example.com/img/patagonia-camp.jpg</image:loc>
</image:image>
</url>
</urlset>
2 things to note. The xmlns:image declaration on <urlset> is mandatory: without it the image: prefix is undefined and a validating parser rejects the whole file. And the page appears once, with 2 images inside, rather than twice with one image each. Duplicate <loc> values in one sitemap are a spec violation.
The generator enforces the one-entry rule for you and caps a page at 1,000 images, which is Google's documented per-page maximum. Anything past that is discarded rather than written, since Google ignores the overflow anyway.
The 4 tags that were retired in 2022
This is the part most tools still get wrong. The image sitemap extension originally defined 6 tags. Google now reads exactly one.
image:loc- still live. The image URL. This is the tag.image:caption- retiredimage:title- retiredimage:geo_location- retiredimage:license- retired
Google announced the deprecation of caption, title, geo_location and license in 2022 and stopped processing them. They remain valid XML, so a validator will not complain, which is exactly why they survive in old templates and in generators nobody updated. They just do nothing.
This generator emits image:loc only. If you inherited a sitemap stuffed with captions, deleting them is safe and shrinks the file, sometimes by half. Move the caption text into a real <figcaption> and the alt attribute, where it still counts.
Licensing did not disappear as a concept, only as a sitemap tag. Google now reads license information from ImageObject structured data on the page.
Filling the fields
urls takes one page per line. Images go after a pipe, comma or space separated:
https://www.example.com/tours/patagonia | https://cdn.example.com/img/patagonia-hero.jpg, https://cdn.example.com/img/patagonia-camp.jpg
https://www.example.com/tours/iceland | /img/iceland-hero.jpg
Relative image paths resolve against the page's own origin, or against baseUrl if you set one. Set baseUrl whenever you are pasting relative paths, and set it if the file might exceed 50,000 URLs, because a split produces a sitemap index and index entries must be absolute.
sitemapType is already on image for this page. It exists because the same engine renders standard, HTML, news, video, WordPress and visual sitemaps.
lastmod offers 3 behaviors: omit unless a per-line column supplies it, stamp today on every URL, or take it only from the per-line column. Resist "today for every URL". A sitemap that claims every page changed today is a sitemap Google learns to distrust, and losing lastmod credibility costs you more than the tag ever gained.
changefreq and priority default to omitted, and that default is correct. Google has said for years that it ignores both. Priority in particular is relative within a single sitemap and has no cross-site meaning, so setting everything to 1.0 achieves precisely nothing. The auto-by-depth option exists for teams whose internal tooling expects the tag.
Crawlability beats markup, always
An image sitemap is a suggestion. A robots.txt rule is an instruction, and the instruction wins.
The most common wasted afternoon: a team generates a beautiful image sitemap while robots.txt still carries Disallow: /wp-content/uploads/ from a staging config, or blocks the CDN host entirely on a separate robots file. None of the listed images will be fetched. The sitemap is not broken; it is being overruled.
Before you submit, check 3 things:
robots.txton the image host, not just the page host.cdn.example.com/robots.txtis a different file and it needs to allow crawling too.- Direct fetches. Open an
image:locvalue in a private window. A 403 from a hotlink-protection rule means Googlebot gets a 403 as well. - Response type. Signed CDN URLs that expire are useless in a sitemap. Use stable, public paths.
Submitting it
Upload the file to your web root, reference it from robots.txt with a Sitemap: line, and submit the URL in Search Console. Google retired the sitemap ping endpoint in 2023, so scripts that still hit google.com/ping?sitemap= are calling a dead URL.
You can also skip the separate file. image:image blocks are legal inside a standard sitemap, so if you already publish one, adding the xmlns:image declaration and nesting the blocks in place is one fewer file to keep in sync. A separate file is easier to diff and easier to hand to a client, which is usually why people keep them apart.
For teams generating pages continuously, BlazeHive handles SEO content end to end, sitemaps included.