A redirect test sends each group to a different URL. It is the right shape when you have two pages that already exist and genuinely differ — a long-form lander against a product page, a new collection against the old one, a rebuilt page against the one it replaces.
It is the wrong shape for small differences. If the two pages are nearly the same, you pay for a navigation on every variant visit to measure something a content or template test would answer without one. The figures below are live: one follows a shopper through four visits, the other shows what a redirect does to a test sharing its page.
The origin is the setup
Give the control group the URL visitors actually arrive at. That one field does two jobs: it makes the control the group that stays put, and it defines where the test runs. The Targeting tab shows it as the test’s page rather than letting you set a second, disagreeing one.
Every other group gets a destination. Browse picks a real product, collection or page; a full URL or a path both work. On a store with language subfolders, a French shopper sent to /pages/spring-long lands on /fr/pages/spring-long, not in the default language.
A redirect test with no origin is refused. Everywhere else in this app an empty URL rule means “every page”. For a redirect it would mean every page of your store — home, products, cart — sending visitors to one variant URL, and the store stops working. So Start will not allow it, and the loader would not do it even if asked.
One shopper, four visits
A redirect only fires on the origin. What happens there depends on the visitor’s group and on one setting for the whole test.
- Visit 1 · Taps an Instagram ad
/pages/spring?utm_source=instagram&utm_campaign=spring#reviewsPage hidden until the new one loads→ /pages/spring-long?utm_source=instagram&utm_campaign=spring#reviewsSent, with every parameter carried across.
Sent 1 time in 1 visit.
Always: every landing on the origin sends them, with whatever parameters they arrived on.
↳ Parameters and the anchor ride along
Step through the default, a variant visitor on Always. The ad click on /pages/spring?utm_source=instagram&utm_campaign=spring#reviews lands on /pages/spring-long with both parameters and the #reviews anchor intact. The product page is left alone. Going back to the spring page sends them again, and so does next week’s newsletter link — four visits, three hops.
Switch to Once and the same four visits make one hop. Switch the visitor to the control and they make none.
Your ad attribution survives
Query parameters are carried across, so your analytics and your ad platform still see the campaign that brought the visitor. A parameter the destination names itself wins. This is not politeness: a redirect test that dropped them would break attribution for half your paid traffic for as long as it ran.
Once, or every time
A setting on the test rather than on a group: one arm redirecting once while another redirects every time would give the two different numbers of chances to convert. Changing it on a running test starts a new run, for the same reason.
- Always
- Every landing on the origin sends them. Right for a campaign page people come back to.
- Once
- The first landing sends them; after that, a shopper who navigates back to the origin is allowed to stay. It is remembered per visitor, not per tab, so a new tab or a new week does not reset it. A browser that blocks storage gets Always.
No flash of the origin
The page stays hidden until the destination loads, so a variant visitor never glimpses the page they are leaving. The hop replaces the origin in their history, so Back does not bounce them through it again.
Keep it on your own store
A destination on another domain is allowed — sending half your traffic to another site you own is a legitimate split test. But our cookie does not follow, so an order placed there cannot be attributed to the group that sent it. The test reports visitors and no revenue, which reads like a bug and is physics. Check setup flags any destination that leaves your store for exactly this reason.
Sharing a page with another test
Two navigating tests on the same pages are refused. Theme, template and redirect tests all move the visitor, and two of them on overlapping URLs cannot both act.
A redirect and a content or styles test on the same page are allowed, with a warning. The content test buckets the visitor and counts them; then the redirect takes them away before they see either version.
A +10.0% win reads as +5.0%.
Dragged toward “no difference” in proportion to the redirect’s share, and a smaller effect needs far more traffic to call. The app warns about this overlap; it does not refuse it.
↳ Redirected visitors drag the other test to zero
At the defaults, a headline that really lifts conversion by 10%, on a page where the redirect sends half the visitors away, reports +5.0%. Half its visitors added the same nothing to both of its groups. And a 5% effect needs roughly four times the traffic of a 10% one to call.
The redirect doesn’t break the other test. It quietly halves it.
What to watch
- Paste each destination into a private window first. A URL that redirects again on Shopify’s side sends the visitor somewhere neither group was measuring. Check setup, on the Preview tab, does the same for every group: it flags a 404, a destination that sends visitors back to a page the test runs on, and one that leaves your store.
- Every variant visit costs a navigation. The control does not pay it. That asymmetry is real but small, and it is why the page stays hidden across the hop rather than letting the origin paint first.
When it wins
Set the redirect up properly in Shopify — Online Store, Navigation, URL Redirects — and end the test. A real redirect is a server-side 301: faster for the shopper, understood by search engines, and not dependent on our script running.