Redirect chains: find and remove unnecessary hops

Your site goes through two or three redirects before loading? Find the chain, avoid loops and redirect straight to the final page.

What is a redirect chain?

A chain happens when the address you visit redirects to a second, then a third address before reaching the final page.

Example to improve:

http://www.example.com/product → https://www.example.com/product → https://example.com/product → https://example.com/products/

Goal:

http://www.example.com/product → https://example.com/products/

Each extra hop adds delay. Google recommends pointing old addresses straight to the final destination and avoiding unnecessary chains, especially during a migration.

Step 1 — Review the existing redirects

In Redirect Audit, check the domain and look at the card for the variant in question. Note the starting address, each 301, 302, 307 or 308 code, the Location header and the final destination.

A 301 or 308 usually suits a permanent move. A 302 or 307 means a temporary move. They are not interchangeable without considering the application context and HTTP methods.

Step 2 — Find the rule behind each hop

Common causes:

• HTTP to HTTPS done by a first layer;
• www to non-www done by the application;
• the old path rewritten by a third rule;
• a domain change or a redirect added by WordPress;
• conflicting rules between the CDN and the origin server.

Do not delete rules at random: first find which layer creates each hop.

Step 3 — Point the old address straight to the target

For a specific old page on Cloudflare, use Rules → Redirect Rules with the exact source path or a suitable pattern, a permanent target and a 301 code. For many old pages, use Bulk Redirects with a mapping table instead.

With Apache, a simple path redirect looks like this:

Redirect 301 /old-product https://example.com/new-product

Watch out: Apache’s Redirect directive also matches sub-paths (/old-product/photos, for example). To target only the exact address, use a dedicated rule and test the sub-paths. Also make sure the destination does not redirect again.

With Nginx, a targeted route can use:

location = /old-product {
    return 301 https://example.com/new-product$is_args$args;
}

$is_args$args keeps the query parameters (for example ?ref=newsletter): without it, Nginx drops them. Apache keeps them automatically with Redirect.

Behind a CDN, it may be better to handle the first redirect at the CDN level. Avoid rules that bounce between HTTP and HTTPS, or between two hostnames.

Step 4 — Test several paths

Check at least the home page, an old page, an active inner page and an address with parameters. A fix on / does not prove that every old page reaches the right content. After a migration, avoid redirecting all old pages to the home page without a relevant match: Google may treat them as “soft 404” errors.

Step 5 — Check the result

The old address should lead straight to the new HTTPS destination, and the final page should respond with a 2xx code. Run the test again in Redirect Audit to compare the number of hops and the response time.

These examples are a starting point: adapt them to your setup and test them before applying them to a live site.