Netlify Split Testing: A/B Test Between Branch Deploys (2026)

Netlify Split Testing lets you route a percentage of your traffic to different branch deploys, effectively A/B testing entirely separate versions of your site.

Let’s see it in action. Imagine you have a main branch main with your stable production site. You also have a feature branch new-hero where you’ve redesigned your homepage’s hero section. You want to test if the new hero performs better before merging it into main.

Here’s how you’d set that up in Netlify:

1. Deploy Both Branches: Ensure both main and new-hero are deployed. Netlify automatically deploys branches pushed to your Git repository. You’ll have unique deploy URLs for each, like main--your-site.netlify.app and new-hero--your-site.netlify.app.

2. Configure Split Testing: Navigate to your Netlify site’s settings. Go to Deploys > Split testing.

   • Click Add split test.
   • Branch: Select your new-hero branch.
   • Traffic %: Enter 50. This means 50% of incoming traffic will go to this branch.
   • Publish: Click Publish.

   Now, your site is live at your-site.netlify.app. When a user visits, Netlify’s edge network randomly assigns them to either the main branch (the default, 100% traffic initially) or the new-hero branch (now receiving 50% of traffic). The remaining 50% of traffic continues to go to main.

   The crucial point is that your-site.netlify.app now acts as a single entry point, but the actual content served is dynamically determined by the split test configuration.

The problem this solves is the risk of deploying untested changes directly to production. Traditional A/B testing often involves modifying the same codebase and using feature flags or JavaScript to show different UI elements. Split Testing with branch deploys allows you to test completely independent deployments, meaning you can test vastly different UI, backend logic, or even entirely new frameworks without touching your main production branch.

Internally, Netlify’s edge network (powered by Akamai) intercepts incoming requests to your primary domain (your-site.netlify.app). Based on the traffic percentage configured in the split test, it forwards the request to the corresponding Netlify deploy. This routing happens at the CDN level, meaning it’s incredibly fast and doesn’t require any client-side JavaScript to determine which version to show.

The exact levers you control are:

• Branch: Which Git branch’s deploy will receive a portion of traffic.
• Traffic %: The percentage of new incoming traffic that will be routed to that specific branch. This percentage is relative to the remaining traffic. If you have main at 100% and add new-hero at 50%, main will receive 50% and new-hero will receive 50%. If you then add another branch experimental at 25%, main will get 75% (100 - 25), and new-hero will get 25% (50 - 25).
• Publish/Unpublish: Activating or deactivating a split test.
• Primary Deploy: The default branch that receives all traffic not allocated to other split tests.

One thing that often trips people up is how the percentages are calculated. If you have a primary deploy at 100% and add a split test for branch A at 50%, branch A gets 50% of traffic, and the primary deploy gets the remaining 50%. If you then add a split test for branch B at 25%, branch B gets 25% of the total traffic, and the primary deploy and branch A now share the remaining 75%. The percentages are not additive on the original 100%; they are allocated sequentially from the pool of available traffic.

The next concept you’ll likely want to explore is analyzing the results of your split tests using Netlify Analytics.