How to Run a PostHog A/B Test on WordPress

Running an A/B test on WordPress with PostHog is possible, but the setup needs more care than a simple tracking snippet.

PostHog experiments run through feature flags. WordPress pages, especially builder-based pages like Divi, render content before your experiment logic has finished loading. If the control and test modules are not prepared correctly, visitors can see the wrong version, see both versions, or create experiment data that is hard to trust.

This guide shows the practical workflow we use: duplicate the page, create the PostHog experiment, build the WordPress variants, hide test modules by default, use the PostHog feature flag response to show the right version, QA each variant, then launch the experiment with a clear primary metric.

By the end, you should have a WordPress A/B test that is easier to validate and cleaner to analyze in PostHog.

What You Need Before You Start

Before you build the experiment, make sure these pieces are already in place:

• A working PostHog project.
• PostHog installed on the WordPress site. If not, follow this PostHog installation guide for WordPress to set it up quickly.
• Access to the WordPress page you want to test.
• Permission to edit the page template or builder modules.
• A clear test hypothesis.
• A conversion event or funnel in PostHog that can be used as the primary metric.
• The exact page, section, or module you want to change.

If PostHog is not installed yet, install it first. The experiment code in this guide assumes the global posthog object is available on the page before the variant script runs.

Decide What You Are Testing

Do not start by duplicating random modules. Start with the experiment question.

For example:

• Does a clearer hero headline increase form visits?
• Does a shorter CTA section increase button clicks?
• Does changing the webinar framing improve opt-ins?
• Does replacing a pricing block reduce drop-off?

Keep the first version of the test narrow. If you change the headline, CTA, layout, and pricing copy at the same time, PostHog may tell you which variant won, but it will not tell you why.

A clean test plan should include:

• The page being tested.
• The control version.
• The test variant or variants.
• The primary conversion event.
• The expected business outcome.

Example:

We are testing whether a more specific above-the-fold headline increases visits to the lead form on the About page.

Step 1: Duplicate the WordPress Page

In WordPress, duplicate the page you want to test before editing anything.

In the WordPress dashboard:

1. Go to Pages.
2. Find the page you want to test.
3. Duplicate it using your normal page duplication tool, such as Yoast Duplicate Post or another approved duplicate-page plugin.
4. Rename the copied page so it is easy to identify, such as About Page - PostHog Test.
5. Keep the copied page unpublished, password-protected, or otherwise hidden until QA is complete.

This protects the live page while you build the experiment. It also gives you a clean space to prepare the control and test modules without disrupting real visitors.

Step 2: Create the Experiment in PostHog

PostHog experiments use feature flags behind the scenes. That feature flag is what your WordPress page will read to decide which module to show.

In PostHog:

1. Open Experiments.
2. Click New experiment.
3. Add a clear experiment name.
4. Set the feature flag key.
5. Add your control and test variants.
6. Save the experiment as a draft.

Use a naming format that stays readable later:

[Experiment number] - [Funnel step or page] - [Test hypothesis]

Example:

001 - About page - Heading clarity test

For the feature flag key, use a code-friendly version:

001-about-page-heading-test

Keep variant keys short and predictable:

control
test_group_1
test_group_2

The feature flag key matters because it must match exactly in your WordPress script. A typo in the key is enough to make every visitor fall back to the wrong version.

Step 3: Create the Variant Modules in WordPress

Now build the content variants on the duplicated WordPress page.

If you are using Divi Builder, open the duplicated page and find the module or section you want to test. Duplicate that module once for each test variant.

For a three-way test, you might have:

• Control: the original module.
• TG1: the first test version.
• TG2: the second test version.

Each module should contain only the change you want to test. If the test is about a heading, keep the surrounding layout, spacing, buttons, and form behavior the same.

Step 4: Give Each Variant a Unique CSS ID

Your script needs stable selectors so it can hide and show the correct module.

In Divi:

1. Open the module settings.
2. Go to Advanced.
3. Open CSS ID & Classes.
4. Add a unique CSS ID.

Example IDs:

experiment-control
experiment-tg1
experiment-tg2

Use IDs that describe the experiment, not the design. Avoid IDs like blue-heading or new-copy, because they become confusing once the test changes or gets reused.

Step 5: Hide Test Variants by Default

The test variants should be hidden before the PostHog flag response is available. This reduces the chance that visitors briefly see the wrong version while the page is loading.

In Divi:

1. Open the settings for each test-group module.
2. Go to Advanced.
3. Open Custom CSS.
4. In Main Element, add:

display: none;

Apply this to the test variants, such as TG1 and TG2.

You can leave the control visible by default if you want a safe fallback. The script below hides all variants once the flag is ready, then shows the assigned version.

If you are not using Divi, add display: none; to the test variant elements through your builder, theme CSS, or custom CSS field.

Step 6: Add the PostHog Variant Script

Add the script near the bottom of the duplicated page, preferably in a code module placed just above the footer or in a page-specific script area.

Update these values before publishing:

• featureFlagKey
• control
• test_group_1
• test_group_2
• The CSS selectors for each module

This script waits for PostHog feature flags before checking the assigned variant. PostHog recommends using onFeatureFlags when you need to make sure flags have loaded before using them on the page.

The call to getFeatureFlag() is also important because experiments use feature flags. Reading the flag tells the page which variant applies to the visitor.

Step 7: QA the Variants Before Launch

Do not launch the experiment until every variant has been checked on the page.

At minimum, test:

• Control renders correctly.
• Each test variant renders correctly.
• Only one version is visible at a time.
• Mobile layout works.
• Tablet layout works.
• Desktop layout works.
• The conversion action still works.
• PostHog receives pageview and conversion events.
• The feature flag is being evaluated.

To manually force a variant during QA, use the browser console after PostHog has loaded:

posthog.featureFlags.overrideFeatureFlags({
flags: {
'001-about-page-heading-test': 'test_group_1'
}
});
posthog.reloadFeatureFlags();

Then refresh and check the page. Repeat for each variant.

If your site already has custom URL-based override logic, you can also test with a URL parameter. Do not rely on URL parameters unless that override behavior has been explicitly implemented or confirmed on your site.

Step 8: Set the Primary Metric in PostHog

Before launching, choose the metric that decides whether the test worked.

For a WordPress landing page, the primary metric is usually one of these:

• Form visit.
• Form submit.
• CTA click.
• Checkout visit.
• Purchase.
• Lead created.
• Booking completed.

In PostHog:

1. Open the draft experiment.
2. Go to Primary metrics.
3. Click Add primary metric.
4. Choose the metric type.
5. Configure the event or funnel.
6. Set the attribution type and conversion window.
7. Save the metric.

A common setup is a funnel such as:

Feature flag called -> Form visit

or:

Feature flag called -> Form submit

Use the conversion action that best matches the business decision. If the test changes a hero heading, a form visit may be useful. If the test changes pricing or offer framing, a form submit, purchase, or qualified lead event is usually better.

Step 9: Launch the Experiment

Once the variants and metric are confirmed:

1. Open the experiment in PostHog.
2. Confirm the traffic split.
3. Confirm all variants are active.
4. Confirm the primary metric is saved.
5. Click Launch.

After launch, check PostHog events in real time. You should see page activity, feature flag calls, and the conversion event you selected for the experiment.

Step 10: Move the Tested Page Into Production

Once the duplicated page is fully tested, decide how it should go live.

The safest approach depends on your WordPress setup:

• If the duplicated page should replace the original, update URLs carefully so the live URL points to the tested page.
• If the test is only inside a module on the existing live page, copy the prepared modules and script into the live page.
• If SEO rankings matter for the page, avoid changing canonical URLs without checking the broader SEO setup.

Before making the live URL switch, record:

• Original page URL.
• Test page URL.
• Experiment feature flag key.
• Variant keys.
• Primary metric.
• Launch date.
• Any page or template changes made.

This makes the experiment easier to debug later if data looks strange.

How to Verify the Setup in PostHog

After the experiment is live, verify the data instead of assuming the setup worked.

Check these areas:

• Activity: confirm visitor events are arriving.
• Feature flag calls: confirm the experiment flag is being evaluated.
• Experiment results: confirm users are being assigned to variants.
• Funnels: confirm the primary conversion event appears after the flag call.
• Session recordings: review a few sessions to check visual behavior.

Success looks like this:

• Visitors see one version of the tested section.
• The same visitor keeps the same assigned variant.
• The primary metric receives events.
• Experiment results begin populating in PostHog.
• There are no obvious layout shifts or broken modules.

Common Mistakes to Avoid

Using the wrong feature flag key

The feature flag key in WordPress must match the PostHog experiment exactly. Even one different character can break the assignment logic.

Showing variants before flags load

If all modules are visible by default, visitors may see content flash or multiple variants. Hide test variants by default and wait for feature flags before switching modules.

Testing too many changes at once

A/B testing is most useful when the change is isolated. If you change several major elements in one variant, the result becomes harder to interpret.

Forgetting mobile QA

WordPress builder modules often behave differently across breakpoints. Check mobile and tablet before launch.

Choosing a weak primary metric

A click can be useful, but it may not prove business impact. When possible, use the closest reliable conversion event to the outcome you care about.

Publishing before PostHog events are verified

Do not wait until the end of the experiment to discover the metric was not firing. Verify events immediately after launch.

Changing variants during the experiment

Avoid editing the tested content mid-experiment unless there is a clear bug. Changing a variant after launch can make the result harder to trust.

Why This Matters for CRO

A WordPress A/B test is only useful if the assignment, display logic, and conversion tracking are clean.

PostHog can help you measure which variant performs better, but it cannot fix a messy implementation. If visitors see the wrong module, if conversion events are missing, or if the metric does not match the business goal, the experiment result becomes less useful.

The value of this setup is not just that a different heading or CTA appears. The value is that the experiment creates decision-quality data:

• Which version did visitors see?
• What did they do next?
• Did the change improve the conversion path?
• Is the result strong enough to keep, iterate, or reject?

That is the difference between running a visual test and running a CRO experiment.

Frequently asked questions

External & Internal References

• PostHog installation guide for WordPress
• PostHog experiment naming guidelines
• Best ways to install PostHog on WordPress
• PostHog Experiments documentation
• PostHog JavaScript feature flags and experiments documentation