What a redirect checker does
A redirect checker — also called a link checker, redirect tracer, or URL tester — requests a link the way a browser would and records every redirect it meets. Rather than stopping at the first 301 or 302, it follows the chain until it reaches the final page.
This tool recognizes HTTP redirects (301, 302, 303, 307, and 308), JavaScript redirects such as location.href and location.replace, and meta refresh tags. For each hop it shows the URL, status code, response time, cookies set, redirect target, and selected response headers.
The result is a complete map of the path: where the link starts, which services sit in the middle, and where the visitor actually lands. The final URL appears at the top, along with a parametrized version that preserves tracking parameters the last redirect may have dropped.
Why use a redirect checker?
Find broken links
See the exact hop where a chain fails, loops, or returns an error before your visitors do.
Audit SEO redirects
Count the hops, spot chained redirects, and confirm the final page is the intended destination.
Verify affiliate links
Check that a tracking link reaches the right merchant with the right parameters and affiliate IDs.
Expand short URLs
Reveal where a tiny URL really goes before you click it or share it.
Redirect tracing is also useful for competitive research and post-migration checks: it shows which ad networks, affiliate platforms, and landing pages a campaign uses, and whether old URLs still reach their replacements.
How to use this tool
- Paste the link Enter a normal page, a shortened link, or an affiliate click URL.
- Set the limits Choose the maximum number of hops and the timeout per request. The defaults suit most links.
- Start tracing The tool follows the chain server-side and carries cookies and Referer headers between hops, so session-based redirects still work.
- Read the chain Each hop shows its type, status, timing, cookies, and target. The summary reports the hop count, total time, and final landing page.
- Copy or open the result Copy the final URL, open it in a new tab, or use the parametrized final page to test attribution with the tracking parameters intact.
Tip: if a chain looks wrong, trace the same link in a private browser window. Cookies, login state, and region can change the path.
Troubleshooting redirect problems
Redirect problems usually appear in one of four forms: a chain that ends on an error status, a loop that never reaches a page, a 3xx response without a Location header, or a final page that is not the one you expected.
The hop list points straight at the failure. The error badge marks the request that failed; the hop before it is the last one that worked. A loop badge means the chain returned to a URL it had already visited. A missing Location header usually indicates a server or application configuration problem.
If a link works in one browser but not another, session state is often the cause. This tool carries cookies from hop to hop within a single trace, which covers many login and consent flows, but it is not a full browser. Compare the trace with what you see in a private window before changing server rules.
After a site migration, trace a sample of old URLs. Each should reach its replacement directly, without an intermediate error or an unexpected extra hop.
Redirect chains and SEO
Search engines use links to understand and rank pages. A redirect passes visitors and most ranking signals to the target, but every extra hop adds latency and another chance for the chain to break. Long chains can also waste crawl budget.
Prefer one redirect from the old URL to the final destination. If you find a chain, update the first redirect to point directly at the last URL. Remove redirects that lead to other redirects, and make sure the final page returns 200 rather than another 3xx.
How much link equity survives each redirect is still debated. The practical conclusion is less controversial: fewer hops mean fewer failure points, faster page loads, and a simpler setup to maintain.
Trace links after you migrate content, rename product URLs, change domains, or consolidate pages. Check both the old and new URLs, and keep the redirect in place for as long as the old link may still be used.
Affiliate links and tracking parameters
Affiliate links often pass through several platforms before reaching the merchant. A click URL may go to a network, then a tracking domain, then the merchant's own redirect, and finally the product page. Each step can add parameters such as ranSiteID, ranEAID, utm_source, or subid.
The tracer shows the complete path and explains the parameters it recognizes in the URL parameters table. Use it to confirm the merchant, affiliate ID, and campaign parameters — and to catch links that land on the wrong product or silently drop the tracking data.
The parametrized final page helps here. If the merchant redirects to a clean URL and discards the query string, the tool merges the tracking parameters found earlier in the chain onto the final URL. Open that version to test attribution without walking the chain by hand.
Finding intermediaries in the chain
The hop immediately before the final destination is usually the platform that hands the visitor to the merchant. If you are an affiliate, compare that host with the programs you joined. A host you do not recognize may be a sub-affiliate network earning a share of the commission.
Tracing your active links can reveal layers you were not aware of. Sometimes you can apply directly to the merchant or network and remove an unnecessary middle layer; other times the network is required and the layer is part of the program's tracking. Review your agreements before changing live links.
A direct relationship is not only about commission. It also brings clearer reporting, better control over creatives and landing pages, and a simpler chain to debug when something breaks.
Expanding short URLs safely
Short links hide their destination. That is convenient for social posts, SMS, and print, but it also makes phishing and misleading links harder to spot. A redirect trace reveals the full path before you decide to open the final page.
Because the tool requests the URL from its server, the destination site sees the tracer, not your browser. The tool does not execute the final page's full JavaScript or submit forms; it only reads redirects and common navigation patterns. Treat a suspicious destination with the same caution you would in a browser.
Short links can expire, change destination, or behave differently by region and device. If a link matters, trace it again close to the time you plan to use it.
What this tool can and cannot see
It follows HTTP redirects, meta refresh tags, and common JavaScript navigation patterns such as location.href, location.replace, and location.assign. Within a single trace it keeps cookies and a Referer header across hops.
It does not run a full browser, so heavily obfuscated scripts, URLs assembled at runtime, or pages that require real user interaction may not be detected. It also cannot see redirects that depend on your login, location, or device unless the server response itself differs.
Response bodies are read only to find redirects; page content is not rendered. The local version stores recent URLs only in your browser, and the hosted version does not store traces at all. The “ignore certificate errors” option applies to the local version only.