How to run an A/B test on WordPress (without breaking the cache)

To run an A/B test on WordPress you have three routes: a plugin such as Nelio A/B Testing, an external tool installed with a script in the <head>, or that same tool loaded through Google Tag Manager. On a services or lead generation site, what usually fails is not the tool but the cache: WP Rocket, LiteSpeed Cache or your host's cache delays or bundles the script, and the test shows up late or not at all. The fix is to exclude the script from those optimisations, measure the real form submission (not the click on "Send") and start with the form or the main button on your landing page. Here is how, step by step.

This guide is for WordPress sites without a store: a clinic, an accountancy firm, a renovation company, a blog that lives on email sign-ups. If you run WooCommerce, read A/B testing on WooCommerce: when a plugin is enough and when it isn't instead.

For years the easy answer was Google Optimize. It was free and installed next to Analytics. Google shut it down on 30 September 2023, and plenty of small sites were left with no way to test anything. If someone recommends Optimize on a forum, it is an old thread.

WordPress has nothing built in for testing. So you have to choose.

Nelio A/B Testing is the best known A/B testing plugin in the official directory. According to its WordPress.org listing, it relies on Nelio's cloud services, has a free version limited to 500 tested page views a month at the time of writing, and is "designed to work with popular WordPress caching solutions", while warning that you should check your setup if you cache full pages or combine and delay JavaScript. On the plus side, you edit everything from WordPress, with Gutenberg, Elementor or whatever you use. Prices are on its website, and they change.

A script-based tool does not touch WordPress. It applies changes in the visitor's browser, on top of the page WordPress has already generated. Theme, page builder and version do not matter. That is how Bixlow works: one script, and from then on the agent proposes hypotheses and builds the variants on your live site. Nothing goes live until you approve it.

GTM is the same tool, loaded from Tag Manager. Handy if you already have GTM, but it loads a little later than a script pasted straight into the head.

My rule: if everything you want to test is pages you already edit with your page builder and you want to stay inside WordPress, try a plugin. If you want to test the form, the header, the WhatsApp button, or show something different to people arriving from an ad, use a script.

Pick one of these and do not mix them.

1. With an "insert code in header" plugin. There are several, WPCode is one of the best known. You paste the script into the header box and it loads on every page. It is the simplest route if you would rather not touch code, and it survives theme updates.

2. From a child theme's functions.php. If you have a child theme, add a function hooked to wp_head with an early priority so it prints near the top:

   add_action( 'wp_head', function () {
     echo '<script src="SCRIPT-URL"></script>';
   }, 1 );
   

   Do not do it in the parent theme: the next update will wipe your change.

3. With Google Tag Manager. If GTM is already on the site (via Site Kit, a plugin or by hand), create a Custom HTML tag that fires on all pages.

Then check that it loads. Open the site in a private window, look for the script in the page source or the network tab, and do it on the homepage, a landing page and a blog post.

Almost every WordPress site uses some kind of cache, because without it they are slow. And almost every "the test isn't showing" comes from here. There are two separate problems.

The first: page caching. WP Rocket, LiteSpeed Cache, W3 Total Cache, your host's cache or Cloudflare store the generated page and serve the same copy to everyone. If a tool decides the variant on the server, the cache stores the first version and serves it to everyone. A script-based tool does not have that problem: the cached page is the same for everyone and the variant is decided in the browser. With a plugin, check how it assigns the variant.

The second: JavaScript optimisations. This one affects any testing script:

1. Delaying JavaScript. WP Rocket has "Delay JavaScript execution": scripts do not load until the user moves the mouse, touches the screen or scrolls. If your testing script is delayed, the variant appears late. Add it to the Excluded JavaScript Files field, or put the nowprocket attribute on the tag. In LiteSpeed Cache, if "Load JS Deferred" is set to "Delayed", add the script to "JS Deferred/Delayed Excludes".
2. Combining and minifying. If the cache bundles every script into one, it can change the order or break yours. Exclude it from combining too.
3. Deferring. Deferring JavaScript is good for speed, but the testing script has to load at the top. Exclude it.

Then clear the plugin's cache, your host's and Cloudflare's if you use it. One more thing people forget: if your cookie banner blocks scripts until the visitor accepts, check which category yours ended up in.

On a services site the goal is almost always for someone to write to you or call you. Picture a physiotherapy clinic in Valencia with a "first appointment" landing page. This is what I would test, roughly in this order:

• The form. If it asks for name, email, phone, company, region and message, try cutting it down to name, phone and "what's wrong?". Every extra field is a reason to close the tab.
• The button copy. "Send" says nothing. "Book your first appointment" or "Call me back" says what happens when you click.
• What happens next. A line under the button like "We'll call you today before 8 pm" removes the doubt about whether anyone reads the message.
• Phone or WhatsApp visible on mobile. Many people on a phone would rather call than fill anything in.
• The top of the landing page. A headline that says what you do and for whom, instead of a stock photo with "Your health, our priority".

If you only want people arriving from your Google Ads campaign, or only mobile visitors, to see the change, that is done by audience, without touching the page for everyone else.

With little traffic, test big changes. The sample size calculator tells you how long it will take with your numbers.

The classic mistake is measuring the click on "Send". That click also counts people who got a field wrong and left. What you want is the successful submission. There are two ways.

1. The thank you page. If the form redirects to /thank-you after submitting, create the goal by URL. It is the most reliable option and needs no code.

2. The form plugin's event. If the form submits without reloading (AJAX), each plugin fires its own JavaScript event when the submission succeeds:

• Contact Form 7: wpcf7mailsent, when the submission has completed and the mail has been sent.
• Gravity Forms: gform_confirmation_loaded, on AJAX forms when the confirmation message is displayed.
• WPForms: wpformsAjaxSubmitSuccess, on forms with AJAX enabled.

Listen for that event and tell the tool. In Bixlow you can push an event to the dataLayer and use it as the goal, or call window.bixlow.track directly:

document.addEventListener('wpcf7mailsent', function () {
  window.bixlow && window.bixlow.track('form_submitted');
});

Submit a test entry with each variant before publishing and check that the goal is counted.

Does Bixlow have a WordPress plugin? No. It is installed with a script in the head or through Google Tag Manager, as on any website.

Does an A/B test hurt SEO? A short test that changes copy or elements in the browser rarely causes problems. Do not show Google something different from what your visitors see, and do not leave forgotten tests running for months.

What if my site is on WordPress.com? It depends on the plan: on some you cannot install plugins or paste code into the header. Check before choosing a tool.

How much does it cost with Bixlow? The free plan analyses your site and proposes hypotheses, but does not run tests. A/B tests start on the Standard plan, at €24.17 a month billed yearly.