How to Check Redirects on a Website: 301 Redirect Checker, Chains and Loops
Every redirect is a small conversation between a browser and a server, and most of the time nobody listens to it. A page moves, a rule fires, a visitor lands somewhere new, and the only evidence is a number that flashes past in a developer console. Checking redirects means listening to that conversation on purpose: requesting a URL, following each hop, reading the status code at every step, and confirming where the chain finally ends. If you want the quickest way to start, you can check 301 redirect behaviour on any address without installing anything, and then move on to the deeper checks described below.
The reason this matters is simple. A permanent redirect is how a website tells browsers, crawlers and the links pointing at it that content has moved for good. When that message is delivered cleanly, visitors arrive at the right page and the old address keeps its value. When it is delivered badly, through a temporary code, a detour through three intermediate addresses, or a rule that quietly sends everyone back to the homepage, the damage is slow and hard to see. Pages drop out of search, internal links keep pointing at addresses that no longer belong to the site, and nobody notices until traffic has already slipped.
- If a page has moved since a link was published, a 301 from the old address keeps the link working without asking every publisher to change anything
- When a page is later renamed or restructured, the inventory shows exactly which redirects need to be checked and which external references depend on them
- Online checkers give you speed, curl gives you precision, and browser developer tools give you the visitor's view, and a careful checker uses all three where each one is strongest
- Then verify the result and keep watching the reports for a few weeks, because redirect problems rarely announce themselves on the day they are introduced
What a Redirect Check Actually Tells You
A redirect is a server response with a status in the 3xx range and, usually, a Location header that names the next address. The browser does not decide where to go on its own; it follows the instruction it was given. That is why the status code carries so much weight. A 301 or 308 says the move is permanent, a 302 or 307 says it is temporary, and every client that understands HTTP treats them differently when it decides what to remember, what to cache and what to index.
A proper check has to verify several things at once. It needs the status code of the first response, the address of the final destination, and every intermediate hop in between. It also needs to confirm that the destination returns a 200 response, because a redirect that ends on a 404 or on a soft error page has failed no matter how clean the earlier steps look. Equally important is whether the redirect preserves the path, the query string and the protocol. A move from an old article to the homepage may technically be a redirect, but it throws away the page the visitor wanted.
Several everyday situations make checking unavoidable. Site migrations almost always involve a long list of redirect rules, and a single typo can send thousands of URLs to the wrong place. An HTTP to HTTPS move needs to be tested for both variants of the address. Consolidating www and non-www versions, normalising trailing slashes, and handling products or articles that have been deleted all create the same kind of risk. Each of these is cheap to verify at the time of the change and expensive to discover months later.
Choosing a Method: Online Checkers, curl or Browser DevTools
Free online checkers are the fastest option for a single address. You paste the URL, the tool requests it, follows every Location header it receives, and presents the chain as a list of hops with status codes and a final URL. For a quick question such as whether a page redirects at all, or how many steps a visitor takes to reach it, this is usually enough. The limits are just as clear: a web-based tool cannot see the full set of response headers in every detail, it cannot test pages behind a login, and it sends requests from its own location and with its own user-agent string, which may not match what a real visitor experiences.
Command-line tools fill that gap. With curl you can request only the headers using the -I flag, follow the chain with -L, and watch the entire exchange with -v. Changing the user-agent lets you test whether a server behaves differently for search engine crawlers than for ordinary browsers, which is a real source of problems when a site redirects by device or by country. The output is raw, but raw is exactly what you want when you are debugging a rule that behaves unexpectedly.
The Network panel in browser developer tools sits between the two. Opening DevTools, switching to the Network tab and enabling Preserve log keeps every redirect step visible while you navigate, so you can see each status and each Location target as the browser experiences them. Two cautions apply here. Browsers cache 301 responses aggressively, so an old redirect can keep firing even after the server has changed, and some extensions alter traffic in ways that make the results look wrong. Testing in a private window or confirming with curl before blaming the server is a habit worth building.
Choosing between these methods comes down to a handful of criteria. Scale matters first: one URL suits a web checker, while a few hundred URLs call for a script or a crawler. The depth of detail matters next, since header-level questions need curl. Reproducibility matters too, because a command you can save and rerun after every deployment is worth more than a one-off screenshot. Finally, access matters: content behind authentication can only be checked from a session that is actually logged in, which rules out most external tools.
Reading Every Hop in a Redirect Chain
The hop-by-hop output is the core of any redirect check, and it is worth reading it line by line rather than trusting the final status. Each hop has a source address, a status code, and a target taken from the Location header. The final line should be a 200 response from the page you actually intended to reach. When you see a 200 on a page with unrelated content, or a redirect that lands on the homepage, you are looking at a soft failure that many simple checks will report as success.
A redirect chain is any sequence of two or more hops between the requested address and the final one. Every extra hop adds a round trip, which slows the visit, and it adds another place where something can go wrong during the next change to the site. Search engine crawlers will follow a limited number of hops before giving up, and Google recommends keeping chains short for exactly this reason. The practical target is a single redirect from any old address to the final one, with nothing in between.
Redirect loops are the more dramatic failure. A loop is a chain that eventually returns to an address it has already visited, so it never finishes. Browsers respond with an error about too many redirects, and crawlers simply cannot index the page. In a checker, a loop shows up as a chain that hits the step limit while the same addresses repeat. The usual causes are conflicting rules, such as an HTTPS redirect configured on the server combined with a flexible SSL setting at a CDN, or www rules that are defined in both the server configuration and the content management system. The fix is to find the rule responsible by testing each variant of the URL separately and seeing which step introduces the cycle.
Confirming a 301 Redirect Works as Intended
Once a redirect is in place, four questions confirm that it is doing its job. The first response should be 301 or 308 for a permanent move, because a 302 or 307 on a page that has truly moved is the most common mistake in this area and can leave the old address in search results. The Location header should point straight at the final URL, not at an intermediate version that adds a protocol or host change. The final address should answer with 200 and show the page you meant, not the homepage and not an error. And every variant of the source address should land in the same place in one hop.
Testing the variants is where many redirect setups fail. An address can be requested over HTTP or HTTPS, with or without www, with or without a trailing slash, in uppercase or lowercase, with query parameters or with an index file name. A well-configured site sends all of these to a single canonical address. A poorly configured one might handle three of the four correctly and leave the fourth looping or pointing somewhere arbitrary. Working through the full matrix takes only a few minutes with curl and prevents surprises that would otherwise show up in analytics. To see exactly where a link ends up, you can check 301 redirect behavior with a tool that lists every hop, the status code at each step, and the final destination.
It is also worth checking how crawlers see the site. Requesting the same address with a Googlebot or Bingbot user-agent string can reveal rules that redirect or serve different content based on the requester. Such rules are sometimes added with good intentions, for instance to personalise a page for visitors from one region, and they can accidentally treat search engines as a different audience. If the crawler sees a different outcome from the browser, the difference is worth understanding before it affects indexing.
A redirect is only as good as its last hop. If the chain ends on the page a visitor wanted, with a single permanent step and a 200 response, the change is working. Anything else is a problem waiting for the next crawl.
Fixing Chains and Loops: Practical Remediation
Fixing a chain usually means rewriting the old rules so that each source address points directly to the final destination. This is the moment to audit the entire redirect map, not just the rule that prompted the check. After a migration, it is common to find that one redirect points to a page which itself redirects, and that the original rule was never updated. Collapsing these into single hops removes the extra latency and makes the configuration easier to maintain. Internal links deserve the same attention: if your own pages link to addresses that redirect, every visit to those links pays the cost of the chain, so updating the links to point at final URLs is often more valuable than any server change.
Loops call for a more methodical approach. Start by reviewing every place where redirects are defined, including the server configuration, the .htaccess file, any CDN or load balancer logic, and the settings inside the content management system. Conflicts usually come from two layers both trying to enforce the same rule, such as the server forcing HTTPS while the application forces a different host. Once you have found the conflict, remove the duplicate and keep the rule in the layer that should own it. Test each fix incrementally, so you know which change resolved the problem.
The web server itself offers clear ways to express these rules. In nginx, combining the scheme and host into a single permanent redirect avoids the two-step pattern that creates chains, and a separate server block for the www variant can send traffic directly to the canonical address. In Apache, rules placed in .htaccess can do the same job, and a generator tool can help produce them without typos. In WordPress, the general settings for the site address and the home address must agree with the server rules, because a mismatch between them is a classic source of loops. Individual page redirects are usually handled through a redirect plugin or through the redirect manager in an SEO plugin, but the same redirect should never be defined in both a plugin and the server, since that is how conflicts begin.
Validation closes the loop. After any change, rerun the checks on the addresses you touched, update the sitemap so it lists only final URLs, and make sure canonical tags point to the same addresses. Then watch the coverage and crawl reports in Search Console for a few weeks, looking for pages that drop out, errors that appear, or crawl activity that suddenly spikes on old addresses. A redirect project is not finished when the rules are deployed; it is finished when the signals settle on the new addresses.
Why This Matters for Link Promotion
Links point to specific addresses, and that is why redirects matter beyond the site itself. A permanent redirect passes most of the value of an old address to the new one, but that transfer works best when the final address is the one being promoted. Keeping the chain short and the final destination clean means the promotion effort lands on the page you intended from the start.
Some teams also keep a simple inventory of the addresses they promote, along with the redirects that serve them. This small habit prevents the situation where a carefully built set of links quietly starts pointing at error pages after a routine site update.
Conclusion
Checking redirects is a discipline of reading every step rather than trusting the outcome. A single request tells you where a visitor ends up, but only the full chain tells you how they got there, how many times the server had to speak, and whether any of those responses were the wrong kind. The four-point test for a 301, the variant matrix and the crawler check turn a vague sense that redirects are working into concrete evidence.
The fixes follow from the diagnosis. Collapse chains into single permanent hops, remove duplicate rules that fight each other, update internal links and sitemaps so they stop relying on redirects, and keep the server and the content management system aligned on one canonical address. Make the check a routine part of every change to the site, and the redirects will keep doing the quiet job they were built for: carrying visitors and their value to the right place.