How to Audit Redirects After a Site Migration — and Decide What to Fix

A site migration is not finished when the new site goes live.

It is finished when every old URL lands where it should, without chains, loops or dead ends.

This article walks through a practical audit process: build the list of old URLs, crawl them through their redirects, read the results, and decide what to fix first.

Why audit redirects after a migration

When you change URL structure or move domains, 301 permanent redirects are the mechanism that passes indexing and link signals from old URLs to new ones.

Screaming Frog, whose crawler is built for exactly this job, notes that things go wrong regularly.

Redirects can point to the wrong targets, hop through multiple steps, or error out entirely with a 404.

Their advice is to audit the old URLs, check that they redirect correctly, and spot errors that need fast correction.

Google's own site move documentation reinforces the stakes.

It recommends preparing a URL mapping from current URLs to their new format, configuring server redirects from old to new, and monitoring traffic on both sets of URLs.

It also sets expectations: for medium-sized sites, it can take a few weeks or more for Google to gradually show new URLs instead of old ones, and larger sites take longer.

Errors left in place during that window waste crawl attention and send visitors to the wrong place.

The audit matters for more than search.

Paid campaigns, email templates, printed materials and bookmarked pages all hit old URLs.

A redirect that works for Googlebot but lands a prospect on a deleted product page is a revenue problem, not just an SEO one.

Step one: assemble the full list of old URLs

The most common audit failure is auditing an incomplete list.

If you only test URLs you remember, you will miss the long tail.

Screaming Frog recommends uploading URLs from a crawl taken before the migration, and combining and de-duplicating that with other sources:

• Landing page URLs from analytics
• Top pages from Google Search Console
• Backlink data from tools such as Majestic, Ahrefs or Moz Link Explorer
• URLs scraped from site: search queries
• Server log files
• XML sitemaps

Each source covers a different slice of reality.

A pre-migration crawl finds internally linked pages; Search Console surfaces pages that actually earn search traffic; backlink data shows URLs that external sites point at.

Merge them, remove duplicates, and keep the combined file as your audit baseline.

If you did not capture a pre-migration crawl, the remaining sources still give you a workable list, though it may not be exhaustive.

If your mapping work is still underway rather than complete, the guide to mapping redirects during a site migration covers how to pair old and new URLs in the first place.

Step two: crawl the old URLs through their redirects

Upload the list into a crawler such as Screaming Frog SEO Spider in list mode.

One setting matters more than any other here: enable the 'always follow redirects' option in the spider configuration.

List mode by default only checks the URLs you upload, at zero crawl depth.

With redirects followed, the crawler keeps going until each URL reaches its final destination, whether that is a successful page, an error, or no response at all.

Then start the crawl and let it run to completion.

Do not sample and stop early; a redirect that fails only for a subset of URLs, such as those with query parameters or a particular path prefix, will hide from a partial run.

Step three: read the All Redirects report

Screaming Frog's 'All Redirects' export includes every URL from the original upload, not just the ones with chains.

It records the start URL and final URL in fixed columns, then maps out every hop in variable columns.

The fixed columns worth scanning first are:

• Chain type, such as HTTP redirect, JavaScript redirect or meta refresh
• Number of redirects, meaning the hops in the chain
• Redirect loop, true or false
• Temp redirect in chain, true or false
• Final address, indexability, indexability status and final status code

This single export lets you diagnose most redirect problems at a glance.

The variable columns then show the exact status code and target of each hop, which you need when you want to shorten a chain rather than just flag it.

What to look for, and what to fix

Not every finding deserves the same urgency.

Sort your findings into these groups.

404s and errors on old URLs

An old URL that returns a 404 or 410 after a migration is the highest-priority finding, unless the content was deliberately deleted.

Google's guidance is that URLs for deleted or merged content should correctly return a 404 or 410, so some 404s are intentional.

The problem is unintentional ones: pages that should have moved but were missed in the mapping.

Cross-check each 404 against your analytics and Search Console data.

A 404 on a page that earned traffic or links is a fix; a 404 on an empty tag archive may be fine.

Redirect chains

A chain is an old URL that hops through two or more redirects before landing.

Chains usually accumulate when a new redirect layer is stacked on top of an old one.

They work, but they add latency for visitors and extra steps for crawlers.

The fix is to point the first redirect directly at the final destination, collapsing the middle hops.

Prioritise chains on high-traffic or heavily linked URLs; a two-hop chain on an obscure page is a low-value cleanup.

Redirect loops

A loop sends the visitor in a circle and never resolves.

These are outright failures: the visitor sees an error, and the page is unreachable.

Fix loops immediately, before anything else on the list.

Temporary redirects in the chain

A 302 or other temporary redirect inside a migration chain is a signal that something was set up as provisional and never updated.

Google's documentation treats 301 and other permanent redirects as the mechanism for passing signals during a move.

So a temporary hop in the path is worth converting to a permanent one, especially on URLs that matter.

Wrong destinations

The final address column tells you where each old URL actually lands.

Compare that against your intended mapping.

Redirects to the homepage are a classic migration shortcut that often mismatches intent.

A visitor looking for a discontinued product gets a generic homepage instead of the closest relevant page.

Where the exact page no longer exists, redirect to the nearest equivalent rather than defaulting everything to the root.

Non-indexable final destinations

If a redirect lands on a page that is noindex, blocked by robots.txt, or otherwise non-indexable, the redirect effectively leads nowhere for search.

Check the indexability status column for these cases and confirm whether the destination is intentionally excluded.

If it is not, fix the destination page.

A related check is whether canonical tags on the new pages agree with your redirect targets; the walkthrough on auditing canonicals on a website covers how to verify that.

Step four: verify in Search Console and monitor traffic

The crawl tells you what your server does.

Search Console tells you what Google sees.

Google's site move guidance recommends verifying both old and new sites, including all variants such as www and non-www and HTTP and HTTPS.

Use the Index Status report for a broad look and the Sitemaps report to see how many submitted URLs have been indexed.

It also notes that submitting a sitemap can help make the discovery of new URLs quicker.

Google also advises patience: Googlebot has to visit every URL on the old and new site at least once, there are no fixed crawl frequencies, and the move happens on a per-URL basis.

Expect temporary ranking fluctuation while Google recrawls and reindexes.

That means a dip in the weeks after launch is not automatically evidence of a redirect failure.

But it is a reason to keep monitoring traffic on both old and new URLs, as the guidance recommends, and to re-run the audit if specific pages lose visibility.

If performance has not settled, the article on what to do after a Google core update offers a structured assessment.

It helps determine whether a change is migration-specific or part of a broader pattern.

A worked example of reading the report

Suppose your export shows a row where the start URL is an old blog post, the number of redirects is two, and the final address is the new blog post.

The first hop goes to an intermediate URL from a previous migration years ago.

The decision: update the redirect so the old URL points straight at the new post, removing the intermediate hop.

The outcome you are looking for on a re-crawl is a single redirect with the same final address.

That is the whole loop: observe the state in the report, make one targeted change, and verify the change with another crawl of the affected URLs.

Contrast that with a row where the final status code is 404 and the URL appears in your Search Console top pages.

That is not a cleanup task; it is a missing mapping that needs a redirect created, and it should jump the queue.

How often to re-audit

Run the full audit shortly after launch, then re-run it after you have applied fixes, so you can confirm each change landed.

After the immediate migration window, redirect configurations tend to drift when new redirects are added on top of old ones.

A periodic re-check of the same URL list is a sensible safeguard.

What a re-audit reliably reveals is the current state of every URL in your list: new chains, new errors, changed destinations.

What it cannot do is cover URLs that never made it onto your list, which is why keeping the source list current matters as much as the checking itself.

Redirects are one layer of a migration.

Before launch, the checklist in auditing a staging site for SEO catches problems while they are still cheap to fix.

After launch, a site-wide check of live pages helps confirm the content itself arrived intact.

The short version

• Build the old-URL list from multiple sources, not memory
• Crawl the list with redirects followed to the final destination
• Fix loops and unintentional 404s first, then chains and temporary redirects on URLs that matter
• Check destinations against your intended mapping, not just status codes
• Verify in Search Console and monitor both old and new URLs while Google recrawls

An audit is not about achieving a perfect report with zero redirects.

It is about confirming that every old URL that matters reaches a page that serves the visitor and preserves the signals the migration was meant to protect.

Source references: www.screamingfrog.co.uk; developers.google.com.

How Meshline can help. Connect automation, Organic Marketing (demand generation), and customer lifecycle management (Revenue Intelligence).

Bring topic planning, content publishing and performance feedback into the conversation about your workflow. Book a Meshline demo.