Keeping Image Rankings Through a Redesign or Migration

Migration checklists cover pages thoroughly and images barely at all. The usual treatment is a line reading "check images display correctly", which verifies the one thing that would have been noticed anyway.

Meanwhile every image URL on the site is changing, and each of those URLs carries index history, inbound links and — for anything performing in image search — accumulated ranking. Unlike a page, nobody has a list of them, so nobody notices what was discarded.

This is the work that keeps it. It is not difficult; it is just entirely unglamorous and it has to be done before launch, because the input data stops existing afterwards.

What an image URL is actually holding

It helps to be concrete about what is at risk, because "images" sounds low-stakes next to page redirects.

An image URL that has been indexed for a while holds an index entry that can appear in Google Images, in Discover and increasingly in AI-generated answers; inbound links, since images are linked and embedded by other sites more often than people assume; hotlink references from partners, directories and press coverage; and crawl history establishing the URL as stable.

A 404 discards all of it. Not degrades — discards. And because image traffic is usually reported inside overall organic numbers rather than separately, the loss shows up as a modest unexplained dip that gets attributed to the redesign in general.

For sites where image search is a real channel — anything visual, and most local and product businesses — this is not a rounding error.

Before launch: the export

Everything downstream depends on having a list of the current image URLs. That list is only obtainable while the current site is live, which is why this step cannot be deferred.

Take four exports and keep them somewhere that survives the launch:

1. A full crawl of image URLs from Screaming Frog or equivalent, with the file size, the alt text, and the page each image appears on. This is the master list.
2. Search Console image-search performance, ninety days, with impressions, clicks and queries. This is your baseline and your priority list.
3. The current image sitemap, saved as a file.
4. Inbound links pointing at image URLs, from whatever backlink tool you have. Usually a short list, and usually the highest-value entries on it.

Export two is what turns this from a bulk exercise into a targeted one. Most sites find that a small fraction of images account for nearly all image-search impressions. Those are the URLs where a redirect is essential. The remainder can be handled with a pattern rule and no individual attention.

Building the mapping

The mapping file has two columns: old URL, new URL. Producing it is the actual work.

Three situations, in decreasing order of convenience:

The path structure changed predictably. /wp-content/uploads/2024/03/name.jpg becomes /assets/images/name.webp. A regex handles the whole library in one rule. Verify against a sample of twenty rather than trusting the pattern.

Filenames survived but paths did not. Match on the filename stem, ignoring extension and any size suffix the old CMS appended. A short script joining the two crawls on stem resolves most of the library; what fails to match is your exception list.

Nothing survived. The new platform generates opaque identifiers. Here you match by the page each image appears on: old page X had image A, new page X has image B, therefore A maps to B. This is imperfect for pages with many images, and imperfect is substantially better than nothing.

For images that genuinely no longer exist, redirect to the page that replaced their context — the product page, the article, the service page. Not the homepage. A blanket redirect of a thousand image URLs to the homepage is treated as a soft 404 and preserves nothing, and it is what the default catch-all rule will do if you let it.

If you are changing filenames as part of the rebuild — a reasonable thing to do if the old ones were IMG_4471.jpg — do it in the mapping, deliberately, with redirects. What a good image filename actually looks like is worth applying at this moment specifically, because it is the one time the renaming cost is already being paid.

Redirects, and what tends to go wrong

Use 301s. Permanent, cacheable, and understood to pass the history you are trying to preserve.

Situation	Redirect to	Note
Same image, new path	The new image URL	Bulk rule where the pattern allows
Image replaced by a new one	The replacement image URL	Match by page context
Image removed, context remains	The page that replaced its context	Not the homepage
Image and context both gone	410 Gone	Honest, and stops repeated crawling
Moving to a CDN hostname	The CDN image URL	Cross-host redirects are fine

Three failure modes account for most problems.

Redirect chains. Old path → interim path → new path. Each hop dilutes and delays. If the site has migrated before, the old rules are still in the config and your new rule will chain onto them. Flatten every chain to a single hop; a crawl of the old URL list will surface them immediately.

Redirecting images to HTML pages en masse. A rule that sends every .jpg request to a page is a soft 404 at scale. Map to images where images exist.

The catch-all firing first. Server rules are ordered, and a broad rule earlier in the file will swallow your specific image rules. Test the actual URLs, not the intent.

The launch-day checks

Run these within an hour of going live, because they catch the failures that are cheapest to fix immediately and expensive to fix in three weeks.

Fetch twenty old image URLs directly. Include the top ten from your Search Console export. Each should return 301 to a URL that returns 200. Use curl -I and read the chain, not a browser, which hides the hops.

Check robots.txt on every hostname serving images. New platforms ship restrictive defaults, and if images now come from a CDN there is a second robots.txt you have never seen. A disallow here removes the entire library from image search regardless of how good your redirects are.

Check response headers for X-Robots-Tag: noindex. Staging configurations carry this and it survives launch more often than it should. It is invisible in the HTML.

Confirm the new image sitemap lists URLs that actually resolve, and that they are the same URLs the rendered pages reference. A sitemap generated from the old structure is a common launch artefact.

Verify hotlink protection and signed URLs if either is in play. A referrer rule that blocks crawlers, or expiring URLs on public images, will both quietly remove your images.

Those last four are all hosting-layer issues rather than migration ones, and they are the most frequent cause of images vanishing after a launch that otherwise went fine. Where images live and how CDN configuration affects indexing covers the full set; at launch, the abbreviated version above catches the ones that matter.

The first eight weeks

Image re-crawling is slower than page re-crawling. A dip is normal. Not recovering is not.

Weeks one to two: expect image impressions to fall. Do not act on this unless a spot check of old URLs shows broken redirects. Watch the crawl stats report for image requests, which tells you whether re-crawling is happening at all.

Weeks three to six: impressions should be climbing back. Submit the new image sitemap if you have not. Check the coverage report for image-related errors, and re-run the top-twenty URL check, because rules do get changed during post-launch fixes.

Weeks six to eight: compare against the baseline. Recovery to roughly the previous level is a successful migration. A persistent gap means either a systematic redirect failure or a crawlability issue, and the diagnosis is the same ordered list as any images-missing problem — the causes of images not appearing in Google Images applies exactly, with the migration simply being what introduced the cause.

Give it the full eight weeks before concluding anything. Acting in week two on a normal re-crawl dip produces changes that then have to be untangled from the recovery.

The rebuild opportunity

One genuinely positive note. A migration is the only moment when touching every image is already budgeted, which makes it the cheapest time to fix things that are otherwise never worth a dedicated project.

Worth doing in the same pass: convert the library to WebP if it is still JPEG and PNG; set correct width and height attributes, which many older templates omit; fix the alt text on your top pages while you are in the templates; add ImageObject markup where it earns eligibility for something rather than everywhere; and set correct Open Graph images, which are a separate field set from your SEO images and are frequently lost entirely in a platform change.

This is also the moment to fix whatever the old platform made impossible. If the previous CMS controlled filenames and you are moving to one that does not, take the filenames back — WordPress image handling and its plugin ecosystem is a common origin for filename and sizing constraints that a migration is a chance to leave behind.

Then, once the dust settles at week eight, run a full pass over the new site. A systematic image audit after a rebuild reliably finds template defects introduced by the new theme — an oversized hero repeated across every page, a lazy-load rule applied to the LCP image — and finding those at week eight rather than at month nine is most of the value.

In short

Export the image URLs before you launch, because afterwards they no longer exist. Build a real mapping, prioritised by what Search Console says was actually performing. Redirect with 301s, no chains, images to images. Check robots.txt and headers on every hostname on day one. Measure against a baseline for eight weeks before drawing conclusions.

The whole thing is perhaps a day of work on a mid-size site, and it is the difference between carrying your image visibility across the rebuild and starting it again from zero.