Growth Notes

Split URL Tests

Tags: experimentation web-dev concept

Split URL Tests

Date: 2026-08-17

Sending each arm to a genuinely different URL rather than modifying one page in place. It’s the right design for changes too large to apply client-side — and it drags in redirect latency, SEO handling and analytics attribution, none of which a standard A/B test has to think about.

A split URL test is an A/B test where each arm is served at a different URL, with visitors redirected or routed to their assigned one.

The shape, versus a normal test

STANDARD A/B                         SPLIT URL

/product/1234                        /product/1234          ← control
  ↓                                  /product/1234-v2       ← variant
assign, then modify the DOM
or render the variant server-side    assign, then REDIRECT

one URL                              two URLs
no extra request                     an extra round trip for the variant arm
flicker is the risk                  no flicker — the page is what it is

The two risks are a straight swap: in-place tests can show the original before the variant applies, split URL tests can’t — they pay a redirect instead — Flicker and Flash of Original Content.

Use it when the variant is a different page, not a different version of a page: a rebuilt checkout flow, a new template, a page on a different stack during a strangler migration. For a headline change it’s the wrong tool and the redirect costs more than the change is worth.

The four things that break

1. The redirect is a latency tax on one arm only.

control arm    request → 200 OK                        ~180ms
variant arm    request → 302 → request → 200 OK        ~180ms + 120ms = 300ms

This is a confound, not just a nuisance. The variant is now slower by construction, and page speed affects conversion — so a variant that would have won by 3% may read as flat, and the effect you measured is the design change minus the redirect penalty — Performance and Conversion.

Mitigations, best first:

  • Redirect server-side or at the edge, before any HTML is sent. Adds a few milliseconds rather than a full round trip — Edge Computing
  • Rewrite rather than redirect where the platform allows — serve different content at the same URL, which removes the problem entirely and makes it a normal server-side test
  • If you must redirect client-side, do it before render and accept that you’ve made the arms unequal. Measure the delta and report it as a caveat
  • Never redirect after the page has painted — that’s flicker plus latency plus a visible flash of the wrong page

2. Crawlers must not index the variant.

Two URLs serving near-identical content is duplicate content, and the variant can outrank or replace the control in the index — which outlives the test.

  • rel="canonical" on the variant pointing at the control. This is the primary control and the one Google’s own guidance has long centred on — Canonicalisation
  • Use a 302, not a 301. A 301 signals permanence and can cause the control URL to be replaced in the index. The test is temporary; say so — Redirects and Link Equity
  • Don’t block the variant in robots.txt. A blocked URL can’t be crawled, so the canonical tag can’t be read, which defeats the mechanism you’re relying on
  • Clean up afterwards. Losing variant URLs is how a site ends up with indexed ?v=2 pages years later — Site Migrations and SEO

3. Analytics splits the page into two.

Every report grouped by page path now shows two rows, and every historical comparison for the control URL breaks for the duration.

  • Send a consistent logical page name as a property, separate from the raw path, so funnels and page reports stay whole — Event Taxonomy Design
  • Check that the redirect doesn’t drop the referrer or the UTM parameters. It frequently does, which moves the variant arm’s traffic into direct and corrupts channel reporting — Direct Traffic and Lost Referrers, UTM Governance
  • Watch for session splits if the redirect crosses a domain or a cookie boundary

4. Assignment must be sticky across the redirect.

The user is assigned, redirected, and must stay assigned on every subsequent visit — including if they bookmark the variant URL or arrive at it directly. Deterministic hashing on a persistent identifier handles this; a random draw stored only in a session does not — Assignment and Bucketing.

Direct arrivals at the variant URL are a real pollution source. Someone shares the link, and now unassigned users are in the variant arm without having been randomised. Either redirect them back to be assigned properly, or exclude them — Sample Pollution.

The checks before launch

  • Both URLs return 200 and render fully, including on mobile and to logged-in users
  • The canonical is right on the variant, verified in the rendered HTML rather than in the template
  • The redirect preserves query strings — UTMs, gclid, and any parameter the page needs
  • Sample Ratio Mismatch watched closely. Split URL tests produce SRM more often than in-place tests, because the redirect is one more thing that can fail asymmetrically — blocked by an extension, timed out, cached wrongly
  • Cache behaviour. A CDN caching the redirect response can pin everyone to one arm — check Vary and cache keys before trusting the split — CDN Caching

Where it interacts

Graph View

Backlinks