A/B testing in Webflow with PostHog, without pretending the dashboard is the strategy

A/B testing in Webflow sounds like it should be simple. Change a headline, split the traffic, see which one wins.

In practice, I think the hard part is usually not the code. The hard part is keeping the test honest. You need a real hypothesis, a clean way to assign variants, and events that tell you what happened after the click. Otherwise you are just changing copy and calling it data-driven because there is a dashboard nearby.

PostHog is a nice fit for this kind of thing because the pieces live close together: analytics, feature flags, experiments, session replay, and the actual events you care about. Webflow is still Webflow, so you are probably adding this through custom code instead of some beautiful productized experiment layer, but that is fine. For a small startup site, this is often enough.

Start with the thing you are actually trying to learn

Do not start with "button color test." Start with a question.

Something like: "Do people understand the product faster if the hero is framed around the problem instead of the feature?" That is a useful test. You can write two versions of the same section, send half of visitors to each one, and measure the next step: demo click, signup, waitlist join, pricing click, whatever actually matters for the page.

That last part is important. If your test only measures headline clicks, you can accidentally optimize for the loudest version of the page instead of the version that brings in better users.

Put PostHog on the site first

In Webflow, the PostHog snippet usually belongs in site-level custom code so it loads across the site. If you are only testing one landing page, page-level custom code works too. The main thing is that PostHog needs to load before your experiment code tries to read a flag.

Use the normal PostHog install snippet from your project settings. Then create a feature flag in PostHog for the experiment. I like naming these in plain language, because six months from now homepage-hero-problem-vs-feature will make a lot more sense than test-2b.

Use a feature flag to choose the variant

Here is the basic shape I would use for a Webflow page. It waits for PostHog feature flags, reads the variant, changes the hero copy, and captures an exposure event with the variant attached.

<script>
window.addEventListener('load', function () {
  if (!window.posthog) return;

  posthog.onFeatureFlags(function () {
    const variant =
      posthog.getFeatureFlag('homepage-hero-problem-vs-feature') || 'control';

    const headline = document.querySelector('[data-exp="hero-headline"]');
    const subhead = document.querySelector('[data-exp="hero-subhead"]');

    if (variant === 'problem-led') {
      if (headline) headline.textContent = 'Know what your users are doing before you rebuild the page';
      if (subhead) subhead.textContent = 'A practical analytics setup for startup teams that need signal, not another reporting ritual.';
    }

    posthog.capture('experiment viewed', {
      experiment: 'homepage_hero_problem_vs_feature',
      variant: variant
    });
  });
});
</script>

In Webflow, I would add those data-exp attributes to the headline and subhead in the Designer. That keeps the JavaScript boring, which is what you want. The more your experiment code knows about Webflow's generated class names, the more brittle it gets.

Also, do not use posthog.featureFlags.override() for the live test. That is useful for QA, but it defeats the point of letting PostHog assign visitors to variants.

Track the conversion you actually care about

The exposure event tells you who saw the test. The conversion event tells you whether the test mattered.

For a marketing page, I would usually track the obvious next action explicitly. Autocapture can be useful, but I do not like relying on it for the one event that decides whether the experiment worked.

<script>
window.addEventListener('load', function () {
  if (!window.posthog) return;

  document.querySelectorAll('[data-track="primary-cta"]').forEach(function (button) {
    button.addEventListener('click', function () {
      posthog.capture('primary cta clicked', {
        location: button.getAttribute('data-location') || 'unknown'
      });
    });
  });
});
</script>

Then add data-track="primary-cta" to the button in Webflow. If there are multiple buttons on the page, add data-location="hero", data-location="pricing", or whatever helps you read the results later without opening the Designer and playing detective.

The Webflow-specific stuff that can make this weird

Client-side tests can flicker. The original Webflow content loads, PostHog gets the flag, then JavaScript swaps the copy. For a small headline test, that may be acceptable. For a big layout change, it can feel broken.

My rule of thumb: test copy, ordering, CTAs, and small section-level changes this way. Do not use this setup to rebuild the whole page after load. If the variant needs a totally different layout, make a dedicated page or build the experiment somewhere with more control.

You also need to remember that ad blockers and privacy tools can block analytics scripts. That does not make the test useless, but it does mean the numbers are never as pure as the dashboard makes them feel. Treat the result as a decision aid, not a court ruling.

A small checklist before calling the test real

Before I would trust the result, I would check a few things:

The flag is assigning visitors the way I expect. The exposure event fires once the variant is known. The conversion event is explicit. The event names are boring and readable. The page does not visibly jump in a way that changes user behavior. The test has enough traffic to be worth reading.

That is not a lot of ceremony. It is just enough structure to keep the experiment from becoming a vibes machine with nicer charts.

Why I like this setup

I like this because it is practical. A lot of early-stage teams do not need an enterprise experimentation platform. They need to stop guessing which message is working, and they need the answer to live next to the rest of their product data.

PostHog gives you the flag and the measurement layer. Webflow gives you the speed to change the surface. The job is making sure the thing you are measuring is actually connected to the business question you started with.

For now, that is the version I would reach for: a small, honest experiment system that helps the site learn without turning the whole thing into a lab project.

‍