Redirect Fixes: One Clean Hop From Every Old URL

A redirect tells a browser or crawler that the page it asked for lives at another address. Done well, a visitor never notices. Done badly, one old link bounces through several addresses, loops forever, or lands on a temporary redirect that was meant to be permanent.

The Redirect Checker follows each URL through its whole chain, recording every status code, every Location header and the time each hop takes. It flags chains of more than two hops, loops, 302s that should be 301s, gaps in the HTTPS upgrade and mixed content. This page explains each finding and where to fix it.

By John Carlsson · Updated 28 September 2026 · About 10 minutes to read

📋 Demo 📘 Tutorial 📖 Guide 📚 Book 🔧 Fix

On this page

Anatomy of a redirect chain
The fix guides
Which findings to fix first
301, 302, 307 and 308 in plain English
Decide which layer owns redirects
Order of work
Questions and answers

Anatomy of a redirect chain

Here is a chain the checker commonly finds on sites that have moved to HTTPS and changed their preferred host over the years:

http://example.co.uk/services
  301 -> https://example.co.uk/services
  301 -> https://www.example.co.uk/services
  301 -> https://www.example.co.uk/services/
  200

Each rule was sensible when it was added: force HTTPS, then add www, then enforce a trailing slash. Stacked together they turn one request into four. The fix is to make the first response send the visitor straight to the final address:

http://example.co.uk/services
  301 -> https://www.example.co.uk/services/
  200

Why does it matter? Every hop is a separate round trip to the server, which adds delay before the page even starts loading, and on a mobile connection that delay is noticeable. Search engines follow chains, but Google has said Googlebot follows a limited number of hops per attempt, and long chains make it harder for signals to pass cleanly to the final URL. Chains also tend to grow: each future change adds another rule on top.

The checker reports the full chain for each URL, so you can see which layer added each hop. That matters, because the rules may live in three different places: the CDN, the web server and the CMS.

The fix guides

The guides split into two sets: one for each kind of finding, and one for each place redirect rules are usually written.

By finding

Fixing multi-hop redirect chains covers collapsing a chain into a single 301 and keeping a redirect map so it does not rebuild itself. Fixing redirect loops covers the ERR_TOO_MANY_REDIRECTS error, HTTPS forced in two places, conflicting plugins and stale cached rules. Fixing 302s that should be 301s covers when a temporary redirect is right, such as short campaigns or tests, and when a permanent one is needed.

Fixing HTTPS upgrade redirects covers forcing HTTPS in one hop at the edge and using HSTS so browsers stop requesting HTTP at all. Fixing www and non-www splits covers choosing one host, redirecting the other and updating links and sitemaps. Fixing trailing-slash inconsistency covers picking one URL style and enforcing it, with file URLs such as .html as the usual exception.

Fixing mixed content during redirects covers HTTPS pages that still request images, scripts or stylesheets over HTTP, and the upgrade-insecure-requests directive. Fixing CDN and origin redirect conflicts covers deciding which layer owns redirects and removing the duplicates from the other.

By platform

The WordPress guide covers redirect plugins, the rewrite rules WordPress writes to .htaccess, and clashes between SEO plugins that also manage redirects. The Plesk and cPanel guide covers panel-level redirects, domain aliases and which rules win when the panel and files disagree. The Apache and nginx guide covers RewriteRule and return 301 patterns and the regular expressions that cause loops. The Cloudflare guide covers the different redirect features Cloudflare offers and when each fits.

Which findings to fix first

Priority	Finding	Reason
1	Loops	The page cannot be reached at all. Visitors see a browser error and search engines give up.
2	Chains on the homepage and main entry points	These are hit by almost every visitor and by links from other sites, so the delay is multiplied.
3	HTTPS gaps	If any URL still serves content over HTTP without redirecting, visitors may see "not secure" warnings and you may have two versions indexed.
4	www or trailing-slash splits	Two working versions of every page split links and create duplicates.
5	302s on permanent moves	They send a mixed message about which URL should be indexed.
6	Mixed content	Browsers block insecure scripts and styles on HTTPS pages, which can break layout or features.
7	Chains on low-traffic URLs	Worth tidying, but only after the above.

Once your host-level rules are clean, most other chains disappear with them, because they were built on top of the same HTTPS and www rules. That is why fixing the sitewide rules first usually clears far more findings than working URL by URL.

⚠️ Test redirect changes in a private browser window or with the checker, not in your normal browser. Browsers cache 301 redirects strongly, so an old rule can appear to still be working, or a new one appear broken, when you are only seeing the cached version.

301, 302, 307 and 308 in plain English

The checker flags 302s on URLs that look like permanent moves. It helps to know what each code actually says.

301 Moved Permanently: the page has moved for good. Use it for changed URLs, merged pages, HTTPS and host changes. Search engines move their indexing to the new URL.
302 Found: the page is temporarily elsewhere. Use it for short campaigns, maintenance or tests where the original URL will return. Search engines tend to keep the original URL indexed.
307 Temporary Redirect: like a 302, but the browser must repeat the same request method, so a form submission stays a submission. Browsers also show a 307 internally when HSTS upgrades a request, which is not a server redirect at all.
308 Permanent Redirect: like a 301, but with the same method guarantee. Some frameworks use it by default for permanent redirects.

Google has said that 301 and 302 redirects both pass ranking signals, and that it may treat a long-standing 302 as permanent. So a 302 is rarely a disaster. The practical problem is ambiguity: a 302 tells search engines you might want the old URL back, and they may keep showing it in results. If the move is permanent, say so with a 301 or 308.

A common source of stray 302s is a CMS, framework or hosting panel whose redirect feature defaults to temporary. Check the setting when you create each redirect.

Decide which layer owns redirects

Most redirect problems on established sites come from rules living in several places at once. A typical small business site might have redirects in all of these:

the CDN or proxy, such as Cloudflare;
the hosting control panel, such as Plesk or cPanel;
the web server configuration or .htaccess;
the CMS or a redirect plugin;
the application or framework code.

When two of these each force HTTPS, or one adds www while another removes it, you get chains or loops. A classic loop comes from a CDN connecting to the origin over plain HTTP while the origin forces HTTPS: the origin redirects, the CDN fetches over HTTP again, and round it goes.

The fix is organisational as much as technical. Choose one layer for host-wide rules, meaning HTTPS, www and trailing slashes, and ideally put them at the edge so they apply before anything else. Choose one place for individual page redirects, often the CMS or a single configuration file, and keep a record of them. Then remove the duplicates from every other layer.

💡 Keep a simple spreadsheet of every page-level redirect: old URL, new URL, date and reason. It makes future chains easy to spot, because any new redirect whose target is already an old URL in the sheet is a chain in the making.

Order of work

Run the Redirect Checker on your homepage, main landing pages and a sample of old URLs from previous versions of the site.
Fix any loops straight away, starting by checking the CDN's SSL mode and duplicate HTTPS rules.
Pick your canonical form: HTTPS, with or without www, with or without trailing slashes.
Write one set of host-wide rules that goes directly to that form in a single hop, and remove overlapping rules elsewhere.
Update page-level redirects so every old URL points directly at its final destination, not at another redirect.
Change 302s to 301s where the move is permanent.
Update internal links, canonical tags and the XML sitemap to use final URLs only.
Fix mixed content by changing http:// resource URLs to HTTPS, then consider HSTS once everything works over HTTPS.
Run the checker again and compare the chains.

The example report shows what the checker's output looks like, the beginner tutorial walks through a first check, and the Redirect Checker Guide is the full reference.

Questions and answers

1. How many redirects in a chain is too many?

Ideally one. An old URL should redirect straight to its final destination in a single hop. Two hops are sometimes unavoidable for a short time, for example during a migration, but anything longer is worth fixing. Each hop adds a round trip before the page can load, and Google has said Googlebot will only follow a limited number of hops in one go. The checker flags chains longer than two hops so you can collapse them.

2. Does a 301 redirect lose link equity?

Google has said that 301 and other server-side redirects no longer lose PageRank simply because they are redirects. That does not mean redirects are free. A redirect to a page that is not a close match may not carry its value across, chains add delay and risk, and the old URL still has to be requested every time someone follows an old link. Redirect to the most relevant equivalent page and update your own links to point there directly.

3. When should I use a 302 instead of a 301?

Use a 302 or 307 when the move is genuinely temporary and you expect the original URL to come back: a short promotion, a page under maintenance, or a test that sends some visitors to an alternative version. Use a 301 or 308 for anything permanent, including URL changes, merged pages, domain moves and HTTPS or www changes. If you are unsure, ask whether you want search engines to show the new URL in results. If yes, it should be permanent.

4. What causes ERR_TOO_MANY_REDIRECTS?

The browser has followed so many redirects that it assumes it is stuck in a loop, which usually it is. The most common causes are HTTPS being forced at both the CDN and the origin while the CDN connects to the origin over plain HTTP, two rules that add and remove www, a plugin and a server rule fighting over the trailing slash, or a cached old rule. Check each layer in turn and remove the duplicate rule.

5. Should I choose www or non-www?

Either works equally well for search engines. What matters is picking one and sticking to it. Redirect the other version with a single 301, use the chosen form in canonical tags, internal links and the sitemap, and make sure your Search Console property covers it; a domain property includes both forms. Some people prefer www for technical reasons such as cookie scoping or CDN setup, while others prefer the shorter address. Consistency is the only real requirement.

6. Do I still need HTTP to HTTPS redirects if I use HSTS?

Yes. HSTS tells a browser to use HTTPS for your site after it has seen the header once over a secure connection, so the very first visit, and visits from browsers that have never seen the header, still need the server-side redirect. Search engine crawlers and old links will also keep requesting HTTP URLs. Keep the single-hop 301 in place and treat HSTS as an addition that removes the redirect for returning visitors.

7. How long should I keep old redirects in place?

For as long as the old URLs might still be requested. Links from other websites, bookmarks and old emails can keep sending visitors for years, and removing the redirect turns each of those into a 404. Google has suggested keeping redirects for at least a year after a move, but many sites simply keep them indefinitely because the cost is low. What you should remove is chains, by pointing old rules straight at current URLs.

Trace every hop

The Redirect Checker follows each URL through its full chain, recording every status code, Location header and hop time, and flags long chains, loops, 302s that should be 301s, HTTPS gaps and mixed content.

Run the Redirect Checker →