Redirect Checker

Why a redirect checker needs more than one URL

A redirect checker earns its keep on more than the single URL you paste, because a redirect is usually the right call. It walks visitors from an old address to a new one. It keeps old bookmarks alive after a migration, nudges traffic onto HTTPS, and lets a site pick one canonical hostname so it isn't bleeding signals across a handful of public variants. Trouble starts when the path goes fuzzy. One old rule points at another old rule. HTTP does its own thing while HTTPS does something else. The www host lands in a different spot. Or, worst of all, the final page declares a canonical URL that flat-out disagrees with where the chain dumped you.

So this checker doesn't stop at the main URL. It traces the chain you handed it, kicks the tires on the usual protocol and hostname variants, swallows a short batch of migration URLs, and reads the final page signals whenever there's an actual reachable document at the end. Honestly that's pretty close to what the job feels like in real life: the WordPress permalink switch, the domain move, the HTTPS cleanup, an audit at 11pm before a launch.

How to read a redirect chain

Read it row by row. Each row is one sampled response. A permanent redirect (301 or 308) is normally saying "this move is staying put." A temporary one (302 or 307) can be perfectly fine for short-lived routing, a session, a login bounce. But it earns a hard look when an old public URL has clearly moved for good and someone left it on a temporary code anyway. The last row? That's where it counts. It should be either the real destination document or an error you actually meant to serve.

• Go with the shortest path that still does what you meant it to do.
• Land every final destination on the canonical protocol and hostname you picked, no exceptions.
• Fix the internal links, the sitemap URLs, the marketing links. Don't lean on redirects forever, that's a crutch.
• Hunt down loops and repeated hops. And those temporary moves quietly doing permanent work. And anything ending in a 4xx or 5xx.
• Retest the rules that matter after you touch the CDN, the cache, a security plugin, the web server config.

Redirects, canonical tags and search signals

These two get confused all the time. A redirect says where the request goes right now. A canonical tag tells search engines which URL the page would rather be seen as when duplicates or variants float around. Different jobs. A healthy site just makes them agree. Say an old page redirects to a new URL, and then that new page canonicalizes itself to somewhere else entirely. Now you've handed Google a contradiction, and that needs a look. Same story for sitemap entries or internal links still aiming at URLs that bounce through a redirect on every single crawl.

For SEO, you want redirects to be boring. Boring is the goal here. The destination should be clear, live, indexable if it's meant to rank, linked straight from the site when you can swing it. And clean redirects don't paper over thin content, never have. They just clear the friction so people and crawlers reach the stuff you already sweated over.

A practical migration checklist

1. Grab a sample of old URLs from each template or content type that matters.
2. Make sure the important ones land on their closest useful new home.
3. Compare how HTTP, HTTPS, www and non-www behave against your preferred host policy.
4. Check the canonical tag and the robots signal on the page you actually land on.
5. Update internal links and sitemaps, but only once the redirect rules have stopped moving.

Common redirect mistakes

The biggest one? Not redirecting at all when a URL still pulls real traffic. People just delete the page and move on. Right behind it: dumping everything onto the homepage (lazy, and Google notices), letting historical rules pile up across three migrations until nobody remembers why they're there, slapping a temporary code on a permanent move for no reason anyone wrote down. And folks forget that query strings, a trailing slash, or an alternate host can quietly take a totally different route. A quick batch check catches a lot of this before it turns into the thing you're explaining in a postmortem.

Frequently asked questions

Is a two-step redirect always bad?

Not always. Sometimes an edge rule or a protocol switch or something in the app just makes it unavoidable for a stretch. Still, you want to know it is there, especially on your high-traffic URLs and on any migration path you could actually flatten if you sat down with it for ten minutes.

Should every 404 redirect somewhere?

No. If there is no close replacement, an honest 404 (or a 410) beats shoving someone onto a page that has nothing to do with what they wanted. Redirect when the new spot genuinely answers the old intent. Otherwise let it 404 and move on.

Why check the canonical after redirects?

Because the page you finally land on can still name a preferred URL that fights with where the redirect sent you. When you are deep in technical SEO, you want both signals telling the same story, not arguing with each other.

Should I use a 301 or a 302 redirect?

Use a 301 for permanent moves. That is the one that tells search engines to hand the ranking over to the new URL. Save 302 for content that is genuinely temporary, where you want the original to hang onto its value because it is coming back.