Redirect Checker

Paste the starting URL into a redirect checker and it follows every hop, showing the status code, target URL, and Location header at each step until it lands on a 200 response. So a chain like http → https → www → final URL becomes visible step by step. For SEO audits this is critical — chains of three or more hops waste crawl budget and slow page load. I want my juniors to flag any client URL with more than two redirects in the chain.

301 means permanent — the resource has moved for good and search engines should transfer ranking signals to the new URL. 302 means temporary — the old URL will return, so signals stay with the original. For site migrations, page consolidations, or HTTPS migrations, always use 301. For A/B testing or short-term campaigns, 302 is correct. Using 302 when you mean 301 is one of the most common technical SEO mistakes — it leaves ranking equity stranded and slows down recovery after a migration.

Done right, redirects preserve nearly all ranking signals when content moves. Google has confirmed 301s pass full PageRank these days. Done wrong, they leak equity, create crawl waste, or trigger soft 404s. Common pitfalls: chained redirects (slow and dilutive), redirecting many old URLs to a single homepage (interpreted as soft 404), using 302 for permanent moves, or breaking the redirect chain mid-path. Always map old URLs to relevant new URLs one-to-one when possible. Lazy redirects to the homepage are a classic mistake that costs traffic.

Run the URL through a redirect checker and watch for a chain that keeps returning the same URLs in sequence — A → B → A → B forever. Most tools cap their follow at 10–20 hops and report "loop detected " or "too many redirects ". Browsers throw an "ERR_TOO_MANY_REDIRECTS " error to users. The fix is usually in server config: conflicting rewrite rules in .htaccess, mismatched WordPress site URL settings, or Cloudflare SSL mode set to Flexible while origin redirects to HTTPS. Always test post-deploy to catch these.

Test the plain HTTP version of the URL — for example http://example.com — in a redirect checker. The response should be a 301 (permanent) leading to https://example.com, ideally in a single hop. Common mistakes: using 302 instead of 301, redirecting to a different subdomain accidentally (http://example.com → https://www.example.com → https://example.com creates an unnecessary chain), or having mixed content where some pages redirect and others don't. Every HTTP URL on the site should land on its HTTPS equivalent in exactly one hop.

Test both versions explicitly — check what http://www.example.com and https://www.example.com both resolve to, and confirm they 301 to your chosen canonical (with or without www). Then do the reverse — test the non-www URL. Whichever one you don't use as canonical should redirect to the one you do. Mixed signals confuse Googlebot and split ranking signals across two versions of the same site. Pick one, enforce it everywhere, and document it so the dev team doesn't accidentally undo it later.

Anything more than two hops in a chain starts to hurt. Google has historically said it follows up to 5 redirects per URL during a crawl, but each hop adds latency for users and wastes crawl budget. Best practice: keep chains to one hop, two at most. So if you migrated from HTTP to HTTPS, then later from www to non-www, fix the old rules so HTTP non-www jumps directly to HTTPS non-www in a single 301 — not through three hops chained together over the years.

Server responses can vary based on user agent, IP geolocation, cookies, HTTPS vs HTTP, and CDN caching. A site might return 200 to Googlebot, 301 to mobile users, and a different chain to desktop visitors. CDN edge cache can also serve different responses than origin. To get a clear picture, test with multiple user agents (Googlebot mobile, Chrome desktop, etc.) and multiple geographic locations. Inconsistent redirects across these tests usually point to misconfigured redirect rules or aggressive geo-targeting.

Find the broken hop first — wherever the chain returns a 404, 500, or loops back. Then trace the source: server config (nginx, Apache, IIS), CMS plugin (Yoast Redirects, Redirection plugin in WordPress), CDN rules, or application-level routing. Update the rule to point to a valid live URL with the correct status code (usually 301). Clear any caches — both server-side and CDN edge — and re-test from a fresh tool that hasn't cached the old response. Always confirm the final URL returns 200, not just "no redirect error ".

Yes, noticeably. Each hop in a chain adds a full round-trip — DNS lookup, TCP handshake, TLS negotiation, HTTP response — before the browser can move to the next URL. On mobile networks especially, three hops can add 1–2 seconds before the actual page even starts loading. Core Web Vitals scores suffer, conversion rates drop, and Googlebot crawls less efficiently. After any migration, audit your redirect chains and collapse them to single hops. It's a quick performance win that doesn't require code changes.