You set up a redirect, open the old URL, and the new page loads. Job done?
Not quite. A redirect can land on the right page and still be wrong. It might use a temporary 302 instead of a 301, bounce through three addresses, or drop your tracking parameters on the way.
None of that shows up when you just click a link. You need to look at what happens in between.
What you’re actually checking
A good redirect test answers four questions:
What status code does it return? 301, 302, 307 or 308.
How many hops does it take? Ideally one.
Where does it finally land? And is that the page you intended?
Does it work from every entry point?
http://,https://, with and withoutwww.
The fastest way: a redirect tester
Paste the URL into our free redirect tester. It follows the whole chain and shows every hop, its status code, and the final destination.
It also tries to identify where each redirect is configured, for example Cloudflare, Vercel or Framer. That helps when you’re not sure which system is responsible.
Use the Both option to test http:// and https:// in one go. That’s where many registrar redirects quietly fail.
Testing from the command line
If you prefer the terminal, curl shows the raw response:
curl -I https://oldbrand.com/pricing
Look for the status line, such as HTTP/2 301, and the location header, which shows where it points.
To follow the whole chain, add -L:
curl -IL https://oldbrand.com/pricing
Each block in the output is one hop.
Testing in the browser
Browsers hide redirects by design, but the developer tools still record them.
Open the developer tools and go to the Network tab.
Turn on Preserve log, so the history isn’t cleared on redirect.
Visit the old URL.
Look at the first requests. Each redirect shows its status code and a location.
Always do this in a private window. Browsers cache permanent redirects, so a normal window may show you an old result. Our post on browser caching explains why.
What a good result looks like
For a permanent move, you want something like:
https://oldbrand.com/pricing → 301 → https://newbrand.com/pricing → 200
One redirect, a permanent status code, and a final page that loads with 200 OK.
Common problems a test reveals
A 302 where you meant 301. Search engines treat the old URL as the one that counts. Change the rule type.
A redirect chain. For example
http → https → www → new domain. Each extra hop adds delay. Google’s guidance is to avoid chains and keep them short where you can’t. See redirect chains.A loop. The redirect points back to itself, directly or via another hop. Browsers stop with
ERR_TOO_MANY_REDIRECTS.https doesn’t work at all. The redirect works on
http://but nothttps://, usually because nothing serves a certificate for the old domain.Lost query strings.
?utm_source=newsletterdisappears on the way, which breaks campaign tracking.A soft landing on the homepage. Every old URL ends up on the same page instead of its equivalent.
Test more than one URL
One URL is never the whole story. Before a launch, check a sample that covers each type of rule:
the homepage of the old domain
one or two of your most visited old pages
a URL that should be caught by a wildcard
a URL that should fall through to your catch-all rule
the
wwwversion of each
That catches most mistakes before visitors or search engines do.
Two hops can be normal
If you use Redirect Supply, you may see www redirect to the bare domain first, then your rule run. That’s intentional, so one domain stays canonical. Our www troubleshooting doc explains it.
Reading response headers
The status code isn’t the only useful thing in a redirect response. A few headers tell you more:
locationshows exactly where the redirect points, including any query string.serverand other platform headers often reveal which system sent the redirect, such as Cloudflare, Vercel or Framer.cache-controlshows whether browsers are allowed to cache it, and for how long.strict-transport-securityshows whether the domain uses HSTS, which forces future visits ontohttps://.
Our redirect tester shows these headers for each hop under Details, so you don’t need the terminal to read them.
Test the query string too
If you run campaigns, test a URL with tracking parameters:
https://oldbrand.com/pricing?utm_source=newsletter
Check that the parameters arrive at the destination. If they’re dropped, your analytics will show the traffic as direct instead of coming from the newsletter.
Keep testing after launch
Redirects can break later, for example when someone changes DNS or a destination page is removed. Re-test your key URLs after any DNS change, and every few months for important domains.
