The 3xx redirect codes split on two axes. Permanent vs temporary: 301 (Moved Permanently) and 308 (Permanent Redirect) tell Google the move is final, so it consolidates ranking signals to the destination and eventually drops the old URL; 302 (Found), 307 (Temporary Redirect) and 303 (See Other) say the change is temporary, so Google keeps the OLD URL in the index and does not pass signals. Method preservation: 307 and 308 are the strict modern equivalents that keep the HTTP method (important for POST), while 301/302 may switch to GET and 303 always forces GET. For a permanent move use 301 (or 308 for non-GET); reserve 302/307 for genuine temporary detours like A/B tests or maintenance. Note that Google’s John Mueller has said 301 and 308 are equivalent for SEO — there is no ranking penalty for choosing one over the other.

A redirect chain (A → B → C) multiplies problems: every extra hop adds network latency that hurts Core Web Vitals, counts as an additional request that drains crawl budget so fewer of your pages get crawled, and slightly dilutes the link equity passed to the destination. Googlebot follows up to about 10 hops before flagging a redirect error and excluding the page, and usually only follows around five per crawl, so a long chain risks the final page never being indexed. A redirect loop is worse — a URL redirects back to one already in the path, so the browser shows “ERR_TOO_MANY_REDIRECTS” and the page never loads. The fix in both cases is to point every source URL directly at the final destination in a single hop.

A browser genuinely cannot trace another site’s redirects for you. Cross-origin requests are blocked by the Same-Origin Policy / CORS, and even for a same-origin URL a fetch() automatically follows every redirect and never exposes the intermediate 3xx responses (status codes and Location headers) to JavaScript — with redirect:"manual" you only get an opaque response with status 0. We also deliberately use no server proxy, which is what keeps your URLs private. So the reliable path is to run curl -sIL https://your-url in a terminal (curl prints every hop’s status and Location) or open DevTools → Network, and paste that chain here. The tool then analyses exactly what you pasted, entirely in your browser.

The ideal redirect is a single hop straight to the destination. Google recommends keeping any chain to about three hops or fewer, follows up to roughly ten before flagging a redirect error, and typically only follows around five per crawl — so more than a couple of hops is worth collapsing. Just as important is where the chain ends: the final URL should return a 200 OK. A redirect that ends on a 4xx (like a 404 or 410) or a 5xx server error wastes the redirect entirely, loses any accumulated link equity and creates a broken experience — redirecting to a missing page is worse than letting the old URL simply 404. The checker flags the final status and warns if the chain still ends on a redirect.