Introduction to Split URL Testing

Overview

Split URL Testing is the technique to test multiple variations of your website hosted on different URLs. Here, the website traffic is randomly split between the variations, and conversions are tracked to decide which variation performs the best. The variations that you create in a Split URL test are accessed via different URLs, and the performance of each is tracked and analyzed to identify which variation has a better conversion rate for your visitors.

It is recommended to use Split URL testing when you wish to make some significant design or backend changes [you can do backend changes using Wingify Feature Experimentation] on your website. Say you want to test a single page checkout flow vs. a multi-page flow or test a mega menu vs. a dropdown menu, then you can create a Split URL test and host these changes across different URLs to understand and act on the visitors’ behavior.

The above picture represents how two variations of the example.com domain are hosted on different URLs.

As a rule of thumb, Split URL testing is preferred when you wish to completely redesign each page of your website, while A/B testing is preferred when you want to test minor changes across your website.

Once the Split URL test declares a winner, you can further optimize and redesign your web pages by running an A/B test to test the smaller changes on your web pages.

When a split test is running and visitors land on the original website (the control), Wingify either keeps the visitors on the original URL or redirects them to the variation URL. This redirection is done using JS redirect and not by 302 redirects. This is because it helps notify your URL forwarding to the search engines (SEO) and even google guidelines suggest this.

Split URL testing helps you to:

1. Create and run multiple variations of your website on different URLs
2. Test different flows and complex changes such as a complete redesign of your website
3. Compare webpages hosted on different URLs
4. Test a completely new page

A/B Test vs. Split URL Test

The key difference between an A/B test and a Split URL test is that the variations are hosted on different URLs in the case of the Split URL.

In a typical A/B test, two similar versions with minor changes (as major changes in an A/B test means tests would take a longer time to load) are compared, whereas, in a Split URL test, major changes like redesign are done in the variations. They are then compared to the control version. To know more about A/B testing in Wingify, refer to A/B Testing.

Multivariate Test vs. Split URL Test 

In a Multivariate test, multiple elements on your webpage are modified at a time. Still, the difference between the variation and control is not major, whereas, in a Split URL test, major changes are done in a variation and are tested on different URLs. To know more about Multivariate testing in Wingify, refer to Multivariate Testing.

When Not to Use Split URL Testing?

It will help if you do not use Split URL testing when you want to test minor changes on your website, like change in the color of the CTA button or change any test change. To test such changes, it’s recommended to use the A/B testing method. This is because small changes are applied efficiently with an A/B test, whereas a redirect is introduced with the Split URL test.

Things to Consider While Working with Split URL Testing

• The control URL should be the one present on the site i.e. the users should land on the control URL and not the variation URL.
   
• If using a pattern, the variation pages corresponding to all control pages should exist, else it will return a 404 error.
   
• If the variation URL matches the control URL, there is a possibility of a user getting stuck in a loop if Wingify chooses to show him the variation. In that case, a variation URL should be explicitly excluded.
   
• While creating a split test for multiple pages that do not have a common pattern, a custom URL or negative regex option can be used.
   

• If the split test is integrated with GA:
  
  a. The control URL will have page views and sessions almost double the number of page views and sessions for variation.

   Note: To prevent this, you can employ the method suggested here so that the GA code is not executed twice, thus preventing the page visits and sessions from getting doubled.

  b. The variation URL will not have the traffic source information and will always show referral traffic.
  c. The bounce rate of the site may increase or decrease depending on whether the variation is on the same domain or a different domain.

• If Wingify SmartCode is not present on the variation URL, it will not track conversions but will still track visits.
   
• If there is any internal redirection on the control or variation URL, the split test will not work correctly.

• Wingify creates the _wingify_referrer cookie when visitors are redirected from the control to the variation page. This cookie stores the referrer URL to the control page, and can be used to identify the actual traffic source. For example, in the case of GTM, you can implement the code provided below.  

   Note: Apply this implementation only (and anywhere) on the variation page, where the user is redirected after entering the split test. This ensures that the original referrer (from the control page) is correctly captured and passed to your analytics system.
  • Accounts created before June 14, 2026
  • Accounts created on/after June 14, 2026

  window.VWO = window.VWO || [];
  window.VWO.push(['onVWOLoaded', () => {
     const orgReferrer = window.VWO.get("visitor.referrer");
     if (orgReferrer) {
        gtag('event', 'referrer_restored', {
           referrer: orgReferrer
         });
     }
  }]);

  window.Wingify = window.Wingify || [];
  window.Wingify.push(['onLibLoaded', () => {
      const orgReferrer = window.Wingify.get("visitor.referrer");
      if (orgReferrer) {
         gtag('event', 'referrer_restored', {
            referrer: orgReferrer
          });
      }
  }]);

   

• If your analytics or tracking setup does not use gtag, you can implement an equivalent custom logic to capture and forward this data to your tracking system.

  To implement custom tracking logic, replace the gtag('event', ...) call with your analytics provider’s event tracking method and pass correct values for event and referrer.