Images During a Site Migration
Last updated
Images are the asset class most often half-migrated, because the pages move and the pictures do not. Image results are ranked in the context of the page that hosts them, so an image URL cannot hold a position on its own: it needs a live host page, a live image file, and the connection between the two intact. Break any one of those and the result drops out.
This guide covers the image-specific work inside a migration. The migration itself, from redirect map to post-launch monitoring, is the site migration guide.
What are the three ways images fail in a migration?
Three failure patterns follow from how image results are ranked, in increasing order of damage:
- Images left on the old domain, referenced by pages on the new one. Referral traffic holds at first, because the page redirects work. But the old domain’s pages fall out of the index over the following months, the images lose the host page context they were ranking on, and there is no image-level redirect to consolidate anything onto the new URLs. The decay is slow enough that it is usually noticed long after the migration is signed off.
- Images referenced but never uploaded to the new site. Googlebot renders the new page, finds the image missing, and the image is dropped from results. This is the fastest and most complete loss of the three, and the easiest to catch with a pre-launch crawl.
- Images replaced with visually different versions at the same time as the move. Re-shot photography or a redesigned graphic is a new asset as far as Google is concerned, whatever the URL does. Treat a visual refresh as a separate change from the migration. Note what this does not mean: still redirect the old image URLs. Other sites’ embeds depend on them, and Google’s guidance to move image URLs carries no exception for changed content. What you drop is the expectation that a new photograph inherits the old one’s positions, not the redirect itself.
What is safe to change during the move?
Converting formats (JPEG or PNG to WebP or AVIF) is fine and worth doing for the payload reduction. Renaming files to something descriptive is fine too, as long as each old URL has its own one-hop 301 to its specific replacement. What breaks it is the shortcuts: redirect chains, and batch-redirecting a set of missing images to a single fallback like a logo. Google’s site move guidance warns against redirecting many old URLs to “one irrelevant single URL destination”, which “might be treated as a soft 404 error”.1 That instruction is written about pages rather than images, but the reasoning transfers: a redirect is a claim that this asset moved here, and a logo standing in for fifty missing photographs is not that.
Is a URL restructure on the same domain an image migration?
Yes. Keeping the domain makes it easy to assume the images are unaffected, and they are not: the host pages have moved, and that is what image results depend on. One approach circulates for this case, keeping the old image URLs live so that a Google Images click lands on the old HTML page, which then redirects to the new one. It does work, and the user arrives in the right place, because the Visit click goes to the host page rather than the file. Treat it as a bridge rather than a fix. The old page is redirecting, so it leaves the index over the following months, and once it does the old image has no live host page and follows it out. If a particular image genuinely drives traffic, the durable version is to keep that image embedded on the new page.
Why do alt text and image references need their own migration?
Alt text and the references that point at images are separate assets from the files. If image results depend on host page context, then the alt attribute is part of what ranks, and it is routinely lost in a CMS migration when the media library is re-imported: the files arrive, the metadata does not. This is the one image failure that hits migrations where the domain never changes at all, so it survives a redirect-focused QA pass untouched. Export alt text alongside the image URLs when you baseline, and diff it after launch rather than spot-checking.
The same applies to every reference pointing at an image, which a page-level redirect map does not touch: <img> and srcset paths hardcoded in content bodies, Open Graph and Twitter Card image tags, the image property in JSON-LD blocks, and any image entries in the sitemap. These can all keep pointing at old URLs long after the pages themselves have moved, leaving working pages that reference a domain you are about to switch off. Crawl the new site for external image references before decommissioning anything.
How long does image recovery take?
Longer than page recovery. Google’s guidance for a site move overall is that a small to medium site takes a few weeks for most pages to move across, with larger sites taking longer.1 Google publishes no image-specific timeline, and practitioners consistently report images taking longer than that to settle. Plan for it rather than treating a slow image recovery as evidence something is broken.
Two things help. Submitting the new sitemap aids discovery, and an image sitemap is worth having if you do not already run one; note that image sitemap entries attach <image:image> elements to a host page’s <url> entry rather than listing image URLs on their own, so there is no standalone list of image URLs to submit.2 Second, reference each image by one consistent URL across the site. Google asks for this explicitly, so that it can cache and reuse an image rather than requesting it repeatedly, and notes that images referenced across many pages draw on the site’s overall crawl budget.3 A migration that scatters the same asset across several URL variants makes recrawling slower at exactly the point you need it fastest.
Images served from a CDN or a media subdomain are supported and insulate image URLs from future template changes; the conditions on robots.txt, sitemap hosts and Search Console property type are covered in image SEO.
Image migration checklist
- Baseline every image URL with its alt text and host page before anything moves.
- Map each old image URL to one new URL with a single-hop 301; no fallbacks to a logo.
- Keep visual changes out of the migration; redirect old files even where the picture has changed.
- Crawl the new site for old-domain references in
<img>,srcset, Open Graph tags, JSON-LD and the sitemap. - Diff alt text against the baseline after launch.
- Submit the sitemap with image entries, and give image results longer than pages to recover.