Redirect Checker

Follow a URL through every 301, 302 and 308 it meets, and see where the chain actually ends.

Secure server processingWeb & SEOWorkingNo account needed

What this tool does

Redirect Checker hands your URL to the OmniKitly service, which requests it with automatic redirect following switched off so that each step is taken deliberately. The service reads the status line and the Location header, resolves a relative Location against the URL it has just asked for, re-checks the resulting address, and issues the next request itself. The result is a table, one row per hop, with the status, the Location it pointed at, and a note explaining what that status means for search or for a browser — a 302 that should have been a 301, a hop with no Location at all, a chain long enough to be worth flattening. The hop count includes the request that ended the chain, so one 301 landing on a page that answers 200 is reported as two hops, not one.

Reading a hop chain is how two reasonable decisions turn out to have become four requests. A host that upgrades http to https, a rule that adds www, a CMS that appends a trailing slash and a marketing tool that rewrites the path each add a hop, and none of the people who added them can see the others. Every hop is a round trip a visitor waits through, and a 302 sitting where a 301 was intended keeps the old address alive indefinitely, because a temporary redirect tells crawlers to hold on to the URL they started from.

The requests come from the service, not from your browser, and that changes what the trace can see. They carry the OmniKitly/1.0 user agent, no cookies — none are sent, and none set by one hop are carried into the next — and no referrer, and they originate from the server's own IP address, so a site that redirects by country, by device or by whether you are signed in answers that visitor rather than you. Only HTTP status redirects are followed: 301, 302, 303, 307 and 308. Nothing here renders or executes the page, so a meta refresh or a JavaScript assignment to location arrives as a 200 and reads as the end of the chain.

Three limits are worth knowing before you trust a result. The Maximum hops setting genuinely controls the ceiling — 1 to 20, ten by default — and a chain longer than that abandons the run with "That URL redirected too many times" rather than being named as a loop; the report itself does check for a URL repeating within the chain it did complete, and flags that as a loop when it finds one. Addresses that resolve to private, loopback, carrier-NAT or link-local ranges are refused at every hop, so an intranet or a laptop staging server cannot be traced. And no file is uploaded: the URL travels to the service over an encrypted connection as a job setting, where it is held in the job record until that record and the underlying JSON report are deleted together, six hours after the run by default.

How to use it

  1. Enter the URL to trace. One address per run, with the scheme written out. The service parses the string strictly, so example.com on its own is rejected as an invalid URL where https://example.com is accepted. The text you type is sent as the job's url setting, and it is the service, not the page, that turns down anything malformed or non-http.
  2. Set the hop ceiling if the default is not enough. It offers 1 to 20 and starts at 10. A chain that exceeds it ends the run with "That URL redirected too many times" rather than a report, so raise it before tracing a site you already suspect has an unusually long chain.
  3. Read the chain in order. Each row names the URL that was requested, the status it returned, the Location header it pointed at, and a short note on what that status means. A summary line above the table gives the final destination and its status in one line, and lists any problem the whole chain shows — a scheme downgrade partway through, a hop that revisits an earlier URL, or a chain long enough that it is worth collapsing into one redirect.
  4. Act on what the ordering shows. An http hop before the https one, a 302 on a move that is permanent, or three requests where one rule would do are all visible as separate entries rather than as a single destination.

Processing & privacy

Secure server processing. This operation requires temporary server processing.

Common use cases

Checking a site migration

Old addresses should reach their new ones in a single 301 — two entries in the chain, no more. A longer list says the request is being passed along a queue of rules instead.

Untangling a canonical mismatch

The http, non-www and trailing-slash variants of one page often each add a hop. Tracing them shows which normalisation runs first and which one is redundant.

Auditing a shortened or tagged link

A tracking link can pass through two or three intermediaries before the landing page. The chain names every host it touches, including any that were not meant to be in the path.

Confirming a redirect is permanent

A 302 left in place after a permanent move keeps signals attached to the old URL. The status column shows which code is actually being served, rather than which one was configured.

Questions

Is my URL sent anywhere?
Yes. The trace runs on the OmniKitly processing service, so the address travels there over an encrypted connection as a job setting and is stored in the job record while the job exists. The service makes each request from its own IP, and the record and the JSON report are removed together when the retention window ends, six hours after the run by default. The URL is the only thing that leaves the page; there is no file to upload.
Why does the trace stop before it reaches the end?
It has hit the Maximum hops setting — 10 by default, adjustable to 20. A sixth request past that ceiling answers "That URL redirected too many times" instead of completing, so a chain ending this way is either genuinely long or circular, and raising the setting is the way to see past it if the site really does need more hops.
Does the Maximum hops setting do anything?
Yes. It accepts 1 to 20 and is sent with the job; the service uses it as the real ceiling on how many redirects it will follow before giving up. Ten is the default, which is enough for almost every real chain — raise it only for a site you already know redirects an unusual number of times.
Does it follow a meta refresh or a JavaScript redirect?
No. Only the HTTP status redirects — 301, 302, 303, 307 and 308 — are followed, because the page is never rendered or executed. A meta refresh comes back as a 200 and looks like the end of the chain. That is worth knowing in itself: crawlers follow those far less predictably than a server-side 301, and the extra page load is paid by every visitor.
Will I see the redirects a real visitor sees?
Not necessarily. The request carries the OmniKitly/1.0 user agent, no cookies and no referrer, and it comes from the server's IP address. Geo-targeted, device-targeted and login-dependent rules will answer that request on its own terms, so treat the result as one visitor's view rather than everyone's.
Can I trace a URL on my own network?
No. Hostnames that resolve to private, loopback or link-local addresses are rejected, as are names ending .local, .internal, .localhost, .lan or .home and URLs carrying a username and password. Every hop is re-checked, so a public URL that redirects to an internal one stops at that point.
What happens to a relative Location header?
It is resolved against the URL that returned it, exactly as a browser would, and the absolute address is what appears in the chain and in the next request.
What if a redirect has no Location header?
The trace ends there. That hop becomes the last entry, and its 3xx code is reported as the final status — which is itself the finding, because a browser given a redirect with nowhere to go has nothing to do either.
Does the report include the page it ends on?
No. Only the first kilobyte of the final response is read, and it is discarded rather than returned, so you get status codes and addresses and no page content. Use HTTP Header Inspector or Canonical Checker when the destination itself is the question.
How long will it wait for a slow site?
Each hop is given fifteen seconds to respond and the whole job is cut off at twenty-five, so a long chain of slow answers can run out of time before it reaches the end. There is no retry setting; running it again is the only option.

Related tools