Redirects: How to Find and Fix Redirect Problems

You know the page you're loading is supposed to redirect somewhere else. You hit F5, try Ctrl + Shift + R, and the old page is still sitting there. You refresh again. Still there.

Now you're wondering whether the redirect is broken, whether your browser is holding on to an old response, or whether something else is happening behind the scenes.

Redirect problems are surprisingly confusing because a URL can look fine in a browser while the server returns something completely different. A redirect can work correctly, bounce through several URLs, point to the wrong page, or get stuck in a loop.

When you're auditing a website, you need to look past the browser and see what actually happens to the URL: where it goes, how many hops it takes, and whether it reaches the right destination.

What Redirects Do

A redirect tells a browser or crawler that the requested URL should lead somewhere else. When someone requests /old-page, the server responds with a 3xx status and a Location header telling the client to request /new-page instead.

Redirects are a normal part of maintaining a website. They're commonly used when:

• A page has moved
• A URL has changed
• HTTP moves to HTTPS
• A domain changes
• A product or article is replaced
• URL structure is reorganized
• Duplicate URLs consolidate to one version

Redirects aren't automatically a problem. Trouble starts when they're unnecessary, misconfigured, chained, looped, or pointing to the wrong destination.

301 vs 302

The two redirects you'll see most often don't mean the same thing. The difference is intent.

/old-services → 301 → /services

/sale → 302 → /summer-sale

A 302 isn't automatically wrong. But a URL that's been permanently replaced and still sits behind a 302 months later is worth investigating.

307 vs 308

307 and 308 work like 302 and 301, with one key difference: they guarantee the HTTP method is preserved.

Method preservation matters for requests like POST, where switching to GET could change how the request is handled. In ordinary SEO audits you'll mostly see 301 and 302, but you should still understand 307 and 308 when they appear in a crawl.

Why is this URL redirecting, and is the redirect doing what it's supposed to do?

Redirect Chains

A redirect chain happens when one redirect leads to another before reaching the final page. You eventually arrive, so the site may seem to work normally, but there was no reason for the long route.

Why chains happen

They're usually leftovers from past site changes stacked on top of each other:

1. 1First changeSomeone redirects /page-a → /page-b.
2. 2Later changeSomeone else redirects /page-b → /page-c.
3. 3Another migrationA new rule adds /page-c → /page-d.
4. 4Nobody updates the originalNow you have a chain. Googlebot follows up to 10 hops before giving up, and every hop adds latency for users.

How to fix a chain

Redirect Loops

A redirect loop is worse: the URL never reaches a final destination. /page-a sends you to /page-b, which sends you back to /page-a, until the browser gives up with a "too many redirects" error (ERR_TOO_MANY_REDIRECTS in Chrome).

A classic case: one system redirects HTTP to HTTPS while another rule sends HTTPS back to HTTP. That often happens when a CDN like Cloudflare connects to the origin over HTTP in "Flexible" SSL mode while the server also forces HTTPS. Common causes:

• Conflicting redirect rules
• HTTP and HTTPS configuration
• CDN settings
• Reverse proxy configuration
• CMS plugins
• Server configuration
• Domain redirects
• Multiple systems enforcing HTTPS

Internal Links Pointing to Redirects

This one hides inside otherwise healthy websites. An internal page links to /old-page, which 301 redirects to /new-page. The link works, but it adds an unnecessary hop.

Your internal links are fully under your control, so there's little reason to make crawlers, browsers, or visitors take an extra step when you already know the final URL. During a crawl, look for this pattern:

Then update the source page to link directly to the final URL where appropriate.

HTTP → HTTPS

One of the most common redirects you'll see is http://example.com → 301 → https://example.com. After an HTTPS migration, that's expected. But don't stop once you've confirmed the redirect exists. Check the rest of the site for leftovers like this:

If the site already uses HTTPS, internal links pointing to HTTP should be updated. The same applies to canonical URLs and XML sitemaps: use the preferred HTTPS URLs consistently instead of routing crawlers through HTTP redirects. Adding an HSTS header also tells browsers to go straight to HTTPS on future visits.

Redirecting Deleted Pages

Deleting a page doesn't automatically mean you should redirect it. First, ask what happened to the content.

If /blue-running-shoes was replaced by /running-shoes, a 301 makes sense. If there's no replacement, don't automatically send it to the homepage. The homepage loads, but it has nothing to do with what the visitor requested, and Google often treats that kind of redirect as a soft 404 anyway.

Redirect Destinations Matter

Finding a redirect isn't enough. You also need to check where it ends. /old-page → 301 → /new-page looks fine, until you check the destination:

When auditing a redirect, check:

• The final URL
• The final HTTP status
• Whether another redirect occurs
• Whether the destination is accessible
• Whether it's relevant
• Whether it's blocked
• Whether it's an appropriate replacement

Irrelevant Redirects

This problem slips past anyone checking status codes alone. An old article at /technical-seo-audit redirects to /. The homepage returns 200, so technically everything works. But is the homepage really the right replacement? Not necessarily. Look for redirects where:

• An old article redirects to an unrelated article
• An old product goes to a completely different product
• Many unrelated URLs all go to the homepage
• A deleted service goes to a generic page
• An old category goes to an unrelated category

The goal isn't to eliminate every redirect. It's to make sure each one makes sense.

Redirects and Crawling

Redirects also shape how crawlers move through a site. In a chain like /page-a → /page-b → /page-c → /page-d, the crawler requests every step before reaching the final page. Multiply that across hundreds or thousands of URLs and you've got a lot of wasted crawl activity, which is why redirect auditing matters most on large sites.

Pay particular attention to:

• Redirect chains
• Redirect loops
• Many internal links to redirects
• Redirects ending at error pages
• Redirects ending at blocked URLs
• Redirects to irrelevant destinations
• Old redirects left after multiple migrations

How to Audit Redirects

You don't need to open every URL in a browser. A crawler gives you a much clearer picture of what's happening across the site. If you want the background on response codes first, see our guide to HTTP status codes.

1. Crawl the website

Run a crawl that records HTTP responses and redirect data, so you can follow every path end to end. You want to capture:

• 301 URLs
• 302 URLs
• 307 URLs
• 308 URLs
• Redirect destinations
• Final URLs
• Redirect chains
• Redirect loops

2. Filter the redirect URLs

Filter for redirect status codes, then review each by what it's doing:

3. Follow the redirect path

Don't stop at the first response. If /page-a → 301 → /page-b, check /page-b. If it redirects again, you've found a chain. Keep going until you reach the final response. For every redirect, the audit should answer four questions:

4. Check internal links

Find pages linking to redirecting URLs. If /page-1 links to /old-page, which redirects to /new-page, update /page-1 to link straight to /new-page. The same check catches broken internal links at the same time.

5. Check HTTP and HTTPS

Confirm HTTP redirects to HTTPS as expected, then look for internal links, canonicals, and sitemap entries still using HTTP after the move.

6. Review deleted URLs

For each old URL, decide the right outcome:

1. Does a replacement exist?
2. Is a redirect appropriate?
3. Is the redirect destination relevant?
4. Should the URL return 404 instead?
5. Should the URL return 410 instead?

Give extra weight to old URLs that still have backlinks. A backlinked URL that redirects should land somewhere relevant so its link equity isn't wasted.

7. Inspect the final destination

Always check where the redirect ends. Finishing at a 200 doesn't make it correct if the destination is unrelated to the original URL.

How to Verify Redirect Fixes

After fixing redirects, test them again. Changing a rule doesn't mean the problem is solved. Here's what each fix should look like afterward:

Check the server response

For one or two URLs, you don't need a full crawler. curl shows exactly what the server returns, with no browser cache in the way.

curl -I https://example.com/old-page

curl -IL https://example.com/old-page

That's ideal for a specific URL or a handful of pages, and you can make redirect testing part of every deployment. But running commands manually for hundreds or thousands of URLs isn't practical.

Redirect Audit Checklist

Before you close the audit, confirm every item:

• 301 redirects are used for permanent URL changes
• 302 redirects are actually temporary
• 307 and 308 redirects have an intentional purpose
• No redirect loops exist
• Redirect chains are minimized
• Internal links don't unnecessarily point to redirects
• HTTP redirects correctly to HTTPS
• Internal links use the preferred HTTPS URLs
• Deleted pages have an appropriate destination or response
• Redirect destinations are relevant
• Redirect destinations don't return errors
• Redirect destinations aren't unnecessarily blocked
• Final URLs return the expected status
• Redirect fixes have been tested again

Don't Just Check the Redirect. Follow It.

A redirect can look fine when you only check the first response. A 301 comes back, the browser eventually loads a page. Done, right?

Not necessarily. The redirect could lead to another redirect. It could end at a 404. It could send visitors somewhere unrelated. An internal link could still route people through an old URL. Or two rules could be fighting each other and creating a loop.

Checking redirects across an entire site is tedious. It's easy to check a few URLs, get pulled into other audit issues, and forget to come back to the rest. That's where a site-wide crawl helps.

Instead of remembering which URLs you checked, SiteAuditLint crawls the website, identifies redirecting URLs, follows where they lead, and surfaces the pages that need attention. You work through redirect issues from the crawl rather than from memory, and after your fixes, compare audits to confirm the redirects are actually resolved.