A redirect hop is a single step in a sequence of URL redirects: one URL redirecting to another. Every time a browser or web crawler follows a redirect and arrives at a URL that itself returns another redirect rather than a final 200 OK response, that transition from one URL to the next is a hop.

A single redirect, URL A redirecting directly to a final destination that returns 200 OK, is one hop. This is the correct and ideal configuration for any redirect. When that destination itself redirects to another URL, a second hop occurs. When that URL redirects again, a third hop occurs. The accumulation of multiple hops is what forms a redirect chain.

The concept of a redirect hop is simple but its implications for performance, SEO equity, crawl budget, and browser limits make it one of the most practically important concepts in redirect management. Every hop has a cost. Those costs compound. The goal of good redirect management is always to minimise hops, ideally reducing every redirect to a single hop from source to final destination.

How a redirect hop works

Each redirect hop follows the same mechanical sequence. A browser or crawler sends an HTTP request to a URL. The server responds with a 3xx status code and a Location header pointing to the next URL. The browser reads the Location header and sends a new HTTP request to that URL. If that URL also returns a redirect, another hop occurs. This continues until a URL returns a non-redirect response, typically 200 OK for a live page, 404 for a missing page, or 410 for a permanently removed page.

Each hop is a complete round trip: a request sent from the browser to a server and a response returned. On a typical connection each round trip takes tens to hundreds of milliseconds depending on server response time, network latency, and geographic distance between the browser and server. These times add up quickly with multiple hops.

The cost of each hop

Every redirect hop imposes costs that accumulate across the full chain. Understanding these costs at the individual hop level explains why minimising hops matters so much.

Latency per hop: each hop requires a complete HTTP request-response cycle. A server response time of 50 milliseconds per hop means a three-hop chain adds 150 milliseconds of redirect latency before the browser even begins loading the final destination page. On mobile connections or high-latency networks, per-hop latency can be significantly higher.

DNS lookup per hop: if consecutive hops involve different domains, each new domain requires a DNS lookup to resolve the domain name to an IP address. DNS lookups add additional latency on top of the connection time, typically 20 to 120 milliseconds per lookup depending on DNS caching state and resolver performance. A three-hop chain crossing three different domains could add 300 milliseconds or more in DNS lookup time alone before any content is delivered.

SSL handshake per domain: when a hop crosses to a new domain over HTTPS, a TLS handshake is required to establish the secure connection. TLS handshakes add one to two round trips of latency before the redirect response can be received. A hop chain crossing multiple HTTPS domains multiplies this overhead.

SEO equity dilution per hop: each hop in a redirect chain marginally dilutes the link juice and SEO equity being passed from the original URL to the final destination. A 301 redirect passes the substantial majority of equity, but research and practical SEO experience suggest the transfer is not perfectly complete at 100% through each hop. With each additional hop, a small incremental amount of equity is lost. The effect is small per hop but measurable across chains of three, four, or five hops, particularly for URLs with strong backlink profiles.

Crawl budget per hop: Googlebot and other web crawlers follow each hop as a separate request. A three-hop chain consumes three crawl requests to reach the final destination, three times the crawl budget cost of a single-hop redirect. On large sites where crawl budget is a meaningful constraint, redirect chains with multiple hops can consume a significant portion of the crawl budget allocation on unproductive intermediate hops rather than on live indexable content.

Hop limits

Both browsers and search engine crawlers enforce limits on how many redirect hops they will follow before stopping. Understanding these limits explains why long chains transition from performance problems to outright accessibility failures.

Browser hop limits: most browsers follow up to 20 redirect hops before stopping and displaying an error. Chrome, Firefox, Safari, and Edge all implement this limit approximately. When the limit is reached the browser displays ERR_TOO_MANY_REDIRECTS or an equivalent error. The page is completely inaccessible to the visitor.

Googlebot hop limits: Googlebot follows up to five redirect hops before stopping. This is a significantly lower limit than browsers, a chain of six or more hops that a browser would still follow successfully will stop Googlebot before it reaches the final destination. If Googlebot’s five-hop limit is reached before the final destination, the content at that destination cannot be indexed regardless of its quality or importance.

Other crawler limits: different web crawlers have different hop limits. Most follow fewer hops than browsers. Bing’s crawler, Apple’s crawler for Spotlight, and other specialised crawlers all have their own limits that may be lower than Googlebot’s five hops.

The practical implication is clear. A redirect chain should never exceed five hops, and should ideally be a single hop. Chains approaching five hops are at high risk of preventing Googlebot from reaching the final destination. Chains exceeding five hops guarantee Googlebot cannot index the content.

Single-hop redirects, the ideal

A single-hop redirect, one URL redirecting directly to a final destination returning 200 OK, is the ideal configuration for every redirect. It minimises latency to a single round trip, passes SEO equity to the destination with maximum efficiency, consumes the minimum possible crawl budget, and is well within every browser and crawler hop limit.

Achieving single-hop redirects across a site requires proactive management, particularly during infrastructure changes, domain migrations, and URL restructuring, to ensure that new redirect rules always point to the current final destination rather than to URLs that themselves redirect.

The most effective way to maintain single-hop redirects over time is to treat every new redirect addition as an opportunity to audit the destination. Before configuring a redirect from URL A to URL B, check whether URL B itself redirects. If it does, follow the chain to the final destination URL C and configure the new redirect from A directly to C, bypassing B entirely. This prevents chains from forming incrementally.

Counting hops

Understanding how hops are counted helps in auditing and optimising redirect configurations.

A direct redirect with no intermediate hops:

• Request → URL A → 301 to URL B → Request → URL B → 200 OK

• 1 hop

A two-hop chain:

• Request → URL A → 301 to URL B → Request → URL B → 302 to URL C → Request → URL C → 200 OK

• 2 hops

A four-hop chain:

• Request → URL A → 301 to URL B → Request → URL B → 301 to URL C → Request → URL C → 302 to URL D → Request → URL D → 301 to URL E → Request → URL E → 200 OK

• 4 hops

In all cases the hop count is the number of redirect responses received before the final 200 OK. Each redirect response, each 3xx status code, is one hop.

Mixed hop types

A redirect chain can include hops of different types, mixing 301s, 302s, 307s, and 308s across consecutive hops. Mixed hop types create additional complexity for SEO equity transfer because the type of each hop affects how search engines treat the overall chain.

A chain that starts with a 302, temporary redirect, followed by a 301, permanent redirect, is treated differently than a chain of two 301s. The temporary redirect at the start of the chain affects how search engines interpret the overall permanence of the move and may reduce equity transfer even if subsequent hops are permanent.

The general principle is that the weakest redirect type in a chain limits the overall equity transfer. A chain with any temporary hop is treated more conservatively than a chain of entirely permanent redirects. Where possible, all hops in a chain should use the same redirect type, and ideally the chain should be collapsed to a single hop anyway.

Hops in HTTP to HTTPS and www redirects

HTTP to HTTPS and www to non-www redirects are among the most universal sources of unnecessary hops because they are often implemented independently and at different infrastructure layers without being combined.

A visitor arriving at http://www.example.com/page on a site that enforces both HTTPS and non-www might encounter:

• http://www.example.com/page → https://www.example.com/page (HTTP to HTTPS hop)

• https://www.example.com/page → https://example.com/page (www to non-www hop)

Two hops to reach https://example.com/page. Both are necessary redirects, but they do not need to be sequential hops. A properly configured server can handle both in a single rule:

• http://www.example.com/page → https://example.com/page directly

One hop instead of two. The redirect logic checks for both conditions simultaneously: is it HTTP? Is it www? and redirects directly to the canonical HTTPS non-www destination in a single response.

This type of consolidation: combining multiple redirect conditions into a single hop, is one of the highest-value optimisations in redirect management because it applies universally to every URL on a domain.

Auditing hops

Regular auditing of redirect hop counts across a site is an important part of technical SEO maintenance.

Individual URL checking: curl -IL https://example.com/url follows all hops and shows the status code and Location header at each step. Counting the 3xx responses in the output gives the hop count for that URL.

Site-wide crawl: SEO crawl tools audit all URLs on a site and report redirect chains including hop counts. Most tools flag chains above a configurable threshold, commonly two or more hops, as issues requiring attention.

Monitoring after changes: any infrastructure change that involves redirects, CDN configuration, server config updates, application deployments, redirect rule additions, should be followed by spot-checking hop counts on affected URLs to confirm new chains were not inadvertently created.