Image Sitemaps: When You Actually Need One and How to Build It
Most sites do not need an image sitemap. Here is how to tell whether yours is one of the exceptions, the exact XML syntax, and the diagnostics to run before you build anything.
Image sitemaps get recommended far more often than they are needed. They appear on generic technical SEO checklists, someone builds one, images still do not appear in Google Images, and the actual cause — a Disallow line, or images injected by JavaScript that never render for the crawler — goes unexamined for another six months.
So the useful order is: diagnose first, build second. Most of the time the diagnosis makes the build unnecessary. Everything below reflects Google's sitemap documentation as of July 2026 — including one schema change that invalidates a lot of older tutorials.
Diagnose before you build
Run these four checks in order. Each takes a couple of minutes.
1. Is the image in the HTML?
View source — actual source, not the inspector's rendered DOM — and search for the filename. If it is only in the DOM, it is being injected by JavaScript. Googlebot does render JavaScript, but rendering is queued and less reliable than parsing HTML. Images that matter belong in the initial markup.
2. Is it a CSS background?
Background images are decoration as far as Google is concerned and generally do not appear in Google Images. If an image needs to be findable, it needs an <img> tag.
3. Is it blocked?
Open yourdomain.com/robots.txt and look for a Disallow covering /assets/, /uploads/, /media/, /static/ or your CDN path. This single line silently excludes entire image libraries and is the most common root cause by a distance.
4. What does Search Console see?
Run URL Inspection on the page, view the rendered HTML and the page resources. If the image is absent or failed to fetch, that is your answer — and no sitemap will change it.
Only if all four check out and images are still missing does a sitemap become the reasonable next step.
When a sitemap genuinely helps
| Situation | Why a sitemap helps |
|---|---|
| Images loaded by JavaScript | Gives a direct URL list independent of rendering |
| Images on a separate CDN domain | Declares them explicitly under the page they belong to |
| Large galleries behind pagination or infinite scroll | Many images are never reached by normal crawling |
| Images are the product — stock, real estate, marketplace | Image discovery is a primary business objective |
| Fresh image content published continuously | Faster discovery of a high-churn library |
| Very large site with limited crawl budget | Prioritises what you most want fetched |
If none of these describe your site, your effort is better spent on the filenames and alt text of the images you already have.
The syntax
Image entries live inside your normal sitemap using Google's image namespace. Add the namespace to the root element and nest image:image inside each url:
<?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/services/key-replacement</loc>
<image:image>
<image:loc>https://www.example.com/img/car-key-cutting-arlington-tx.webp</image:loc>
</image:image>
<image:image>
<image:loc>https://www.example.com/img/transponder-programming-tool.webp</image:loc>
</image:image>
</url>
</urlset>
Two things to note.
Only image:loc is supported. Google deprecated image:caption, image:title, image:geo_location and image:license in this schema. If a tutorial shows you those tags, it predates the change. Caption and title information belongs in the page markup; licence information belongs in structured data or IPTC metadata.
Images are declared under the page that uses them, not as standalone entries. The url is the page; the nested entries are the images on it.
Limits
- 1,000 image entries per page entry
- 50,000 URLs or 50MB uncompressed per sitemap file
- Split larger sets and reference them from a sitemap index
Cross-domain images
Listing a CDN image under a page on your primary domain is explicitly allowed. You should verify ownership of the CDN domain in Search Console so the data attributes correctly.
Generating it, not hand-writing it
A hand-maintained image sitemap is stale the day after you write it. Generate it from the same source your pages use.
Modern frameworks make this straightforward. In a Next.js App Router project a sitemap.ts file exports a function that returns the full URL list, and you build the image entries from the same content source the pages read — so publishing a post updates the sitemap automatically with no separate step. Equivalent mechanisms exist in every major CMS; the principle is that the sitemap should be derived, never authored.
While you are there, confirm two boring things: that robots.txt actually points at your sitemap, and that the sitemap URL it names returns a 200. A robots.txt referencing a /sitemap.xml that 404s is a surprisingly common combination, and it is exactly the sort of thing that survives for years because nobody looks.
A note on lazy loading and discovery
Lazy loading and image discovery interact in a way that catches people out. Native loading="lazy" is fine — the src is in the HTML, so a crawler parsing the markup sees the URL regardless of whether the browser has fetched it yet.
The problem is JavaScript-driven lazy loading of the older kind, where the real URL lives in data-src and a script swaps it into src on scroll. A parser reading the raw HTML sees a placeholder. Googlebot may resolve it during rendering, but you have made discovery conditional on a process that is queued, slower and occasionally skipped.
If you are on that pattern, the fix is to move to native lazy loading rather than to paper over it with a sitemap. Failing that, a sitemap is a reasonable mitigation — this is one of the genuine cases from the table above.
Errors you will actually hit
Sitemap problems are dull and specific. These are the ones that account for most of the wasted afternoons.
| Symptom | Usual cause | Fix |
|---|---|---|
| Sitemap "couldn't fetch" in Search Console | URL 404s, or is blocked by robots.txt | Load the sitemap URL in a private window; check robots.txt |
| Images listed but never indexed | Blocked directory, or images are CSS backgrounds | Fix crawlability first — the sitemap is not the problem |
| "URL not allowed" errors | Image or page URL on a domain you have not verified | Verify the CDN domain in Search Console |
| Sitemap shows stale URLs | Hand-maintained file, or a cached build artifact | Generate from the content source, never author by hand |
| Mixed http/https or www/non-www entries | Sitemap built with a hardcoded base URL | Use one canonical host constant everywhere |
| Sitemap grows past 50MB | Everything in one file | Split and use a sitemap index |
That fifth row is worth a moment. If your site redirects the apex to www (or the reverse), every sitemap entry must use the host that actually serves. Listing a URL that 301s means every crawl of your sitemap starts with a redirect — harmless in small doses, sloppy at scale, and a sign that some other part of your setup is probably using the wrong base URL too.
What about video and other media?
The same nesting pattern covers video, using the video:video namespace, and it has the opposite economics: video sitemaps carry a rich set of supported fields — title, description, thumbnail, duration, publication date — because Google cannot extract that information from the file the way it can infer an image's subject from its page context.
So the asymmetry is deliberate. Images are described by the page around them, which is why the caption and title tags were deprecated and why your alt text and filename carry the weight. Video is opaque by comparison, so the sitemap has to do the describing.
If you publish both, keep them in one sitemap with both namespaces declared rather than maintaining separate files. Fewer moving parts, fewer things to forget to regenerate.
Submitting and monitoring
Submit through Search Console under Sitemaps, and reference it from robots.txt:
Sitemap: https://www.example.com/sitemap.xml
Then watch the right numbers. Sitemap submission reports coverage of page URLs; it does not give you a per-image indexing report. For image visibility, use the Search Console Performance report filtered to the Image search type — that is the number that tells you whether any of this achieved anything.
Give it weeks rather than days. Image indexing runs slower than page indexing.
Which images belong in it
Not all of them. A sitemap listing every decorative flourish and UI icon on the site buries the images you actually care about in noise.
Include images that are content: product shots, project photography, illustrations that carry information, diagrams, team and premises photos. These are the files that could plausibly be a destination for someone searching Google Images.
Exclude images that are furniture: background textures, spacer graphics, icons, avatars, tracking pixels, and anything you gave an empty alt attribute to. If it was decorative enough to warrant alt="", it is decorative enough to leave out of the sitemap — the two judgements are the same judgement.
That rule has a pleasant side effect: it makes the sitemap a rough inventory of your genuinely meaningful imagery. If generating it produces a list of eleven files across a forty-page site, that is a finding in itself, and probably more useful than the sitemap.
The thing that matters more
A sitemap answers "where are my images." It does not answer "what are they of," and the second question is the one that determines whether an indexed image ever gets shown for anything.
An image with a descriptive filename, real alt text, relevant surrounding copy and a populated metadata block gives a crawler four consistent signals about its subject. The same image listed in a perfect sitemap with IMG_4471.jpg and an empty alt attribute gives it none. Discovery is a prerequisite, not an achievement.
Which is why, if you have limited time, the 12-item checklist is where it should go first — and why SEOpix writes the filename, description and metadata at generation time rather than leaving them for a cleanup pass that competes with everything else on your week.
Start free with 10 images a month, or see how it scales on the pricing page.
Frequently asked questions
Does my site need an image sitemap?+
Probably not. If your images are in standard img tags inside HTML that Google can crawl, they get discovered through normal crawling. Image sitemaps earn their place when images are loaded by JavaScript, served from a separate domain, buried behind galleries and lazy-load patterns, or when images are the product rather than illustration.
Will an image sitemap make my images rank better?+
No. A sitemap is a discovery mechanism, not a ranking signal. It can help Google find images it was otherwise missing, and finding them is a prerequisite for ranking, but a listed image with a meaningless filename and no alt text still has nothing to rank on.
Can I put image entries in my existing sitemap?+
Yes, and that is usually the better approach. Add the image namespace to your existing sitemap and nest image:image elements inside the relevant url entries. A separate image sitemap file is only worth the extra moving part when your image set is very large or generated by a different system.
How many images can one sitemap hold?+
Google allows up to 1,000 image entries per page entry, and standard sitemap limits apply overall — 50,000 URLs or 50MB uncompressed per file. Beyond that, split into multiple sitemaps and reference them from a sitemap index.
Do the image caption and title tags still work?+
No. Google deprecated image:caption, image:title, image:geo_location and image:license in the sitemap schema. Only image:loc — the image URL — is supported now. Any guide still showing the full tag set is out of date.
How do I check whether my images are indexed?+
Search site:yourdomain.com in Google Images for a rough view, and use the URL Inspection tool in Search Console on a specific page to see what Google actually rendered and fetched. If images are missing there, the problem is nearly always crawlability or rendering, not the absence of a sitemap.
Can a sitemap fix images blocked by robots.txt?+
No, and this is the most common misdiagnosis in this area. A blocked directory stays blocked regardless of what your sitemap says. Check robots.txt for a disallow on your assets, uploads or CDN path before you build anything else.
Let SEOpix handle the metadata
Filenames, alt text, EXIF fields and GPS coordinates written automatically as each image is generated. Start with 10 free images a month — no credit card required.
