Redirect Chains: Stop Sending Visitors Round

TL;DR: Fix redirect chains by sending each legacy URL directly to its correct final destination, then update the links you control and test the live journey.

Key takeaways

  • A redirect chain sends a visitor through intermediate URLs before reaching the destination.
  • Google recommends redirecting directly to the final destination because chains add latency.
  • Permanent moves normally call for permanent server-side redirects, such as HTTP 301 or 308.
  • Shortening a chain should preserve useful old entry points, not simply delete their redirects.
  • A cleaner route is technical maintenance, not a guarantee of rankings, leads or AI citations.

What are redirect chains?

Redirect chains occur when a URL redirects to another URL that also redirects before the final page is reached. Google's site-move guidance describes this pattern and recommends going directly to the final destination.

A redirect loop is a different problem: the route returns to an earlier point instead of resolving. Keep the distinction in your audit, because shortening a working chain and repairing a loop are not the same acceptance task.

Our recommended starting point is commercial rather than cosmetic. Check the old URLs that still receive enquiries, useful referral traffic or links, then inspect the routes to your important current pages. A tidy spreadsheet of low-value redirects is less useful than fixing the one that disrupts a service enquiry.

Conceptual direct route and multiple doorways representing a redirect and a redirect chain

The goal is not to abolish redirects. It is to make each necessary redirect say where the resource belongs, without sending the visitor on a tour of the site's previous decisions.

How many redirects can Google follow?

Google's migration guidance says Googlebot can follow up to ten hops in a chain, but it recommends redirecting to the final destination directly. The same guidance advises keeping unavoidable chains short and notes that chains add latency and are not supported equally by all user agents and browsers.

Ten is therefore not a design target. It is also not a promise about every AI crawler, browser or retrieval system. Do not turn a documented Googlebot behaviour into a universal internet allowance.

We recommend setting a simpler requirement for a permanent page move: the old address should reach the intended replacement through one direct redirect where technically feasible. If there is a necessary intermediate step, record its purpose and test the resulting behaviour instead of hiding it in a green status label.

Should you use a 301, 308 or temporary redirect?

Use a permanent server-side redirect for a move intended to remain permanent, and a temporary redirect for a genuinely temporary change. Google's redirect documentation identifies HTTP 301 and 308 as permanent and describes temporary options including 302 and 307.

HTTP means Hypertext Transfer Protocol, the system behind these response status codes. The status is not decoration: Google's documentation explains that permanent and temporary redirects send different signals about which URL should be canonical, meaning the preferred version for indexing.

Do not choose a permanent status merely because it sounds stronger. Ask whether the original address is meant to return. Keep temporary service interruptions separate from permanent content moves in the change record.

Conceptual metal chain loop representing a redirect that returns to an earlier URL

For permanent moves, Google recommends server-side redirects where possible. Its redirect guide places JavaScript redirects behind server-side and meta-refresh alternatives, rather than treating every implementation as interchangeable.

Point each still-useful legacy URL directly to the approved final destination rather than deleting the earlier entry points. Google's migration guidance combines direct destinations with keeping redirects for as long as possible, generally at least a year for a site move.

Our preferred workflow starts with a mapping record. Give each old URL an explicit intended destination, a reason for that destination and an owner who can approve it. Do not let the current chain decide the answer by accident.

Then check relevance. Google warns against sending many unrelated old pages to a generic homepage, which can confuse users and may be treated as a soft 404. A legitimately consolidated replacement page is a different case, as the same documentation explains.

For a business serving several countries, our additional judgement is to treat market and language as part of relevance. Confirm the destination still matches the visitor's intended service region and language. A direct route to the wrong market is still the wrong route.

For a larger move, use our SEO migration guide to build the wider plan before changing rules.

Update the internal links and URL references you control to point at the new destination, rather than leaving them dependent on the redirect. Google's site-move instructions cover internal links, canonical annotations, multilingual annotations and new sitemap URLs.

Illustrative developer reviewing a laptop, with no actual crawl report or client results shown

A canonical annotation identifies a preferred URL; it is not a substitute for sending a visitor to the intended page. Keep the routing decision and the indexing signals consistent, while testing them separately.

Our suggested order is navigation, commercial calls to action, frequently visited editorial pages and reusable templates. Then check downloads, image links and campaign destinations where they are part of the move. Google's migration guidance explicitly includes embedded resources and updating campaign links.

The SAGEO internal-links guide provides a complementary way to prioritise important destinations. Do not make readers follow yesterday's address simply because the redirect still functions.

What should a live redirect audit record contain?

A useful record shows the complete observed route and whether the destination is correct, not just whether some page eventually loaded. Google recommends testing redirects with URL Inspection or command-line tools and scripts.

We recommend recording the following fields without filling gaps with assumptions:

FieldEvidence to retain
Requested URLThe exact starting address tested
Response sequenceEach observed status and destination in order
Final pageFinal URL, response status and visible content
Intended destinationApproved replacement and market/language fit
Related signalsRelevant canonical, indexing and internal-link checks
AcceptanceTest time, reviewer and any unresolved exception
Conceptual bridge connecting two destinations, illustrating relevant URL mapping

Test representative old addresses, not only the newest source URL. Include the relevant hostname and protocol variants in your agreed scope. For a multilingual business, sample each affected locale rather than assuming one successful English-language route proves the others.

Also follow the live journey in an ordinary browser. Our acceptance question is whether the visitor reaches the correct usable page and can take the intended next step. A successful HTTP response is necessary evidence, but it is not the whole commercial experience.

Will removing redirect chains improve AI visibility?

Removing unnecessary redirects is sound technical housekeeping, but it does not establish that an AI system will cite the destination. Google's AI-feature documentation says supporting links in AI Overviews and AI Mode must be indexed and eligible for a search snippet, while inclusion is not guaranteed.

The same documentation says ordinary SEO best practices remain relevant and no special optimisation is required for those features. It does not provide an uplift figure for reducing redirect hops.

Keep implementation evidence separate from outcome evidence. First confirm the approved routes and links behave as intended. Then monitor indexing, traffic and qualified enquiries over time, documenting other changes that could affect the result. Do not label every improvement after a redirect change as its consequence.

Limitations

This is an audit framework, not a report of work performed on your site. Google's documentation describes Google Search behaviour, not every search engine or AI retrieval system. We have not measured latency, rankings, citations or conversion effects for the reader's website.

Generated images are conceptual illustrations, not crawl reports, client case studies or performance evidence.

Illustrative project folder, blank record card and stopwatch for documenting redirect verification

What should you bring to a SAGEO conversation?

Bring the current redirect map, observed routes and the commercial pages that matter most. Use the SAGEO starting point to discuss the problem with those records in hand.

The useful brief is not to make every redirect disappear. It is to preserve the right entry points, remove unnecessary detours and prove that visitors arrive somewhere worth reaching.

Sources