A/B testing on WooCommerce: when a plugin is enough and when it isn't

On WooCommerce, an A/B testing plugin is enough when what you want to test is pages, posts or products you edit in WordPress and your site does not rely on aggressive caching. It stops being enough when you want to test the cart or the checkout, when the store is only fast thanks to WP Rocket or LiteSpeed Cache, or when you want a variant shown only to one campaign or only on mobile. In those cases a tool installed with a script works better. Here is how we decide, along with the failures we see most often.

WordPress has a plugin for almost everything, A/B testing included. The best known is Nelio A/B Testing, which has been in the official directory for years. The general idea behind these plugins is sound: you create an alternative version of a page, post, product or headline from the WordPress dashboard, pick a goal and the plugin splits the visits.

What they have going for them:

• Everything lives in WordPress. No other account, no other dashboard. You edit the variant in the block editor or the page builder you already use (Elementor, Divi).
• They understand WordPress content. They know what a post, a product or a menu is, which makes it easy to test things like two descriptions of the same product.
• Installing means installing a plugin. If you can install one, you can install this one.

What to check first:

• One more plugin. Every plugin adds queries, scripts and chances of conflict. On a store with 40 plugins, the next one is the one that breaks something in an update.
• What it covers in the checkout. Testing a page is easy. Testing the WooCommerce cart or checkout, which are filled with session data and in recent versions are blocks rendered with JavaScript, is another matter. Check exactly what the plugin covers before counting on it.
• Price. Many of these plugins have a limited free version and paid plans based on traffic. Check their site, because it changes often.

The alternative is an external tool installed by pasting a script into the site's <head>: by hand in a child theme, with a "header and footer code" plugin, or through Google Tag Manager. The tool does not touch WordPress. It applies changes in the visitor's browser, on top of the page WooCommerce has already generated.

That is what we do at Bixlow. On the plus side:

• Any part of the page. Product page, cart, checkout, mini cart, header. If it shows up in the browser, it can be changed.
• No dependence on your WordPress version or page builder. An Elementor update does not break your tests.
• Targeting comes naturally. You can show a variant only to people arriving from an Instagram campaign, only on mobile, or only to people who have visited before.

On the minus side: it is another tool and another account, and changes made there are not WordPress content. If a variant wins, someone has to move the change into the theme or keep serving it from the tool.

This is where most stores get stuck, and it is the main reason we usually recommend the script on WooCommerce.

A WooCommerce store without caching is slow, so nearly all of them use WP Rocket, LiteSpeed Cache, W3 Total Cache or the host's cache. These tools store the generated page and serve the same copy to everyone. If the test picks the variant on the server, in PHP, the cache keeps the first version generated and hands it to everybody. The test stops being a test.

Serious plugins know this and assign the variant with JavaScript, or ask you to exclude pages from the cache. Check how the one you choose handles it. 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.

Even so, three cache settings affect any testing script:

1. Delay JavaScript execution. WP Rocket has an option that delays scripts until the user interacts (moving the mouse, scrolling, touching the screen). LiteSpeed Cache has something similar. If the testing script is delayed, the variant is not applied until the visitor interacts and the change shows up late. Add the script to the exclusions.
2. Combine and minify JS. If the cache merges all scripts into one file, it can change the order or break the script. Exclude it from combining as well.
3. Defer JS loading. Deferring all JavaScript is good for speed, but the testing script needs to load at the top and as early as possible. Exclude it.

Then clear the plugin cache, the host cache and Cloudflare if you use it, and check in a private window.

When an order completes on WooCommerce, the customer lands on the order-received endpoint of the checkout page, usually something like /checkout/order-received/1234/?key=.... That URL is the best goal for a store test.

If you take payment through a hosted card gateway or PayPal, the customer pays elsewhere and comes back to that page. Anyone who closes the tab at the gateway does not come back and is not counted, equally in both variants. And if you already have a plugin that sends the purchase event to the dataLayer for GA4, you can use it as the goal.

Our rule is simple. If everything you plan to test is content pages and you want it all inside WordPress, try a plugin. If what you want to test is the store itself (product page, cart, checkout, shipping), use a script.

The doubts are the same as on any store, with a few WooCommerce details:

• Shipping cost on the product page. WooCommerce does not show it there by default, only in the cart. Putting "Shipping €4.95, free over €50" next to the price answers the question before the customer has to go looking.
• The threshold in the cart. "You're €12 away from free shipping" in the cart and the mini cart.
• Payment methods before checkout. Card, PayPal and any local wallet icons under the add to cart button.
• Checkout fields. The default checkout asks for quite a lot (company, second address line). Hiding the optional ones or labelling them clearly is an easy test.
• Guest checkout. If you force account creation, try not requiring it, or offering it after payment.

Before publishing any of them, place a complete test order with each variant, on mobile. The block checkout redraws sections when you change shipping method, and that is where bugs show up.

To get an idea of how long you will need, the sample size calculator works it out from your traffic and conversion rate. In Bixlow, the agent proposes the hypothesis and builds the variant on the live store, you review it in preview and nothing goes live without your approval. The verdict comes from Bayesian statistics: there is no winner until a variant has at least a 95% probability of being the best and a minimum sample and duration are met. If you want a variant shown only to one kind of visitor, that is set up with audiences.

Does Bixlow have a WordPress plugin? No. It installs with a script in the head or through Google Tag Manager, the same as on any other site.

Can I use a plugin and a script at the same time? You can, but do not test the same thing with both, or on the same page at the same time. Two tests touching the same element contaminate each other.

Does a test affect SEO? A short test that changes copy or elements in the browser rarely causes trouble. Do not show Google something different from what your customers see, and do not leave forgotten tests running for months.

What if I run Cloudflare in front of WordPress? It behaves like any page cache: the script is served to everyone and the variant is decided in the browser. Purge after installing.