Where Should Your Images Live? Image CDNs, Subdomains and SEO

Where an image file physically lives is treated as an infrastructure decision and handed to whoever manages hosting. It is also an SEO decision, because it determines whether the file can be crawled, whether it can be indexed, what metadata survives, and how quickly it arrives.

None of this is difficult. It is just a set of configuration details that live outside the CMS, which is exactly why they go unchecked for years while everyone audits alt text.

The three arrangements

Nearly every site uses one of three:

Same origin. Images served from example.com/images/…, straight from the application or its storage. Simplest possible arrangement, one hostname, nothing to coordinate.

CDN or image subdomain. Files served from cdn.example.com or a provider hostname, usually with on-the-fly resizing and format conversion. This is now the default for anything with real traffic.

Third-party host. Images live on a service you do not control — a marketplace, a DAM's public URLs, a page builder's asset host.

Google has been consistent that images on a CDN or subdomain are indexed normally, provided they can be crawled. There is no ranking preference for same-origin files. So the choice is about operational risk, not about a hidden penalty.

Arrangement	Crawl risk	Metadata risk	Portability	Best for
Same origin	Low — one robots.txt	Low unless the CMS re-encodes	High	Small and mid-size sites
CDN / subdomain	Medium — second robots.txt, second hostname	Medium — transformations often strip	Medium	Most sites at scale
Third-party host	Medium — their rules, not yours	High — no control	Low	Avoid for images you rely on

The right-hand column of that table is the real recommendation. The middle row is where most sites sit and where most of the failures happen, because it introduces a second hostname with its own configuration that nobody remembers to audit.

The four ways a CDN silently removes you from image search

These are the failures worth actively checking. Each is invisible on the rendered page — the images display perfectly — and each removes the file from Google Images entirely.

A robots.txt on the CDN hostname. This is the big one. cdn.example.com serves its own robots.txt, and providers frequently ship a restrictive default, or return a 404 that some setups handle badly. Your carefully audited main-domain robots.txt is irrelevant to files served from a different host. Fetch https://cdn.example.com/robots.txt in a browser right now and read what it says; on a surprising number of sites the answer is a blanket disallow nobody has ever looked at.

An X-Robots-Tag: noindex header. Storage buckets and some CDN presets add this at the edge. It never appears in the HTML, so an HTML-focused audit will not find it. Check with curl -I against an image URL and read the response headers.

Hotlink protection that catches crawlers. A referrer-based rule blocking requests without a matching referrer will block Googlebot, which does not send one. The image loads fine for visitors and returns 403 to the crawler. If you need hotlink protection, allowlist the search engine crawlers explicitly and verify by fetching the URL with no referrer.

Authentication or signed URLs. Signed URLs that expire are fine for private assets and fatal for public ones — the crawler fetches a URL that works today and 403s tomorrow, and the image drops out. Public images need stable, unsigned URLs.

If images are already missing from Google Images and you are working through causes, these four belong near the top of the list alongside the on-site ones covered in the ordered diagnostic for images that never appear. The distinguishing symptom is that everything on the main domain checks out and the images still are not there.

Metadata and the re-encoding problem

Image CDNs earn their keep by transforming files — resizing, converting to WebP or AVIF, adjusting quality. Every one of those transformations produces a new file, and by default most providers do not carry the metadata across, because metadata is bytes and the whole point is fewer bytes.

For most sites that is fine and even desirable. If you have deliberately written descriptive fields, author, copyright or GPS coordinates into your images, it is not fine — it means the work happened and then was undone at the edge, and nothing reports it.

The check takes a minute. Fetch the image from its real public CDN URL, not from your originals folder, and run ExifTool against what comes back. If the fields are gone, look for a "preserve metadata" or "strip metadata" setting in the transformation configuration and turn stripping off for the relevant paths.

Whether this matters depends on why you wrote the metadata. What each EXIF and IPTC field does and how much weight to give it is worth reading before you trade file size for fields you do not actually need — copyright and licence information is usually worth preserving, a full camera block on a generated image is not.

The same caution applies to format conversion at the edge. An automatic WebP or AVIF pipeline is one of the better things a CDN does, and it makes the manual format decision mostly moot, but it does mean the file a visitor receives is not the file you uploaded — so audit the delivered file, always.

Sitemaps and hostnames

An image sitemap lists image URLs as they are actually served. If your images come from cdn.example.com, those are the URLs that belong in the file, even though the page URLs are on the main domain.

This is legitimate and supported — cross-host image entries work when the hosts are verified in Search Console, or when the sitemap is cross-submitted. It is also a frequent source of quiet errors, because a sitemap generator built for same-origin hosting will happily emit main-domain image URLs that do not resolve, and the resulting warnings are easy to ignore.

Two things to verify: that the URLs in the sitemap return 200 when fetched directly, and that they are the same URLs the page actually references. A mismatch between the sitemap and the rendered HTML is common after a CDN migration and means the sitemap is describing a version of the site that no longer exists. How image sitemaps work and when they earn their place covers the format; the hosting-specific point is simply that the hostname must be the serving one.

What a CDN actually buys you, measured

It is worth being concrete about the upside, because "a CDN makes it faster" is often asserted and rarely quantified, and the quantity determines whether the configuration risk above is worth taking on.

Three things improve. Latency falls because the file is served from a location nearer the visitor, and on a page with twenty images that saving is multiplied. Concurrency improves because a CDN handles many parallel requests better than most origins. And transformation means the visitor receives a file sized and formatted for their device rather than whatever was uploaded, which is usually a far larger saving than the network one.

That third item is where most of the benefit sits, and it is easy to test. Load a representative page in devtools with the Network panel filtered to images, and compare total transferred image bytes against the sum of the original file sizes in your media library. On a site serving unoptimised originals the gap is frequently five to ten times, and closing it is worth more than any amount of latency tuning.

The measurement that matters most is the hero, since that is usually the Largest Contentful Paint element and the one whose arrival time is scored. Diagnosing an image-driven LCP properly is the right next step if the numbers here look poor, because a CDN improves delivery time without fixing discovery time, and discovery is more often the culprit than bandwidth.

Cache headers, filenames and change

The other reason hosting matters is what happens when an image changes.

Long cache lifetimes are correct for images — a year is standard — but only if the URL changes when the file does. If you overwrite hero.webp in place, visitors and intermediaries will keep serving the old bytes for as long as their cache says to, and you will get reports of an old logo appearing on some machines and not others.

The fix is a content hash or version in the filename, which build tools do automatically and CMS uploads generally do not. That works cleanly for build-time assets. For content images it creates a tension with descriptive filenames, since a hash is not descriptive, and the filename is one of the few genuinely textual signals attached to an image. The workable compromise is a descriptive stem with a short version suffix — arlington-workshop-bench-v2.webp — which keeps the words and changes the URL.

If a filename must change on an image that has been indexed, redirect the old URL to the new one. Image URLs accumulate links and search history the same as pages do, and a 404 discards it.

A short verification pass

Run this against your actual public image URLs, not your originals:

1. curl -I https://<image-host>/<path>.webp — expect 200, no X-Robots-Tag: noindex, and a sensible Cache-Control.
2. Fetch https://<image-host>/robots.txt and read it. Confirm image paths are not disallowed.
3. Fetch an image URL with no referrer header and confirm it still returns 200, proving hotlink rules do not catch crawlers.
4. Run ExifTool on the fetched file and confirm the fields you expect survived transformation.
5. Compare an image URL in your sitemap against the same image's URL in the rendered HTML. They should match exactly.
6. Confirm the CDN hostname is verified in Search Console if your sitemap lists cross-host image URLs.

Six checks, once, and then again after any migration or provider change. That is the entire discipline.

The recommendation

For most sites: serve images from your own domain or a CDN in front of it, keep the URLs public, stable and unsigned, preserve the metadata fields you actually rely on, and verify the CDN's robots.txt and headers once. Avoid depending on a third-party host for images that matter, because the failure mode is every image breaking simultaneously with the fix outside your control.

None of this makes images rank. It is the layer that determines whether the rest of your image SEO work is visible at all — and unlike most of that work, it is a handful of settings checked once rather than an ongoing chore. If your site is on a hosted platform where these settings are not exposed, the platform-specific constraints on Squarespace, Wix and Webflow explain which of these you can control and which you simply have to accept.