Deliverability
Redirect & UTM Inspector
Follows a link hop by hop and shows whether UTM and other tracking parameters survive to the final page.
- Runs on our server
- 2 units per run
- You enter
- A link, usually copied from a sent email.
- You get
- Every hop with its status and time, warnings, and the parameters lost or changed on the way.
- A good result
- A short chain ending in 200 with all UTM parameters intact.
On this page
#What it is for
Use it when campaign traffic is missing in analytics, when a link opens the wrong page, or to check a tracking link before a send.
#What you enter
One link. Without a scheme https:// is added. Only public http and https addresses are allowed.
#How it works
It requests the link without following redirects automatically, reads the Location header, and repeats up to 10 hops. Each hop is checked again against private addresses. Only the first 2 KB of each response is read.
Tracked parameters are every utm_* plus gclid, fbclid, mc_cid, mc_eid and ref. The first and last address are compared.
#Reading the results
- Verdict: "Redirect chain looks clean", "Chain works but has warnings" or "Chain ended with an error" (the last hop failed or returned 400 or more).
- Warnings: a loop, a timeout, a switch from HTTPS to HTTP, or stopping at 10 hops.
- Hop table: status, address, where it points next, server and time.
- Parameters: anything listed as "Lost or changed" will not reach analytics as sent.
#Example
https://track.example.com/f/a/xyz?utm_source=newsletter&utm_medium=email&utm_campaign=octoberA good result: the tracking domain redirects once or twice and the shop page receives all three UTM parameters.
#Limits and gotchas
- Each hop waits up to 5 seconds.
- Redirects done by JavaScript or a meta refresh on the page are not followed; only HTTP redirects are.
- Bare IP addresses and internal hosts are refused.