Pre-Launch Redirect Test
Paste your old URLs and get a verdict on each one: what it returns, whether a redirect fired, and where it lands. Free, no signup.
Redirects rot quietly after a launch: a rule gets edited, a plugin rewrites the file, a CDN rule takes over. Sitewell can re-check your most important old URL on a schedule and tell you when it stops landing.
The usual launch-day advice is to pick ten old URLs and follow them in a browser after go-live. That finds the worst breakage and misses everything else, and it finds it after the traffic has already hit the wall. This test takes the whole list instead — every old URL that earns clicks — and tells you which ones reach a live page, which ones die, and which ones get there the long way round.
Check your old URLs before you flip the switch
Three steps, and the whole thing takes about ten minutes once you have the list.
- 01
Collect the old URLs
Export the pages that already earn something: Search Console, the old sitemap, an analytics landing-page report. One URL per line, up to 1,000 per run.
- 02
Point them at the build you are testing
If the new site is live, paste the old URLs as they are. If it is still on staging, swap the hostname for the staging host and keep every path and query string exactly as it was.
- 03
Read the verdict column
Fix everything marked fail, re-run the list, and keep it. You will run the same list again in the hour after DNS moves.
The host swap in step two is the part people get wrong. Keep the path and the query string byte for byte, because that is what your rules match on. Change example.com/blog/2019/post to staging.example.com/blog/2019/post and nothing else.
What a pre-launch redirect test actually catches
Four failures show up on nearly every launch. None of them are visible in the redirect rules file, which is why reading the rules is not the same as testing them.
The URLs nobody mapped
Redirect maps get written from the site's navigation, so they cover the pages people remember. The ones that get missed are the ones nobody looks at any more: a campaign landing page from two years ago, a PDF someone linked from a forum, an old blog post that still ranks. A test built from a traffic export finds them because the list came from what visitors actually request rather than from the sitemap of the new site.
Rules that fire in the wrong order
Redirect rules are evaluated top down and the first match wins. Put a broad /blog/* catch-all above the per-post mappings and every post lands on the blog index instead of its new URL. Both rules are correct on their own; the order is what is wrong. In the results this is unmistakable: dozens of different old URLs, all landing on the same final URL.
Chains stacked by a staging domain
A rule that hardcodes the production hostname sends a staging request off the build you are testing and back to the live site, so one move becomes staging host, then old production URL, then new production URL. Two of those hops are artifacts of testing on staging. The third is the one that survives launch, and the only way to tell them apart is to look at the final URL on each row.
Old URLs pointing at pages that 404 on the new build
The map was written against the planned structure, then the structure changed during the build: a slug got shortened, a category was merged, a template moved under a different path. The redirect still fires and still returns a clean 301, and it hands the visitor a 404. Reviewing the rules file never catches this, because the rule is right. Only requesting the URL and reading the status at the end of the chain does.
Where to get the list of old URLs
The test is only as good as the list, and the list should describe the old site as visitors and crawlers actually use it. Four sources, in the order I would pull them:
- Search Console. Performance report, Pages tab, date range set to the last 12 months, then export. It arrives sorted by clicks, so the top of the file is exactly what you cannot afford to break. The web interface caps the export at 1,000 rows, which happens to be one run here.
- The old sitemap. Download /sitemap.xml from the old site and save the file now, while the old site still exists. After DNS moves it is gone, and rebuilding that list from memory is miserable.
- Analytics landing pages. Last 12 months, every landing page with more than a handful of sessions. This picks up URLs Search Console never shows you: entry points from email, social, QR codes and old ad campaigns that get no impressions in organic search.
- A crawl. Run a crawler over the old site while it is still up. It finds what the other three miss — paginated archives, tag pages, files, and the pages that are linked internally but get no traffic at all.
Merge the four, dedupe, and strip tracking parameters like utm_source — keep any query string that genuinely changes which page is served. If the merged list runs past 1,000, sort by clicks and test in batches from the top.
Reading the verdict column
Each row gets one of four verdicts. The rule behind them is deliberately strict, because launch day is the wrong time to be generous about what counts as working.
| Verdict | When you get it | What to do |
|---|---|---|
| pass | A redirect fired and the URL landed on 200 within two hops. | Nothing. Collapse two hops to one if it is easy. |
| fail | 404, 410, a 5xx, any other non-200 ending, or three or more hops. | Fix before you switch DNS. Trace the URL to see which hop breaks. |
| no redirect | The URL answered on its own. No rule matched it. | Fine if you kept that URL. A problem if you meant to move it. |
| unreachable | Nothing answered: timeout, DNS failure, or a private host. | Usually staging on an internal network. Test it from inside. |
Two verdicts need a note. A no redirect row is only good news if you intended to keep that URL unchanged. If you restructured the site and the old URL still answers 200, the old build is still serving it, and you are very likely testing the wrong host. And a deliberate 410 on a page you retired on purpose is marked fail here, because the checker cannot tell an intentional 410 from an accidental one. Keep a short list of the URLs you meant to kill and skip those rows.
The summary line counts something slightly different from the verdict: it counts URLs that end on a 200, including the ones that fail on hop count. A four-hop chain does reach a real page. It still needs flattening, and the redirect chain checker will show you which rule to rewrite.
Test again the hour after you go live
A clean staging run is evidence, not a guarantee. Production has layers staging does not: a CDN in front of the origin, environment-specific config, redirect rules gated behind a production flag, a WAF that answers some requests itself. Any of those can turn a passing rule into a failing one at the moment it matters.
Caching adds the second half of the problem. Resolvers keep your old DNS answer for the length of the TTL you set before the move, so for that window some visitors and some crawlers are still being handed the old server while you look at the new one. Edge caches do the same thing one layer up, and a 404 or a 502 served during the switchover can sit in the cache long after the origin is healthy.
So run the same list twice more. Once inside the first hour, which catches the production-only rules. Once after the longest TTL you set has expired, which catches what the caches were holding. If a URL keeps failing in production while the origin serves it correctly, purge the edge cache for that path and test it again before you go looking for a broken rule.
Frequently asked questions
- How do I test redirects before launching a site?
- Start from a real list of old URLs rather than the redirect map, because the map only contains what somebody remembered. Export the pages that already get traffic from Search Console or analytics, then request each one against the build you are launching and record three things: the status it ends on, how many hops it took, and the URL it landed on. That is what this tool does in bulk. If the new site is not live yet, swap the hostname in your list for the staging host and leave the paths untouched, so the same rules fire on the same paths.
- Can I test redirects on staging?
- Yes, and it is the right time to catch most problems. The caveat is that staging is rarely an exact copy of production. Redirect rules often live in environment-specific config, some are loaded only when a production flag is set, and the CDN or edge layer that sits in front of the live site usually has no equivalent in front of staging. Rules can also hardcode the production hostname, which sends a staging request off to the old live site and adds hops that will not exist after launch. Treat a clean staging run as a good sign, not as proof, and run the same list again once the site is live.
- How many old URLs should I test?
- Test every URL that earns something. In practice that means the pages with clicks or impressions in the last twelve months, plus anything with links pointing at it, which is usually a few hundred URLs on a small site and a few thousand on a large one. This tool takes 1,000 per run. If your list is longer, sort by clicks and work down it in batches — the top of that list is where a broken redirect costs real traffic, and the long tail can be checked after launch.
- What if an old URL has no equivalent on the new site?
- You have two honest options. Redirect it to the closest relevant page — the parent category, the replacement product, the section the article belonged to — or return 410 Gone and let it drop out of the index. What you should not do is send everything with no match to the homepage. Google treats a redirect to an irrelevant page as a soft 404, so the URL loses whatever signal it had anyway, and the visitor who wanted one specific page gets dropped at the front door and leaves. A blanket homepage rule also hides the problem: every unmapped URL returns 200 and the test passes while the traffic quietly disappears.
- How long after launch should I re-check?
- Run the list once within the first hour, then again after your longest DNS TTL has expired. The first run catches rules that behaved differently in production. The second catches the visitors and crawlers still being sent to the old server by cached DNS answers. If a CDN sits in front of the site, check that it has not cached an error response from the minutes around the switch — purge and re-run if the same URL keeps failing while it works on the origin.
- What is a good redirect test result?
- Every URL that mattered lands on a 200, and it gets there in one hop. Two hops is acceptable when a protocol or host rule is layered on top of a path rule, though it is still worth collapsing. A good result also has no surprises in the not-redirected group: any old URL still answering directly should be one you deliberately kept. Zero fails is the target before you switch DNS, not something to fix in the week after.
- Does this work for a domain migration?
- Yes, and a domain move is where the test earns the most, because hops stack up fast. Test the old URLs on the old domain in all the forms people actually use: http and https, www and bare host. A migration commonly turns one move into three redirects — protocol, then host, then path — and this test fails anything at three hops or more for exactly that reason. Fix it by having the first rule emit the final https URL on the new domain in one jump.