Redirect Audit for Migrated Sites: Do It Right!

A redirect audit checks that every old URL reaches the right new URL and that each redirect works properly. It helps protect search traffic, rankings, and the routes users depend on after a migration.

A website migration may involve a new platform, domain, URL structure, or protocol. The reason changes; the risk does not. A poor redirect plan can turn useful pages into 404 errors, send visitors somewhere unrelated, and reduce organic traffic and revenue.

Our take: redirect work is migration work. It is not cleanup for later. This guide explains how to audit redirects on a migrated site, including the data to collect, the tools to use, the checks to run, and the fixes worth doing first. The aim is straightforward: connect old URLs with relevant new pages before small gaps multiply.

What is a redirect audit for migrated sites?

A redirect audit reviews the redirects added after a site migration. It checks whether old URLs reach the right new pages, whether the server returns suitable status codes, and whether users and search engines can still find the content they need.

Defining the purpose and scope of a post-migration redirect audit

The audit tests whether the migration’s redirect plan works. A domain change, platform move, site restructuring, or switch from HTTP to HTTPS usually changes URLs. If old addresses have no redirect, search engines may see 404 errors and remove those pages from their index. Visitors may hit dead ends too.

In our last 2 audits, the redirect map looked complete until we compared it with server logs. That comparison exposed valuable URLs nobody had documented.

The audit should cover every old URL that still has value or needs a clear destination. That usually includes:

• Individual page redirects: Check that an old page such as /old-product-page.html leads to its replacement, such as /new-product-category/product-sku/.
• Directory and category redirects: Test moves such as /old-blog/ to /insights/blog/, including the pages inside those sections.
• Canonical tags: Confirm that new pages identify the preferred URL when several versions or parameters show the same content.
• Internal and external links: Find internal links that still use old URLs. Also record important backlinks whose owners might be able to update them.
• Redirect chains and loops: Find routes such as A to B to C, as well as loops such as A to B to A. Both add delay. Loops prevent the page from loading.
• Status codes: Use 301 for permanent moves in most cases. A 302 or 307 tells search engines that the move may be temporary, which can delay the transfer of signals to the new URL.

Why does this matter? Because a redirect can technically work while still sending people to the wrong place.

The audit should leave users and crawlers with a short, direct route to the right page. It should also show which old URLs can be retired and which still need work. Most guides say “redirect everything.” That is only half right; relevance matters as much as coverage.

How a redirect audit differs from a general SEO audit

A redirect audit sits inside a broader SEO audit, but the two jobs are different. A general SEO audit looks across the site at content and keywords. It also examines crawlability, indexation, speed, backlinks, and user experience. Teams may run one every few months or after a major change.

A post-migration redirect audit has a narrower purpose. It checks whether the URL changes were handled correctly. It does not decide whether a page needs better copy or a new keyword target. It asks whether the old page reaches the right new page, whether the redirect returns 301, and whether the destination still contains a suitable version of the content.

For example, a general SEO audit might find that a page gets little traffic because its content is weak. A redirect audit checks whether that page’s old address reaches the new one at all. The first audit looks for opportunities. The second looks for damage after a move.

Yes, that distinction affects the tools. Redirect work depends heavily on crawlers, server logs, redirect rules, and HTTP responses. The broader audit needs a wider diagnostic set.

Why is a redirect audit important for site migrations?

A migration can lose traffic quickly when old URLs return errors or point to unrelated pages. A redirect audit finds those failures while the team can still fix them. It protects search visibility, keeps visitors moving, and limits the revenue loss from broken entry points.

The direct impact of broken redirects on SEO and user experience

When someone opens an old URL and receives a 404, the visit often ends there. This is especially frustrating for returning customers who use bookmarks or saved emails. They expected a product or article and find a dead end instead. Some will try again. Many will leave.

Search engines face a similar problem. If many indexed pages begin returning 404 responses, crawlers may remove them from search results. The old URLs may have collected backlinks and ranking signals for years. A missing redirect gives the new site no clear way to inherit them.

Broken internal links create another problem. They waste crawl requests and make the site harder to use. Long chains slow down visitors and crawlers. Irrelevant redirects can make search engines question whether the destination really replaces the old page.

One bad redirect may be minor. Thousands can affect the whole site. It works. Until it doesn’t.

Estimating the possible losses in traffic, rankings, and revenue

The numbers can become unpleasant quickly. Imagine an online store moving 10,000 product pages. If 10% fail to redirect, 1,000 pages disappear from their old search paths. If each page previously attracted 50 organic visits per day, the site loses about 50,000 visits each day.

At a 2% conversion rate and a $100 average order value, those visits represented roughly $100,000 in daily revenue. The calculation is only an example, but it shows why the audit deserves attention before launch. Actual losses depend on traffic, conversion rates, seasonality, and the value of the affected pages.

Rankings can fall just as sharply. A page in position three may vanish from the first ten pages when its URL breaks. Recovering that position may take months, even after the team repairs the redirect, because Google must recrawl and reassess the page. During that time, competitors get the clicks.

Informational sites face the same issue at a different scale. Each article may attract only a few dozen visits, but thousands of articles can account for a large share of total traffic. A redirect audit gives the team a practical way to protect those gains before they disappear.

Is this overkill? For a 10,000-page store, no. It is basic revenue protection.

When should you conduct a redirect audit during a site migration?

Run the audit before launch, during the launch window, and after the new site goes live. Each phase catches different problems. The work is not finished when the first crawl looks clean.

Pre-migration, migration, and post-migration audit phases

During the pre-migration phase, crawl the old site and collect its indexable URLs, canonicals, pagination URLs, internal links, and XML sitemap entries. For a 100,000-page site, also export URL data from Google Search Console, Screaming Frog, Sitebulb, or the site’s own database.

Map each valuable old URL to its intended destination on the new site. Include consolidated pages, removed pages, changed folders, and protocol changes. Review redirects that already exist. If an old URL currently points to another old URL, send it directly to the final new destination instead of carrying the extra hop into the new setup.

During the migration phase, watch the site as DNS changes and the new version becomes public. Server logs and monitoring scripts can show 404, 5xx, and unexpected redirect responses within minutes. If 5% of important pages return 404 during the first day, stop and fix the cause before more users and crawlers encounter it.

It looked fine. Bot responses exposed the failure within minutes.

Check Google Search Console as well. Crawl and indexation reports may reveal issues that a basic URL test misses, especially when the site works in a browser but serves different responses to bots.

During the post-migration phase, recrawl the full old URL list within the first week. Confirm the final destination and status code for every entry. Run weekly or twice-monthly checks during the first month, with extra attention on pages with high traffic or strong rankings. Continue monthly checks for another three to six months.

Compare traffic and rankings by section. If a category that ranked for 20 keywords suddenly falls out of the top ten, inspect its redirect path, canonical tag, internal links, and destination content.

Why redirect audits need repeated checks

Sites keep changing after a migration. Editors remove pages. Developers change templates. Marketers reuse old URLs in campaigns. A clean launch report cannot catch problems introduced six weeks later.

Set alerts for new 404s, 5xx errors, and redirect chains. Crawl the live site at least monthly, and recrawl important old URLs after major releases. Server logs can reveal requests that never appear in internal link reports, including traffic from old emails, bookmarks, and external sites.

Watch for new chains too. A page may start with a direct 301, then acquire another redirect when its destination changes. The route still works, but it now takes several requests. Replace it with a direct redirect to the current page.

How do you prepare for a comprehensive redirect audit?

Start with complete URL lists, then add traffic, ranking, conversion, and backlink data. The result should be one working file showing the old URL, its proposed destination, its value, and the response seen on the live site.

Collecting old URLs, new URLs, and analytics data

Crawl the old site with Screaming Frog SEO Spider, Sitebulb, or a similar tool. Export URLs, status codes, internal links, canonicals, and sitemap entries. Check the Google Search Console Pages report and Bing Webmaster Tools as well. They may contain URLs that are indexed but no longer linked internally.

Put the results in a master CSV or spreadsheet. Then collect the new URL list by crawling the live site, the staging environment, or a file supplied by the development team. Compare the developer’s redirect map with the crawl data instead of assuming it is complete. Look for missing pages, duplicate destinations, and patterns that can use a regex rule.

Keep one-off redirects for important pages that do not fit a pattern. That small exception list often prevents the most embarrassing misses.

Use the previous 12 to 24 months of analytics data to rank URLs by value. Include organic sessions, conversions, revenue, search rankings, and meaningful backlinks. If the top 100 landing pages generate 80% of organic traffic, test those first and test them carefully. Google Search Console can connect important queries with the pages that used to receive them.

Choosing tools for data collection and analysis

For most sites, Screaming Frog and Sitebulb can collect the needed URLs, responses, canonicals, and redirect paths. Sites with millions of URLs may need cloud crawlers such as DeepCrawl or Botify because local crawls can become slow and hard to manage.

Excel and Google Sheets work well for joining URL lists and filtering traffic data. They can also check mappings with VLOOKUP or INDEX/MATCH. Python and Pandas become useful when the list reaches hundreds of thousands or millions of rows, especially when the team needs to match URL patterns or generate server rules.

For quick manual tests, Redirect Path by Ayima can show the response sequence in a browser. For bulk tests, configure Screaming Frog to crawl the old URL list and report every hop, the final URL, and the final status code. Google Search Console and Google Analytics can then track errors, traffic changes, and indexation after launch.

What are the main steps in a redirect audit?

The process is simple: crawl both sites, build the mapping, test every old URL, fix the highest-impact failures, and crawl again after implementation. Start with pages that bring traffic, rankings, conversions, or important backlinks.

A step-by-step process from the first crawl to final verification

First, crawl the old site. Record every discoverable URL, its response code, existing redirects, canonical tag, and source links. Crawl the new site separately and record its live URLs and canonical versions. These datasets give you something concrete to compare.

Next, map old URLs to new destinations. Use URL patterns and content similarity where they make sense, but review valuable pages by hand. Server logs can help when the old documentation is incomplete. For example, olddomain.com/category/product-a.html may now correspond to newdomain.com/products/product-a/. Record that relationship explicitly.

Then test the redirects before and after deployment. Send the old URLs through a crawler or redirect checker and record each response. A permanent move should normally return 301 and reach the relevant new page directly. Flag chains, loops, 404s, 5xx errors, and redirects that land on the homepage without a clear reason.

After the rules go live, crawl the old list again against the production server. If 10,000 URLs should return 301 and only 9,500 do, the missing 500 need an explanation and a fix. Do not call the audit complete until the live response matches the plan.

We count the final responses twice. It sounds fussy. It catches deployment mistakes.

Prioritizing redirect issues by their effect on SEO and users

Fix broken redirects, loops, and long chains first. A 404 on a high-traffic product page can cost more than hundreds of errors on pages that never received visits. A loop prevents everyone from reaching the content. A long chain adds delay and can stop crawlers before they reach the final page.

Next, correct the redirect type. A permanent move using 302 instead of 301 may leave search engines uncertain about which URL to keep. Also fix redirects to unrelated destinations. Sending an old product page to the homepage may avoid a 404, but it does not give visitors what they wanted.

Counter to the usual advice, not every redirect deserves immediate engineering time. Lower-priority work includes casing differences such as /Product-A/ versus /product-a/, and redirects for pages with no traffic or indexation history. These deserve cleanup, but they can wait while the team handles revenue pages and strong backlinks.

How do you identify and categorize redirect issues?

Use crawls and server logs to find errors, then label each issue by impact and next action. This keeps a large migration from becoming an undifferentiated spreadsheet of problems.

Common redirect errors: 404s, chains, and loops

A 404 Not Found error means the requested URL has no usable page and no redirect. If olddomain.com/product-a moved to newdomain.com/category/product-a but the rule was missed, visitors and crawlers will receive a 404 at the old address.

A redirect chain has two or more steps before the final page. For example:

olddomain.com/page-1 (301) → newdomain.com/page-1-old (301) → newdomain.com/page-1-new (200 OK)

The browser may complete this route, but every extra request adds time. Long chains can also waste crawl requests. Crawlers such as Screaming Frog and Ahrefs Site Audit can report chains above a chosen length. Fix them by pointing the first URL directly to the final destination.

A redirect loop sends the request back to a URL it already visited. For example:

newdomain.com/page-a (301) → newdomain.com/page-b (301) → newdomain.com/page-a

The browser usually displays “Too many redirects.” These loops often come from conflicting server rules, CMS settings, or .htaccess directives. Logs help because they show the same URLs repeating without a successful response.

Classifying issues by severity and action

Classify each issue by severity and required action. A practical scale looks like this:

Severity levels:

• Critical: Widespread 404s on important pages, redirect loops, or chains longer than 10 hops. Fix these immediately.
• High: 404s on moderately important pages, five-to-nine-hop chains, or 302s used for permanent moves. Address them within a few days.
• Medium: Three-to-four-hop chains and errors on pages with little traffic. Schedule the work within a week or two.
• Low: Internal links that point to URLs which still redirect correctly, or issues on pages with no traffic or indexation history. Batch them into routine maintenance.

Required actions:

• Immediate fix: Change a faulty server rule, database entry, or redirect mapping.
• Monitoring: Watch an intermittent error before deciding whether a larger fix is needed.
• Documentation: Record an understood limitation that cannot reasonably be removed.
• Internal link update: Change links that still point to old URLs, even when the redirects work.

For example, a 404 on one of the site’s top ten landing pages is “Critical, Immediate fix.” A three-hop route on a low-traffic blog post may be “Medium, Internal link update.” Add traffic, rankings, conversions, and backlink data to the issue record so the priority reflects actual risk.

What are the best practices for implementing and managing redirects?

Use 301 redirects for permanent moves, keep rules easy to review, and monitor them after launch. Large sites also need pattern-based rules, testing, and version control so one small change does not create thousands of failures.

Using 301 redirects for permanent moves

A 301 tells search engines that the old URL has moved permanently. It is the usual choice for migrated content and gives the new URL the best chance of inheriting the old page’s signals. Do not use 302 or 307 for a permanent move simply because the temporary rule is quicker to add.

For example, if /old-category/widgets moves to /new-category/gadgets, configure a direct 301 between them. A 302 may leave the old URL in the index and delay the transfer of ranking signals. It can also create confusion when the new page contains the permanent version of the content.

Set redirects at the server, CDN, or CMS level. Apache may use .htaccess, Nginx may use nginx.conf, and some platforms include a redirect manager. Test the rule outside the application when possible so you know the server returns the intended response before the page loads.

Managing large volumes of redirects

Thousands of manual rules are difficult to review and easy to break. Large migrations usually need automation alongside carefully reviewed exceptions.

1. Automated generation: Generate rules from a verified old-to-new mapping. A script can turn URLs such as /product.php?id=123 into destinations such as /products/item-name-123.
2. Wildcard and regex rules: Use patterns when an entire directory moves. A rule like RedirectMatch 301 ^/old-blog/(.*)$ https://www.example.com/new-blog/$1 can handle many pages, but test exceptions before deploying it.
3. Central management: A CMS module or redirect tool can provide editing, testing, and logs in one place. This suits teams that do not want every small change to pass through server configuration.
4. Database-backed rules: Very large sites may store redirects in a database, especially when the list changes often. Measure the lookup cost before choosing this approach.
5. Rule order and chain prevention: Put specific rules before broad ones. Check that A goes directly to C instead of A to B to C. A direct route is easier for users and crawlers.
6. Version control: Keep the redirect map in version control. It gives the team a history, makes review possible, and provides a safer rollback path.

Review the rules whenever the URL structure changes. A redirect file is part of the site’s infrastructure, not a document to create once and forget.

How do you measure the success of a redirect audit?

Compare traffic, rankings, indexation, and crawl errors before and after the migration. The audit worked when important pages retain their search visibility, new URLs get indexed, and unresolved errors remain rare.

KPIs to track after the audit

Organic traffic is the first measure. A reasonable target is to recover 90% to 95% of pre-migration organic sessions within four to eight weeks, although seasonality and other changes can affect the result. If the site averaged 100,000 organic sessions each week before launch, a healthy recovery would bring it back above roughly 90,000 to 95,000 within two months.

Look at individual sections as well as the total. A stable sitewide number can hide a serious loss in one product category. Compare the old landing pages with their new counterparts and investigate any large gap.

Track the top 100 to 200 non-branded keywords by search volume. A drop of five or more positions across at least 20% of those terms deserves investigation. If “best CRM software” falls from position three to position 15, check the redirect, canonical, content, internal links, and backlinks before blaming the algorithm.

Technical measures matter too. Watch 404 and 5xx counts in Google Search Console, the indexation rate of new URLs, and the number of old pages marked as redirected. New 404s should be limited. Server errors should be rare. New URLs should gradually replace old ones in the index.

Using analytics and Search Console data to monitor redirects

In GA4, compare organic sessions for important old landing pages with sessions for their new destinations. If an old product page drew 5,000 organic sessions per month and the replacement receives very little traffic, inspect the redirect path, canonical tag, internal links, and content.

In Google Search Console, review the Pages report and the “Page with redirect” status. Seeing old URLs there is normal. The important question is whether the corresponding new URLs are indexed. Check the “Not found (404)” section for migration URLs that should have redirected.

The Performance report shows clicks, impressions, average position, and click-through rate for the new pages. A lower CTR with a stable ranking may point to a weak title or description rather than a redirect problem. The Crawl stats report can show whether Googlebot spends too much time on redirects, errors, or slow responses.

What are the long-term effects of a flawed redirect strategy?

A bad redirect plan can keep causing trouble long after launch. Rankings may remain weak, new pages may take longer to enter the index, and visitors may stop trusting a site that repeatedly sends them to errors or irrelevant pages.

Effects on domain authority, crawl budget, and brand reputation

Broken links and irrelevant redirects weaken the signals that connect old backlinks with new content. Consider a migration of 10,000 pages in which 5% of the rules fail. Five hundred pages may lose the value built through their links and rankings. The effect may not appear in one dramatic report, but the site can become harder to rank over the following months.

Redirect failures also consume crawl resources. Crawlers spend time following chains and retrying missing pages. They deal with server errors instead of finding new or updated content. If a large store has millions of product URLs, that wasted time can leave sections of the catalogue slow to update in search results.

Visitors notice the problem too. A slow chain or an irrelevant destination makes the company look careless. A 404 on a page someone saved in an email can be enough to end a purchase. According to Akamai, a two-second delay can increase bounce rates by 103%, though the exact effect varies by site and audience. Whatever the precise number, delay and confusion rarely help conversion or trust.

Honestly, the brand damage is often harder to measure than the SEO loss. A customer who hits one broken link may simply never return.

Why ongoing monitoring and maintenance matter

The first audit is only the first check. Pages are deleted. Products are renamed. Campaigns reuse old links. Templates change. Any of those events can create a new redirect problem.

Keep monitoring in Google Search Console, server logs, and a scheduled crawler. Alert the team when new 404s, chains, or redirect errors appear. Add redirect review to the content workflow: when a page is removed, its URL is changed, or two pages are combined, someone should decide what happens to the old address before the change goes live.

This keeps small errors from becoming a large backlog. A redirect map needs maintenance just like the rest of the site.

Frequently asked questions

Why is a redirect audit critical for a migrated site, and what’s the biggest risk if we skip it?

It confirms that old URLs reach the right new pages and return suitable status codes. If you skip it, important URLs may return 404s, lose search visibility, or send visitors to the wrong content. The result can include lower traffic, fewer conversions, and lost trust.

How often should we perform a redirect audit after a site migration, and what triggers a re-audit?

Run a full check immediately after launch, then check weekly during the first month. Continue with quarterly audits after that. Recheck sooner after a domain change, URL restructure, CMS migration, large content cleanup, or template update.

What’s the most efficient way to identify all existing redirects on our old site before migration, especially if documentation is poor?

Crawl the old site with Screaming Frog or Sitebulb, then inspect server logs for 301 and 302 responses. Compare those results with the CMS redirect settings and any .htaccess or Nginx rules. Using all three sources usually reveals redirects that the documentation missed.

Beyond 301s, what other types of redirects should we look for during an audit, and why do they matter?

Check 302 and 307 redirects, meta refreshes, and JavaScript redirects. Temporary redirects may not pass signals as reliably for a permanent move. Meta refreshes and JavaScript redirects can add delay or behave differently for crawlers. Replace them with direct server redirects when appropriate.

What metrics should we track to measure the success of our redirect strategy after migration?

Track organic traffic, rankings, clicks, indexation, 404s, and server errors. Traffic should move from old URLs to new ones, while 404s remain low and important rankings stay reasonably stable. A sharp drop in any of those measures is a reason to inspect the affected redirect paths.