1. Source
Live server-side HTTP requests, one hop at a time. The result identifies where its evidence came from.
The Novaverb redirect checker requests each URL server-side without auto-following and reports every hop in the chain: status code, Location header, scheme, host, path and latency, up to the final response.
Run a real check above
Submit a public URL, domain, or keyword. Novaverb will show only the evidence this tool can actually retrieve or measure.
A redirect checker is a tool that requests a URL and shows each redirect between it and the final page. The Novaverb version traces the chain one hop at a time from its own server, reading the status code and Location header of every step, so the reported chain is the one that actually exists.
The redirect checker checks every hop for its status code, scheme, host, path, Location header, response headers and latency, then the final destination and the total number of redirects. Chains of two or more redirects, loops and final responses that are not 2xx are flagged. An optional canonical domain check tests the http, https and www variants.
The redirect checker is for developers verifying redirect rules after a deploy, SEO specialists auditing old URLs during a migration, marketers confirming that a campaign link lands on the intended page, and site owners checking that the http and non-www versions of a domain all end at one address.
A redirect checker catches chain problems that a browser hides, because the browser follows every hop silently and shows only the last page. A temporary 302 where a permanent 301 was intended, an extra hop added by a www rule, a loop or a redirect that ends on a 404 can each be seen and fixed before launch.
The redirect checker works by requesting each URL server-side as NovaBot without auto-following, so the exact status code, response headers and Location of every hop are read directly. The chain is walked hop by hop, up to 10, until a non-redirect response. Each hop is timed, chains and loops are detected, and the final destination is reported.
Enter the URLs you actually publish or link to into the redirect checker, one per line, up to 20 at a time. Submit the old address, not the destination you expect, since the point is what happens in between. The http and non-www forms are the most revealing. A search phrase is not an address.
http://yourdomain.comThe http and non-www forms are the most revealing - they expose the http→https and www hops. Any form is accepted.one URL per line (up to 20)Paste a whole list - each URL is traced independently and shown as its own expandable row. Turn on the canonical check to also test the http/https and www variants of each host.how to fix a redirectThat is a search phrase, not an address. This tool checks URLs; use the Keyword tool for search terms.Reading '0 redirects' as a failureZero redirects is a healthy result - it confirms the URL is already the final destination (200 OK, no hop).A redirect checker report contains counts for URLs checked, URLs with redirects, redirect chains and responses that are not 2xx, then one expandable row per URL. Each row shows the sequence of status codes, a table of scheme, host and path per hop, the redirect type, latency and response headers. Results can be downloaded as CSV.
Read a redirect checker result from the status sequence of each URL. A single 301 followed by 200 is a clean setup, and zero redirects with a 200 is healthy, not a failure. Two or more redirects in a row are a chain to collapse, and a sequence ending in 4xx or 5xx is a broken target.
This tool follows each URL server-side, one hop at a time, and shows the real HTTP status of every step - not just the final page. A clean setup redirects once (301) straight to a 200 OK. Extra hops slow crawlers and users and dilute link equity.
Two or more redirects in a row (a chain) should be collapsed to a single hop pointing at the final URL. Mixed http→https and www→non-www hops are the most common cause - enable the Canonical domain check to see whether every variant funnels to one canonical URL.
The redirect checker gets its data from live HTTP requests sent server-side, one hop at a time, when you run the check. Every request is sent as NovaBot. The status codes, headers and timings shown are the ones returned to those requests, and since some servers redirect crawlers differently from browsers, a browser may be given another chain.
The redirect checker does not tell you about redirects performed in the browser. The trace follows server-side HTTP redirects only, up to 10 hops per URL, sent as NovaBot. Client-side JavaScript redirects and browser-only navigation are outside the check, so a page that returns 200 and then moves the visitor by script appears as a final destination.
A redirect checker result proves the exact chain a URL produced for this request: each hop's status code, scheme, host, path, Location header and latency, through to the final non-redirect response. It reports the code the server returned, not the intent behind it. Whether a search engine has processed the move cannot be concluded from the trace.
Live server-side HTTP requests, one hop at a time. The result identifies where its evidence came from.
The trace follows server-side HTTP redirects (up to 10 hops per URL), sent as NovaBot. Client-side JavaScript redirects and browser-only navigation are outside this check.
Use the finding to verify a problem, then connect a workspace when you need history, monitoring, or site-wide analysis.
The redirect checker applies RFC 9110, the IETF specification for HTTP semantics, which defines what each 3xx status means and how the Location header is resolved. The distinction matters because the specification gives 301, 302 and 307 different permanence and different method-preservation rules. The tool labels 301 and 308 as permanent and other redirects as temporary.
Traces each 3xx hop and its Location header per HTTP semantics.
Read the specificationVerify a redirect checker result by requesting the same URL with a command line HTTP client set to show response headers without following redirects, then repeating the request against each Location value in turn. The status line and Location header of every response should match the hops in the report, unless the server answers that client differently.
A typical redirect checker finding is an old http address without www that answers with a 301 to the https version, then a second 301 to the www host, then a 200. The report counts it as a chain, and the analysis suggests collapsing it to a single hop from the source straight to the final URL.
The redirect checker is free and requires no account. A list of URLs can be traced from the form and the results downloaded as CSV. A free Novaverb account is needed when the redirects must be found across a whole site by a crawl, kept as saved evidence, or checked again after a fix is deployed.
A Novaverb workspace adds a crawl of the whole site to the redirect checker, so redirecting URLs are found without you listing them first. Site Health Audit is the product that continues the job: a source-aware technical checklist that prioritizes supported findings and records fresh rechecks, so a repaired redirect is confirmed by a new measurement.
A free 301 redirect checker run is not enough when you do not know which URLs redirect, since it traces only the addresses you paste. Finding every redirecting URL on a site needs a crawl of all its pages. Confirming that the rules survive later releases needs the same check repeated and compared over time.
After running the redirect checker, fix any chain that ends on a 4xx or 5xx response first. Next, collapse chains so each source redirects once to the final URL. Change a temporary redirect to a 301 where the move is permanent. Then turn on the canonical domain check and confirm every host variant ends at one address.
Other free tools pair with the redirect checker before and after a fix. The Redirect Rule Generator turns a list of old and new URLs into nginx, Apache .htaccess or Cloudflare Bulk Redirect rules. The Server Response Time Checker measures DNS lookup, TCP connect, TLS handshake and first byte time. The Website Monitor runs one live availability check.
People ask what the redirect checker checks, what an HTTP redirect, a redirect chain and a redirect loop are, how a 301 differs from a 302, what a 308 is, how many redirects are too many, what the Location header does and whether the tool follows JavaScript redirects, which it does not.
It traces a URL's full server-side HTTP redirect chain, showing every hop, each status code, the final destination URL, and the total number of redirects so you can see the complete path a request takes.
A redirect is a server response, using a 3xx status and a Location header, that sends a request from one URL to another. Browsers and crawlers follow it to reach the final destination.
A 301 signals a permanent move and passes ranking signals to the new URL; a 302 signals a temporary move and is not meant to transfer them. Use 301 for permanent URL changes.
A redirect chain is multiple hops before reaching the final URL, like A to B to C. Each hop adds latency and can dilute signals, so collapse chains to a single direct redirect where possible.
Keep it to one hop when you can. Long chains slow page loads and risk crawlers giving up. The tool counts total redirects so you can spot and shorten excessive chains.
Redirects preserve link value and user access when URLs change. A correct 301 forwards ranking signals to the new address; broken or looping redirects waste crawl budget and can strand pages searchers cannot reach.
A redirect loop is when URLs point back to each other endlessly, so no final page is ever reached. The chain trace reveals repeating hops so you can break the cycle.
A 308 is a permanent redirect that, unlike a 301, requires the request method to stay unchanged. Like a 301 it indicates a permanent move, so signals should flow to the new URL.
No. It follows server-side HTTP redirects using status codes and Location headers. Client-side JavaScript redirects and browser-only navigation are out of scope, so those hops will not appear in the traced chain.
The Location header accompanies a 3xx response and names the URL to go to next. The checker reads it at each hop to build the ordered chain up to the final destination.