---
title: "Images During a Site Migration"
description: "How to move images through a site migration without losing image search traffic: the three failure patterns, what is safe to change, alt text, and recovery time."
tldr: "Images are the asset most often half-migrated, because the pages move and the pictures do not. Google ranks an image in the context of the page that hosts it, so an image result needs a live host page, a live file and the link between them; break one and the result drops out. The three failure patterns, in rising order of damage, are images left on the old domain, images never uploaded to the new site, and images swapped for visually different versions during the move. Format conversion and renaming are safe with a one-hop 301 per file; batch-redirecting missing images to a logo is not. Alt text and hardcoded image references are separate assets a redirect map never touches, and image recovery lags page recovery."
publishDate: 2026-09-21
author: "Liam Hayward"
---
An image migration is the part of a site move that carries image files, their URLs and their references across, and it is the part most often left half-done: the pages move and the pictures stay behind. That matters for search because an image URL cannot hold a position on its own; Google ranks it in the context of the page that hosts it, so the image file, the host page and the link between them all have to survive the move.

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](/resources/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 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 SEOs 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](/on-page-seo/image-seo/).

## Image migration checklist

1. **Baseline** every image URL with its alt text and host page before anything moves.
2. **Map** each old image URL to one new URL with a single-hop 301; no fallbacks to a logo.
3. **Keep visual changes out of the migration**; redirect old files even where the picture has changed.
4. **Crawl the new site for old-domain references** in `<img>`, `srcset`, Open Graph tags, JSON-LD and the sitemap.
5. **Diff alt text** against the baseline after launch.
6. **Submit the sitemap** with image entries, and give image results longer than pages to recover.

[^1]: [Move a site with URL changes — Google Search Central](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes)

[^2]: [Image sitemaps — Google Search Central](https://developers.google.com/search/docs/crawling-indexing/sitemaps/image-sitemaps)

[^3]: [Google Images best practices — Google Search Central](https://developers.google.com/search/docs/appearance/google-images)