Optimizely Redirect and Split-URL Experiments: When to Use a Full-Page Variant

Loading...·7 min read

TL;DR

Most Optimizely experiments rewrite part of a page in place. A redirect experiment does something categorically different: it sends a share of visitors to an entirely separate URL and compares the two pages as variations. That makes redirects the right tool when the treatment is genuinely a different page — two pre-built landing pages, two checkout flows, a rebuilt template — and the wrong tool for a headline or button tweak. It also changes the failure modes: a decision has to be made and preserved across a navigation boundary, some visitors vanish mid-redirect, and search-engine and analytics behavior need explicit handling. This guide covers when a split-URL test is the right shape, exactly how Optimizely executes it, and how to protect attribution, traffic counts, and SEO so you measure the page and not the plumbing.

A Redirect Experiment Is a Full-Page Comparison, Not a Cosmetic Tweak

Reach for a redirect when the variation would otherwise be a large rewrite or late-stage DOM surgery — comparing two distinct landing pages, two funnels, or an old template against a rebuilt one. In those cases the honest unit of comparison is the whole page, and trying to reproduce a "different page" with on-page JavaScript is slower, more fragile, and more flicker-prone than simply serving the other URL.

Do not use a redirect for minor text, layout, or CTA changes. Those belong in the Visual Editor as in-place variations, where analytics are simpler, there is no navigation to interrupt tracking, and QA is cleaner. If the change is local, keep it local. A redirect adds a navigation boundary, and every boundary is a place measurement can break.

How Optimizely Executes a Redirect

Understanding the execution order is what separates a clean redirect test from a mystifying one. In Web Experimentation you create one with Create > Redirect, then choose a URL destination (a static path) or a Code destination (a function returning a URL, for logic-driven redirects — more power, more QA burden).

The mechanics are specific and worth internalizing:

  • Your variation code runs before the redirect. Any JavaScript or CSS attached to the variation executes before the browser leaves the page. That ordering is what lets you log the exposure or set analytics state before navigation — but it also means slow variation code delays the redirect.

  • Optimizely calls window.location.replace immediately after the bucketing decision. The origin page does not fully load, no extra requests fire on it, and in-flight XHR requests are canceled by the browser. Because replace is used (not assign), the visitor cannot press Back to return to the original page.

  • The original body is hidden via CSS during the decision so the visitor does not see a flash of the origin page before navigating — the redirect equivalent of anti-flicker masking. (For the general version of that race, see how to prevent the A/B testing flicker effect.)

  • Keep the snippet as high in the <head> as possible. As with any Web Experimentation test, an early, synchronous snippet is what makes the decision — and therefore the redirect — happen before paint.

One direct consequence: do not use origin pageviews as a metric. The redirect deliberately races ahead of normal pageview tracking on the source page, so origin-page metrics are unreliable by design. Measure conversions on the destination instead.

Redirect, Performance Edge, or On-Page Editing?

Pick the delivery model from how much the page actually changes:

  • On-page editing when the variation is local — a component, a headline, a layout shift. Simplest analytics, no navigation risk, cleanest QA.

  • Redirect when page identity changes — two URLs, two templates, two distinct funnels. You accept a navigation boundary in exchange for comparing real, fully built pages.

  • Performance Edge when timing is critical but the change is still manageable on one page — its microsnippet decides at the edge with a smaller payload. Edge also supports redirects and can navigate quickly while preserving the decision for attribution.

flowchart TD
    A[Is the treatment a different page?] --> B{Yes}
    A -->|No| C[Use on-page variation]
    B --> D[Create redirect experiment]
    D --> E[Decision made on source page]
    E --> F[Variation code executes]
    F --> G[Browser redirects to destination URL]
    G --> H[Validate destination analytics and conversions]
    C --> I[Use visual or edge-based editing]

Protect Attribution and Traffic Counts

A redirect experiment is a valid experiment, but it introduces two measurement risks you must manage deliberately.

Expect slight traffic imbalance — it is usually not a broken test. Some visitors close the tab or window before the redirect finishes. When that happens, Optimizely's code never activates on the destination, the event data is never sent, and the visitor is never counted. That produces a small, real imbalance between variations. Distinguish this expected drop-off from a genuine allocation bug with a sample ratio mismatch check: a modest, stable skew consistent with redirect loss is different from a growing or large imbalance that signals a targeting or bucketing problem.

Preserve the pre-redirect decision across the boundary. Attribution depends on carrying the source-page decision to the destination. Optimizely's enhanced redirect analytics does this by storing the campaign decision in a cookie and reading it on the post-redirect page — but it works within a single cookie domain (and snippet-to-snippet within the same account); it does not support redirects from one cookie domain to another, and cross-domain redirects can lose tracking entirely. If you redirect to a page served by a different snippet, that snippet must have the same analytics integrations enabled, or the destination won't know about the experiment.

One more practical gap: on the destination, document.referrer is just the pre-redirect URL, which is rarely the referrer you care about. Capture the true original referrer before navigation and pass it to your analytics:

var redirectInfo = window.optimizely.get('state').getRedirectInfo();
var realReferrer = redirectInfo && redirectInfo.referrer;
// forward realReferrer to your third-party analytics on the destination page

Treat the destination as its own experiment surface: confirm its URL, cookies, analytics tags, and conversion events, and make sure it does not create duplicate decisions or duplicate events.

QA the Redirect End to End

A redirect has two paths, and both need testing:

  • Source → destination, the experiment path.

  • Direct load of the destination, plus refresh, Back button, and repeated entry — the ways real visitors arrive that you did not script.

Watch specifically for redirect loops and mismatched defaults. Optimizely blocks other redirects for 5 seconds after one fires to prevent an infinite loop, and you should exclude the redirect (destination) URL from the experiment's page targeting so the destination doesn't try to redirect again. Check that the control page isn't accidentally far slower or structurally different from the destination, which would confound the comparison. Validate analytics on the landing page directly: the decision event, the conversion event, referrer continuity, and any downstream integration payloads. Run this with the same rigor as any launch — the experiment QA checklist applies, with the destination page added as a second surface to verify.

Split-URL Testing and SEO

Because a redirect creates a second live URL, keep search-engine concerns explicit rather than buried in QA. A temporary experimentation redirect is not a permanent site migration, and the release plan should say which one it is.

The concrete safeguards Optimizely recommends: add a rel="canonical" link tag in the destination page's <head> pointing at the preferred URL, so search engines consolidate ranking signals rather than treating the variant as a competing page; optionally use a robots.txt disallow for URLs you don't want indexed; and remember that because Web Experimentation is client-side JavaScript, any indexing behavior ultimately follows the search engine's own rules for dynamic content. If the page is SEO-sensitive, treat the redirect as a governance decision: name who can launch it, who approves the destination, and who owns rollback.

Finally, plan duration against a shorter source-page dwell time — the redirect intentionally cuts time on the origin — using how long to run an A/B test, and remember that redirect tests frequently overlap with other experiments on the destination page, so review running multiple A/B tests at once before launch.

Launch Checklist for Redirect Experiments

  • The two URLs are intentional competitors, not accidental duplicates.

  • Variation code is confirmed to run before navigation, and it is light enough not to delay the redirect.

  • Origin pageviews are not used as a metric; destination conversions are.

  • Destination analytics, cookies, and event payloads are validated on the landing page.

  • Tested for redirect loops and failed navigation; the destination URL is excluded from targeting.

  • Enhanced redirect analytics is confirmed within one cookie domain (or cross-domain tracking is explicitly handled).

  • A rel="canonical" tag is in place and SEO risk is documented.

  • The team has agreed how it will interpret slight traffic imbalance versus a real SRM.

  • The rollback owner and stop condition are recorded.

A redirect experiment is one of the most powerful shapes in Optimizely — it lets you test genuinely different pages instead of approximating them — but it moves the hard part from building the variation to preserving measurement across a navigation boundary. Get the decision-before-navigation ordering, the attribution cookie, and the canonical tag right, and a split-URL test is as trustworthy as any on-page experiment.