Redirects: chains, loops and how to fix them

A redirect chain is when a URL redirects to another URL that also redirects: A goes to B, and B goes to C. A loop is when the sequence returns to a URL it already passed through (A goes to B, and B goes back to A) and never reaches a page. The fix is the same in both cases: every old URL should point straight to the final target with a permanent redirect (301 or 308) on the server, and the site's internal links should use the final URL. Googlebot follows up to 10 hops, but Google recommends redirecting straight to the target and, when that isn't possible, keeping the chain short: ideally no more than 3 hops and fewer than 5 (Google, site moves with URL changes).

Scope: the Google behavior described here comes from the Google Search Central documentation consulted in October 2026, and the semantics of the HTTP codes come from RFC 9110. For the full crawling and indexing process, see the guide to crawling and indexing.

Redirect types and how Google handles each one

A redirect is a response that tells the browser or crawler to fetch another URL. The most common ones are done by the server, with a 3xx code and a Location header naming the target.

The sources for the table are RFC 9110, section 15.4, Google's page on redirects and Google Search and the one on HTTP status codes.

The difference between permanent and temporary shows up in search. With 301 or 308, Google shows the target URL in results. With 302, 303 or 307, the source URL may keep appearing. Google recommends a permanent server-side redirect when you're sure it won't be reverted, and a temporary one for short-lived changes, such as a service that is down for a while.

Two details from the RFC matter in practice. First, 301 and 308 responses can be cached by the browser even without an explicit cache header: a wrong 301 keeps working for anyone who already visited, even after it's fixed on the server. That's why it pays to test the rule before publishing and to disable the browser cache while testing. Second, 308 dates from 2014, and the RFC itself warns that not every HTTP client may recognize it. For ordinary pages requested with GET, 301 does the job; 308 matters when the request method has to be preserved.

Meta refresh, JavaScript and "crypto" redirects

A meta refresh is a tag in the HTML:

<meta http-equiv="refresh" content="0; url=https://www.example.com/new">

With a 0 delay, Google treats it as permanent; with a longer delay, as temporary. A JavaScript redirect is only seen if Google renders the page, and Google warns that rendering can fail. The order of preference in the documentation is: server-side redirect, meta refresh, JavaScript and, last, what Google calls a "crypto" redirect, a page with a link and an explanation pointing to the new address, which Google may or may not understand as a redirect.

What chains and loops cause

For crawling

By default, Google's crawlers follow up to 10 redirect hops. The content of the intermediate URLs is ignored; only the final target is processed (Google, HTTP status codes). When the chain goes over the limit, ends up in a loop, has an empty or invalid URL, or has a URL over the maximum length, the Page indexing report in Search Console shows "Redirect error" for the URL (Search Console help).

Even within the limit, chains have a cost. The crawl budget guide asks you to avoid long chains because they hurt crawling. The same HTTP status page says Google's inspection tools don't follow redirects, so the URL to inspect is the final one.

For visitors

Each hop is one more request before the page starts loading. Redirect time counts toward TTFB (time to first byte), which web.dev considers good up to 0.8 seconds (web.dev, Time to First Byte). TTFB in turn is the first of the four parts of LCP, as the article on how to improve LCP explains. A single redirect already adds latency; a chain adds more. Google's migration guide also notes that not every browser and user agent supports long chains.

Redirects from another origin, such as link shorteners and campaign platforms, are usually outside your control. web.dev recommends that the URL you give advertisers and newsletters already be the final one (web.dev, optimize TTFB).

http, https, www and trailing slash: chains built from separate rules

Address variants create chains without anyone noticing, because each rule was added at a different time. An example:

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

That's three hops to reach one page. Each rule is correct on its own; the problem is the sum. The fix has two parts:

1. A single rule that takes any variant straight to the canonical form (https, with or without www, and with or without a trailing slash, depending on the site's standard) in one hop.

2. Internal links, canonical tags and the sitemap written in the final form from the start, so the browser doesn't even need the redirect.

web.dev points to the http to https redirect as a major source of redirect time. The HSTS header solves part of this: after receiving the header over https, the browser switches http to https on its own on later visits, without going through the redirect. On the first visit the redirect still happens; the HSTS preload list covers that case (MDN, Strict-Transport-Security). The article on HTTP security headers covers the configuration. Why HTTPS comes first is in website security basics.

How to map and fix redirects after a migration

The steps below follow Google's guide to site moves with URL changes, with one extra step for chains left over from earlier migrations.

1. List the old URLs. Google suggests pulling together sitemaps, server logs, analytics data and the CMS itself, including images, videos, CSS and JavaScript.

2. Build a map from each old URL to its new equivalent. Content that isn't moving to the new site should return 404 or 410.

3. Set up permanent redirects (301 or 308) on the server, each one pointing straight to the final target.

4. Flatten inherited chains. If the site has gone through other migrations, old rules may point to URLs that now redirect too. Change the target of those rules to the final URL.

5. Update what is under your control: internal links, rel="canonical" (each new URL with a canonical pointing to itself), hreflang annotations and the sitemap with the new URLs. Include the URLs that appear in structured data, such as BreadcrumbList items. Google notes that redirects are slow for visitors, and updated links avoid the hop.

6. For a domain change, submit the change of address in Search Console for every verified variant of the old domain, including subdomains, www and non-www, even the ones you don't use.

7. Test before and after publishing (next section) and watch the Page indexing report, the logs and analytics. Traffic should drop on the old address and rise on the new one.

How to test redirects

On the command line, curl shows each hop:

curl -sIL https://example.com/product

-I asks for headers only, -L follows redirects and -s hides the progress bar. Each block in the output is a hop, with the status code and the location header of the next target. Some servers respond differently to HEAD, which is what -I sends, and to GET. To check a list of URLs with GET, one per line in a file:

while read -r url; do
  curl -s -o /dev/null -L --max-redirs 10 \
    -w "%{http_code} %{num_redirects} $url %{url_effective}\n" "$url"
done < urls.txt

The output shows the final status, the number of hops, the URL tested and the target. Any line with more than one hop is a chain to flatten. In a loop, curl stops at the --max-redirs limit and exits with code 47 (too many redirects).

In the browser, the Network tab of the developer tools shows the sequence when you turn on the option to preserve the log and disable the cache, because of 301 and 308 caching. For the whole site, an SEO crawler lists the internal links that point to URLs with redirects; each one can be replaced with the final URL. For individual URLs, Google suggests Search Console's URL Inspection, keeping in mind that it doesn't follow the redirect: it shows that the URL redirects, and the target has to be inspected separately.

How to check your site

WebVyze's redirect checker, one of the free tools, checks the hops of a URL without needing a terminal. For what Google actually recorded, the reference is still the Page indexing report in Search Console.