Beamfar

Redirect chains after a site migration: find them and fix them

Every migration produces redirects, and redirects added over time produce chains: http:// goes to https://, which goes to www, which goes to the new path, which goes to the new language folder. Each hop costs time, risks a mistake and blurs which URL should be indexed.

What redirects do

A redirect answers a request with a status code in the 3xx range and a Location header naming another URL. Google groups them by intent:

  • Permanent (301, 308): the move is final. Google uses a permanent redirect as a signal that the target should be the canonical URL, and shows the target in results.
  • Temporary (302, 303, 307): the move may be reverted. Google does not use a temporary redirect that way, so it tends to keep the original URL in results.

Google recommends a permanent server-side redirect whenever you change a URL for good. A JavaScript redirect is a last resort, because Google may never see it if rendering fails.

Two practical cases follow from this. A redirect left as 302 after a migration, because a plugin default or a copy-pasted rule used it, tells Google the old URLs still matter. And a permanent redirect to the wrong place is hard to undo, because browsers and search engines cache it.

How many hops are too many

Google documents that its crawlers follow up to 10 redirect hops by default. Its site-move guidance goes further and asks you to redirect old URLs directly to their final destination, and where that is not possible to keep chains short, no more than three hops and fewer than five. A chain is not penalised as such, but it wastes crawl time, slows visitors and multiplies the chance that one link in the chain is broken.

How chains and loops appear

  • Layered rules. The host forces HTTPS, the CMS forces www, a plugin forces a trailing slash and the migration adds a path map. Each rule works alone; together they produce four hops.
  • A second migration on top of the first. /old goes to /new, and later /new goes to /newer. The first rule still points at /new.
  • Conflicting rules. One layer adds a trailing slash, another removes it. The browser reports “too many redirects”.
  • The redirect target itself redirects, for example to a login page, a language selector or a maintenance page.
  • Everything goes to the home page. Not a chain but the worst redirect map: Google’s guidance warns against sending many old URLs to one irrelevant page such as the new home page.
  • A redirect that varies by region or device. One region gets the chain, another gets a 200.

Find them

  1. Crawl the old URL list. Use the URLs from the old sitemap, analytics, server logs and the backlinks you know of. For each, record the first status, the number of hops, the final URL and the final status.
  2. Test the four site variants: http://example.com, http://www.example.com, https://example.com, https://www.example.com. Every one should reach the single preferred URL in at most one hop.
  3. Look at the final status. The end of a redirect should be a 200. A 404 at the end is a broken redirect; a 302 at the end is a chain that still has a link in it.
  4. Check from more than one place. A CDN or geo rule can change the chain.
  5. Look in Search Console at the Pages report for “Page with redirect” and at server logs for Googlebot hitting redirect URLs repeatedly.

A command line check shows each hop: curl -sIL -o /dev/null -w "%{url_effective} %{num_redirects}\n" http://example.com/old-page prints the final URL and the number of redirects followed.

Fix them

  1. Decide the preferred form once: scheme, host (www or not), trailing slash, language prefix.
  2. Write a map from every old URL to its single best new URL. Redirect page to page. When the content is gone, a relevant parent page is better than the home page, and an honest 404 or 410 is better than a misleading redirect.
  3. Collapse the chain. Change each old rule to point at the final URL directly, not at the next hop.
  4. Use 301 or 308 for permanent moves, 302 or 307 only for what is really temporary.
  5. Update what you control: internal links, canonical tags, sitemap URLs and navigation should use the final URL and cause no redirect at all.
  6. Keep the redirects. Google’s guidance says to keep them as long as possible, generally at least a year. Redirects can stay indefinitely for users; you should update your own links and important external links to the new URLs.
  7. Re-test the map and the four variants after every deployment.

Watch after the migration

Google’s site-move guidance suggests watching traffic shift from old to new, the server logs for Googlebot and for URLs that unexpectedly return errors, and Search Console for unexpected crawl errors. The checks that need to be repeated are the ones no one repeats: after the next theme update, host change or SSL change, the redirect rules may quietly change.

How Beamfar helps

Beamfar follows the redirects on each check and records the final URL on the site’s timeline, so a redirect that starts pointing somewhere new shows up as a change, and a redirect loop is flagged. It tells you that the final destination changed or looped; it does not crawl your old URL list or draw the redirect map. Use a crawler for the migration itself and a monitor to notice when it breaks later.

Questions

How many redirects will Google follow?

Google’s crawlers follow up to 10 redirect hops by default. Its site-move guidance asks for a direct redirect to the final URL, and if that is impossible, fewer than five hops.

What is the difference between 301 and 302?

A 301 is permanent, and Google uses it as a signal that the target should be the canonical URL. A 302 is temporary, and Google does not use it as a signal that the target should be canonical, so it tends to keep the original URL in results.

Should I redirect everything to the home page after a migration?

No. Redirect each old URL to the closest equivalent new page. Mass redirects to an irrelevant page are called out as poor practice in Google’s guidance.

How long should I keep migration redirects?

As long as possible, generally at least a year according to Google. For users they can stay indefinitely; update your own links so that the redirects are rarely used.

Sources

Read on . Standards and vendor pages change; confirm the current text before you rely on it.

Terms used in this guide

  • RedirectA redirect is an HTTP response that sends a visitor or crawler to another URL. The permanent and temporary status codes and how Google treats each.
  • Redirect chainA redirect chain is a sequence of redirects between the first URL and the final page. How many hops Google follows and why to collapse chains to a single hop.
  • HTTP status codeAn HTTP status code is the three-digit number that opens a server response and says how the request went: 2xx success, 3xx redirect, 4xx client error, 5xx server error.
  • Canonical URLThe canonical URL is the address a search engine treats as the main version of a page that exists at several URLs. How rel=canonical, redirects and sitemaps signal it.

Know first. Know why. Tell your client before they call.

Paste your client list. Both regions start checking.

No card for the trial.