A/B Testing on Webflow: Tools, Setup and What to Test First

Why A/B test a Webflow site at all

Opinions about websites are cheap. Everyone in the room has a favourite headline. An A/B test replaces the argument with data: half of the visitors see version A, half see version B, and you compare what they did.

Webflow suits this well, because changing a page and publishing a variant does not need a developer queue. But the tool is the easy part. Most failed tests fail on method: no clear goal, too little traffic, a test stopped too early.

This guide covers the tools, the basic statistics, what to test first on SaaS and B2B sites and the pitfalls. For a full project story, read the Oscilar case study.

Webflow Optimize vs third-party tools

Webflow Optimize (native)

According to Webflow's announcement, Webflow Optimize covers A/B testing, for example of headlines, images, CTAs and content formats, and no-code personalisation for audience segments. Its main advantage is that it lives in the platform your site is already built in, so there is no extra script vendor and fewer moving parts. I have not listed pricing or plan requirements here, because they change and secondary sources disagree. Check Webflow's current pricing page before you plan a budget.

Third-party options

• Optibase is an app built for A/B testing on Webflow, described in its own guide. It is a vendor source, so read it as such.
• PostHog publishes a tutorial for A/B tests in Webflow based on feature flags and product analytics. A good fit if you already use PostHog.
• VWO, AB Tasty and Optimizely are the tools Google points to after it shut down Google Optimize. Google's help page says Optimize was sunset on 30 September 2023.

How I would choose

• Small team, simple tests: start with the native tool or a lightweight Webflow app.
• Product analytics already in place: use the experimentation feature of that tool, so goals and data live in one place.
• Many sites, many teams, strict governance: an enterprise platform may be worth the cost.

Whatever you pick, check four things before you commit: how variants are served (flicker risk), how goals are tracked, how traffic is split and whether it works with your cookie consent setup.

Setup before the first test

I follow the same sequence every time.

1. Pick one primary metric tied to revenue: demo requests, trial sign-ups, qualified leads. Not page views.
2. Record the baseline and the date. Without it you cannot prove an improvement later.
3. Set up the conversion event and test it. Submit the form yourself and confirm the event arrives in your analytics. Broken tracking is the most common reason a test result is useless.
4. Write a hypothesis: "Visitors do not understand what we do above the fold, so a more specific headline will increase demo requests."
5. Calculate the sample size (next section) and decide the test length in advance.
6. Build the variant in Webflow, check every breakpoint and every main browser, then QA the test itself: does the split work, does each variant fire the goal?
7. Define who is in the test. All visitors, or only new visitors? Desktop and mobile together? Exclude internal traffic.
8. Keep a log: date, hypothesis, variants, result, decision.

Sample size and test duration in plain words

You need three inputs to know how long a test must run:

• Baseline conversion rate, for example 2%.
• Minimum detectable effect: the smallest improvement worth caring about, for example a relative lift of 20%.
• Confidence level, commonly 95%, and statistical power, commonly 80%.

Put those into a calculator such as Evan Miller's sample size calculator. It tells you how many visitors each variant needs. The lower the baseline and the smaller the effect you want to detect, the more visitors you need. That is the maths behind a rule of thumb: small tweaks need big traffic.

Practical rules

• Decide the sample size before you start, and do not stop earlier.
• Run full weeks, so weekday and weekend behaviour both count. Many B2B sites behave differently on Mondays than on Fridays.
• Do not run tests for ever either. If the calculator says you need six months of traffic, the test is not realistic. Make the change bigger, or test a higher-traffic page, or test earlier in the funnel.
• A flat result is a result. It tells you the element does not matter much, and you can move on.

What to test first on SaaS and B2B sites

Order tests by two things: how many visitors see the element, and how close it is to the conversion. These are hypotheses to test on your site, not guarantees.

1. Homepage headline and sub-headline. Specific outcome versus vague slogan. It reaches every visitor.
2. Primary CTA. Wording ("Book a demo" versus "See it in action"), placement and what happens after the click.
3. Demo or contact form. Fewer fields, a clearer promise of what happens next, and where the form sits on the page.
4. Social proof placement. Customer logos, quotes and results next to the CTA instead of further down.
5. Hero format. Product screenshot versus abstract illustration, short video versus static image.
6. Pricing page layout, once the main path works.
7. Navigation. One clear CTA button in the header, fewer distracting links.

Test one change at a time, and change the message before the colour. Button colour tests are popular because they are easy, not because they are where conversion is lost. If you want to find the biggest obstacle first, look at recordings and drop-off points before you design a variant.

Pitfalls: flicker, peeking and others

Flicker

Some client-side tools load the original page first and swap in the variant after a script runs. Visitors briefly see the original, which looks broken and can bias the result. Reduce it by testing how the tool serves variants on a slow connection, keeping the test script early in the page and choosing a tool whose approach suits your pages. A test result on a flickering page is partly a result about the flicker.

Peeking

Checking results daily and stopping when a variant is "winning" inflates false positives. Evan Miller explains the problem in How Not To Run an A/B Test. Fix the sample size first, or use a tool that uses sequential methods designed for continuous monitoring, and say which one in your report.

Other traps

• Testing too many things at once, so you cannot say what worked.
• Ignoring mobile. A variant that wins on desktop can lose on phones. Segment the results, but do not slice so thin that the segments have no data.
• Tracking broken on one variant. Always QA both.
• Seasonality and campaigns. A paid campaign starting mid-test changes who visits.
• Slow pages. Performance is part of the experience, so keep variants as light as the original.
• Cookie consent. If visitors who decline tracking are not counted, check that this does not skew one variant.

My take: process beats tools

On Oscilar, a fraud-prevention SaaS, the redesign was tested iteratively and the demo request rate went from 1.2% to 3.7% in four months. Session duration rose by 35% and bounce rate fell by 20%. I would not claim any single test did that. It came from a redesign combined with testing, and the full story is in the Oscilar A/B testing case study and on the Oscilar project page.

What I take from it for agencies: the tool matters less than the discipline. One metric, one hypothesis per test, a sample size decided up front and a log of what you learned. That also makes a good retainer report for clients.

I build in Webflow and work with agencies on a white-label basis, so a variant is usually quick to build and QA across breakpoints. If you want to plan a testing programme for your own or a client's site, get in touch. For the launch side of things, see the Webflow SEO checklist.

FAQ

Written byPeter CekanakDesigner & Webflow developer · white-label partner for agencies

I design and build Webflow sites for agencies and startups since 2018 — Client-First, GSAP, CMS and AI automations. Sites I built helped a client to a $10M exit and tripled demo requests for a SaaS.

Webflow Certified ExpertRelume ExpertClient-First