How to Find and Fix Redirect Chains After Changing URLs

To fix redirect chains after changing URLs, find all addresses that pass through two or more redirects, identify the final canonical URL, and change the rules so that each old address immediately returns a single permanent redirect to the final page. At the same time, update internal links, the sitemap, canonical tags, and hreflang attributes; otherwise, the site will continue creating unnecessary hops even after the server rules are corrected.

What Is a Redirect Chain?

A chain occurs when the requested URL redirects not directly to the target page, but to another intermediate address:

https://example.com/old
301 → https://example.com/category/old
301 → https://www.example.com/category/new/
200 → final page

The correct setup for a permanently moved page is:

https://example.com/old
301 → https://www.example.com/category/new/
200 → final page

Also check for loops in which URLs redirect to each other or a rule sends the user back to a URL already visited. A loop usually ends with a browser error or an exceeded redirect limit.

This guide applies to standard HTTP redirects with status codes 301, 302, 307, and 308, regardless of the CMS. The configuration examples below are intended for typical Apache HTTP Server and nginx installations. Configuration file locations and rule-processing order depend on the specific hosting environment, control panel, and application architecture.

Step 1. Record the Final URLs

Before changing the configuration, create a mapping table. For each old address, specify one final URL that:

returns an HTTP 200 status;
is accessible without an additional redirect;
uses the selected protocol and domain variant;
uses the agreed trailing-slash format;
contains current content that corresponds to the old page.

Old URL	Intermediate URL	Final URL	Action
/catalog/item-10	/products/item-10	/shop/item-10/	Redirect the old URL directly to the final URL
/blog/post-a	/articles/post-a	/articles/post-b/	Verify content relevance and remove the intermediate hop

Do not create a redirect automatically based only on URL similarity. If there is no content-relevant replacement for the old page, returning 404 or 410 is more appropriate than redirecting every removed URL to the homepage or an unrelated section.

Before editing the rules, save the current configuration and the list of detected chains. A bulk replacement without a URL mapping table can create loops, redirect service URLs, or break traffic from old external links.

Step 2. Check the Chain for a Single URL

For a manual check, use browser developer tools or curl. The following command prints the headers from every response in the chain and limits the number of redirects:

curl -sS -o /dev/null -D - -L --max-redirs 10 "https://example.com/old-url"

In the output, identify each status line and the corresponding Location headers:

HTTP/2 301
location: https://example.com/intermediate-url
HTTP/2 301
location: https://example.com/final-url/
HTTP/2 200

After the fix, the expected result is one 301 response followed by a 200 response:

HTTP/2 301
location: https://example.com/final-url/
HTTP/2 200

This command does not prove that the page is indexed correctly; it checks only the HTTP route. The final page content, canonical tag, robots directives, and crawler accessibility must be checked separately.

Step 3. Find Chains Across the Entire Site

For a site-wide audit, run a crawler that can follow redirects and export a redirect-chain report. Include the following in the crawl scope:

current site pages;
old URLs from previous sitemaps and migration files;
addresses from web server logs;
pages receiving external links or search-engine traffic;
URLs from crawl-error reports;
HTTP and HTTPS variants, with and without www.

The report should include the source URL, every intermediate address, the response status, and the final destination. Sort the results by the number of hops. Fix loops first, followed by chains affecting pages with internal links, organic traffic, external links, or a high number of requests in server logs.

The report name and export procedure depend on the crawler being used. Without access to the specific tool, it is not possible to state its current menu names or version-specific limitations reliably.

Step 4. Identify the Cause of Extra Redirects

A chain is most often caused by several independent normalization rules:

HTTP redirects to HTTPS.
The non-www domain redirects to the www domain, or vice versa.
The CMS adds or removes a trailing slash.
The old path redirects to an intermediate structure.
The intermediate structure then redirects to the new URL.

For example, separate rules may change the protocol, domain, and path one after another:

http://example.com/old
→ https://example.com/old
→ https://www.example.com/old
→ https://www.example.com/new/

The fix should combine these transformations for the old URL:

http://example.com/old
→ https://www.example.com/new/

General domain and protocol canonicalization rules may remain in place for other addresses. Place exact migration rules before general CMS rules and verify that the same request is not processed more than once.

Step 5. Change the Server Rules

Apache Example Using .htaccess

To redirect one exact old page, you can use mod_rewrite. The rule must appear before the catch-all rule that sends requests to the CMS:

RewriteEngine On
RewriteRule ^old-page/?$ https://example.com/new-page/ [R=301,L]

In an .htaccess context, the RewriteRule pattern is usually specified without a leading slash. Do not copy this example into a virtual host configuration without checking the context, because rewrite rules may be processed differently there.

nginx Example

For one exact path, you can create a dedicated location block:

location = /old-page {
    return 301 https://example.com/new-page/;
}

After changing nginx, first validate the configuration syntax and then apply it using the standard method configured on your system. The exact management command depends on the installation method, service name, containerization, and user permissions, so no universal command is provided here.

CMS-Level Redirects

If redirects are configured through a CMS plugin or module, look for multiple sequential entries for the same piece of content. Replace them with one entry in the form “old URL → final URL.” Then check whether the CMS itself applies additional URL normalization after the custom rule runs.

Do not maintain the same redirect simultaneously in the CDN, web server configuration, and CMS unless necessary. Rules distributed across multiple layers are harder to diagnose, and their execution order is not always obvious.

Step 6. Update Sources of Old URLs

The server-side redirect should remain in place for external traffic and old bookmarks, but internal site links should point directly to the final address. Check and replace URLs in the following locations:

navigation, breadcrumbs, and in-text links;
XML Sitemap;
rel="canonical";
hreflang and links between language versions;
structured data;
RSS feeds;
form parameters, API clients, and JavaScript requests;
email templates and exports for external systems.

A canonical tag does not replace a redirect. For a moved page, the old URL should return a redirect, while the final page should point its canonical tag to its own canonical address unless there is a justified alternative.

Step 7. Verify the Result

After applying the rules, run another crawl and manually check the key URLs. For each old address, confirm that:

the first response has the expected permanent status, usually 301;
the Location header immediately contains the final URL;
the final URL returns 200 without another redirect;
there is no HTTP-to-HTTPS transition after the first response;
the domain variant or trailing-slash format does not change on a second hop;
the final page is crawlable and contains the expected content;
internal links no longer point to the old address.

Also review the server logs after publishing the changes. Repeated requests to intermediate URLs indicate that old internal links, integrations, or external sources still exist somewhere. Do not remove working redirects simply because internal links have been fixed; old addresses may continue receiving external traffic.

Common Mistakes

Removing the first redirect. The old URL starts returning 404 even though links still point to it.
Redirecting all removed pages to the homepage. Users and search engines receive an irrelevant destination page.
Using a temporary redirect for a permanent move. A permanent status is generally used when the address change is final.
Updating only the sitemap. The chain remains accessible through internal and external links.
Placing the rule after CMS routing. The request is processed by the application first and only then reaches the redirect rule, or never reaches it at all.
Using bulk regular expressions without testing. One overly broad rule can affect administrative sections, files, and URLs that are already correct.

Final Checklist

A list of old, intermediate, and final URLs has been collected.
A content-relevant final page has been selected for each old address.
Redirect loops have been eliminated.
Each old URL redirects directly to the final URL.
The final URL returns 200.
The protocol, domain, and trailing-slash format are normalized without additional hops.
Internal links, the sitemap, canonical tags, and hreflang attributes have been updated.
The rules have been tested in a staging environment or against a limited set of URLs.
Another crawl has been completed after publication.
Old permanent redirects have been retained for external links.