SEO Redirect Audit: Find Chains, Loops and Wrong Targets

An SEO redirect audit checks whether old or alternative URLs reach the correct destination through an intentional, working path. Record the first response, every intermediate hop and the final page, then review relevance and indexing signals. A redirect that eventually returns a page is not automatically a good result: it can still send customers to the wrong product or create conflicting instructions.

When should you run an SEO redirect audit?

Run an audit before and after a domain change, platform migration, URL restructuring or large content consolidation. It is also useful when visitors report redirect errors, old links stop working, or a previous migration left rules that nobody owns.

Start with a specific question. Are valuable legacy URLs being lost? Does a new hostname rule create loops? Are internal links repeatedly sending visitors through retired paths? Defining the problem helps you distinguish an expected redirect from an implementation defect.

A Pakistan-based store moving its catalogue to a new platform faces the same underlying task as an international publisher changing article paths: preserve meaningful journeys and explain where each old page belongs.

Build the URL inventory for your SEO redirect audit

Combine several inputs instead of relying only on a crawl of the new site. Include the old sitemap, a pre-migration crawl if available, current internal links, landing pages from analytics, Search Console page exports and important externally linked URLs. Each source reveals paths that another source may miss.

Create one review row per source URL. A useful worksheet contains:

• The source URL and where it was discovered.
• The intended destination and the reason for that mapping.
• The observed first status, intermediate URLs and final status.
• The final page title and a relevance decision.
• Priority, implementation owner and retest result.

Use the redirect map generator to organise proposed source-to-destination mappings. A generated map is a planning aid; review the commercial and content relationship before implementing its rows. Keep the original source list so a later crawl cannot silently erase evidence of missing pages.

Inspect the first response and every hop

Use a crawler or HTTP inspection tool that exposes the full redirect history. A result showing only the final status can hide several intermediate failures or unnecessary steps. For a browser check, preserve the network log, open the old URL directly and inspect the document requests.

Record exactly what happened. A chain is a sequence through intermediate destinations. A loop returns to an earlier point and never reaches a useful final page. A wrong-target redirect can be technically successful while being commercially unhelpful.

For example, /old-lamp might reach /lighting, then /collections/lighting, then a product page. Before shortening that chain, confirm which destination is actually intended. Otherwise, an efficient new rule can make an incorrect mapping harder to notice.

Keep a separate queue for broken links discovered on live pages. The broken link checker can help identify those links; enable its internal-link option when checking your own paths. Use the redirect worksheet to record the intended handling of legacy URLs.

Match the redirect type to the intended change

Google's redirect documentation distinguishes permanent moves from temporary changes. For a permanent URL move, Google recommends a server-side permanent redirect where possible; HTTP 301 and 308 are permanent types. Temporary redirects include 302 and 307 and communicate a different intention.

Do not convert every temporary redirect simply because a tool highlights it. Ask why it exists and whether the original URL is expected to return. An audit should identify accidental status choices, not remove legitimate temporary behaviour.

Keep navigation redirects separate from application workflows. A login process, form submission or payment return may have requirements that a general SEO rule should not override. Ask the application owner before changing routes involved in those operations.

Review destination relevance before simplifying chains

The final page should satisfy the reason someone followed the old URL. Compare the offer, topic, product identity and language. A shared keyword in two page titles is not enough to justify the mapping.

Google's site migration guidance warns against sending many unrelated old URLs to the homepage, which can be treated as soft 404s. It also recommends redirecting directly to the final destination and returning 404 or 410 for removed content where appropriate. Do not manufacture a homepage mapping just to make an error count smaller.

Test URL families and rule boundaries

A broad rule can appear correct for one sample and fail for an entire catalogue. Test the patterns it matches, including URLs that should remain untouched. Check old hostnames, HTTP and HTTPS entry points, trailing slashes, capitalisation where relevant, and paths with query parameters.

Use a small test matrix for each rule family. Include a valid old product, a nested category, a similarly named page outside the intended section and an unknown path. Record the expected result before running the test so the actual output does not redefine success.

Preserve parameters that the application genuinely needs. Review campaign and checkout parameters with the appropriate owner instead of dropping every query string by default. Also check whether a hosting rule, CMS setting and redirect plugin are all trying to normalise the same URL. Conflicting layers can explain a loop that is invisible in a single configuration screen.

Align internal links, canonicals and the sitemap

A working redirect should not become a permanent excuse to keep obsolete internal links. Update navigation, content links and relevant campaign destinations to the preferred current URL. Inspect the destination page's canonical and sitemap entry alongside the server response.

Google's canonicalisation guidance advises against specifying different preferred URLs through different methods. It also recommends linking internally to the canonical URL. Use the canonical URL checker as one input when reviewing the final page.

If the old URL redirects to one page while that page points its canonical elsewhere, investigate the intended content relationship. Record one agreed preferred destination rather than treating each configuration field as an independent task.

Deploy fixes with a regression checklist

Prioritise loops, inaccessible destinations and wrong mappings affecting important journeys. Then address unnecessary chains and stale internal links. Save the current rules before changing them, group fixes into understandable batches and record the deployment time.

1. Retest the old URL. Confirm the first response and complete path.
2. Open the final page. Check its content, usability and intended status.
3. Test neighbouring paths. Include URLs that the new rule must not affect.
4. Review related signals. Confirm the preferred canonical and internal links.
5. Check real actions. Test relevant forms, product selection or checkout navigation.

Compare the new crawl with the saved baseline, not only with a dashboard score. A useful completion note identifies which URL families were fixed, what remains unresolved and who will investigate those exceptions.

Keep the mapping and monitor the move

Google recommends retaining migration redirects for as long as possible, generally at least one year. Keep a documented owner for old domains and rules so renewals or a plugin cleanup do not remove them accidentally. Review important entry URLs after subsequent site releases.

Monitor destination accessibility, search performance and customer journeys after implementation. A passing HTTP test confirms the observed route, not a guaranteed ranking outcome. Use actual evidence to distinguish a redirect defect from changes to content, demand or the offer. For help connecting migration checks with wider technical improvements, see full stack marketing services.