Run A\/B tests on WordPress pages or on HTML landings you've imported \u2014 including the ones your AI tool just generated. Drop a .html (or a .zip with CSS\/JS\/images) into wp-admin \u2192 A\/B Tests \u2192 Import HTML; Variolab renders the page byte-perfect with zero WordPress wrapper, then runs a real 50\/50 cookie-split test against any existing page on your site. Claude, v0, Lovable, Cursor, bolt.new exports all work out of the box.<\/p>\n\n
The classic two-page path works too: point the plugin at two existing pages \u2014 one as the control (Variant A), one as the variant (Variant B). Visitors are split 50\/50 via a persistent cookie; once assigned, they always see the same variant.<\/p>\n\n
Tracking is fully internal: impressions and conversions land in a custom database table, and the wp-admin dashboard shows conversion rates, lift, and a basic statistical significance indicator (two-proportion z-test).<\/p>\n\n
Security-audited internally before every release (situated checklist + OWASP grid). See SECURITY.md on GitHub for the disclosure policy and the latest audit report ( A\/B testing breaks under page caching: the first variant served gets cached for everyone, all subsequent visitors get that same response, the 50\/50 split dies. The plugin handles most cases automatically.<\/p>\n\n Kinsta uses a two-layer cache (nginx server-cache + Cloudflare Enterprise edge cache). The plugin's no-store headers bypass both \u2014 but for 100% safety, also add your test URLs to MyKinsta \u2192 Tools \u2192 Cache \u2192 Cache Bypass<\/strong> as URL Patterns (e.g. Verify it works by inspecting headers on your test URL:<\/p>\n\n Look for For W3 Total Cache, WP Super Cache, WP Fastest Cache, and Cache Enabler \u2014 the plugin shows a notice but does not automatically exclude URLs (no clean public API). Manually add your test URLs to that plugin's cache exclusion list.<\/p>\n\n Pull stats programmatically from external tools (n8n, Make, Pipedream, dashboards).<\/p>\n\n Optional query params:<\/p>\n\n Example:<\/p>\n\n The response includes for each experiment: id, title, test_url, status, dates, control\/variant IDs, goal, and a stats block with A\/B impressions\/conversions\/rate, lift, p-value, significance, and 95% confidence interval bounds for both lift and absolute difference.<\/p>\n\n The plugin stores no raw IP, no User-Agent, no email, no name, and no cross-site tracking identifier. The events table contains: experiment_id, variant, test_url, event_type, created_at, and a A native WordPress privacy guide snippet is registered automatically \u2014 find it under Settings \u2192 Privacy \u2192 Policy Guide \u2192 Variolab \u2013 A\/B Testing to paste into your privacy policy.<\/p>\n\n For consent-banner sites: enable \"Require consent\" in the plugin settings and wire your banner to the Right to erasure: because no reversible identifier is stored, individual deletion isn't possible. Use This plugin connects to one external service, only when the site administrator opts in<\/strong> through the plugin's Settings \u2192 Google Analytics 4 panel by entering a Measurement ID and API Secret. With the GA4 integration disabled (default), no data leaves your site.<\/p>\n\n What it is and what it's used for: when the GA4 integration is enabled, the plugin forwards A\/B-test impression and conversion events to Google Analytics 4 via the Measurement Protocol, so the test results can be analyzed alongside your existing GA4 reports.<\/p>\n\n What data is sent and when: on each impression and each conversion logged by the plugin, a single fire-and-forget HTTPS request is sent to No raw IP address, User-Agent string, email, name, WordPress user ID, or page content is sent.<\/p>\n\n Service provided by Google. Please review their terms and policies before enabling the integration:<\/p>\n\n On their first visit to the control page, a cookie No. Logged-in users with Always use the Update<\/strong> action \u2014 Plugins \u2192 Installed Plugins \u2192 Update, or v1 only swaps the entire page (the variant must be a separate post). Block-level and product-level testing are on the roadmap.<\/p><\/dd>\n A\/B test pages must never be served from a cache. A cached page freezes one variant for every visitor (breaking the 50\/50 split) and skips impression logging \u2014 so conversions get dropped. The plugin already sends docs\/security\/latest.md<\/code>).<\/p>\n\nFeatures<\/h4>\n\n
\n
abtest_event_logged<\/code> action hook ready for v2 GA4\/webhook integrations<\/li>\n<\/ul>\n\nCaching<\/h3>\n\n
What the plugin does automatically<\/h4>\n\n
\n
Cache-Control: no-store<\/code> headers<\/strong> on every page response under A\/B test. Respected by Cloudflare, Varnish, Kinsta edge cache, nginx page cache, and most server-level caches.<\/li>\nrocket_cache_reject_uri<\/code> filter<\/strong> when WP Rocket is detected \u2014 your test URLs are auto-added to the never-cache list.<\/li>\nlitespeed_force_nocache_url<\/code> filter<\/strong> when LiteSpeed is detected \u2014 same idea.<\/li>\nHosting on Kinsta<\/h4>\n\n
^\/promo\/$<\/code>). After publishing a new test, purge the Kinsta cache<\/strong> to flush any version cached before the experiment started.<\/p>\n\ncurl -I https:\/\/yoursite.com\/promo\/\n<\/code><\/pre>\n\nX-Kinsta-Cache: BYPASS<\/code> (or MISS<\/code>). If you see HIT<\/code>, you're getting the cached version and the split is broken \u2014 purge the cache.<\/p>\n\nHosting on other CDNs \/ hosts<\/h4>\n\n
\n
curl -I<\/code> looking for cf-cache-status: BYPASS<\/code> or DYNAMIC<\/code>.<\/li>\nPlugins not auto-supported<\/h4>\n\n
REST API<\/h3>\n\n
\n
GET \/wp-json\/abtest\/v1\/stats<\/code><\/li>\nmanage_options<\/code>.<\/li>\n\n
url=\/promo\/<\/code> \u2014 filter to a single test URL.<\/li>\nexperiment_id=38<\/code> \u2014 fetch a single experiment by ID.<\/li>\nstatus=running|paused|ended|draft<\/code> \u2014 filter by status.<\/li>\nfrom=YYYY-MM-DD&to=YYYY-MM-DD<\/code> \u2014 restrict event date range for the stats computation.<\/li>\nbreakdown=daily<\/code> \u2014 include per-day time series (for charting).<\/li>\n<\/ul>\n\ncurl -u 'admin:xxxx xxxx xxxx xxxx xxxx xxxx' 'https:\/\/yoursite.com\/wp-json\/abtest\/v1\/stats?status=running'\n<\/code><\/pre>\n\nPrivacy<\/h3>\n\n
visitor_hash<\/code> = first 16 hex chars (64 bits) of sha256(IP + UA + wp_salt('auth'))<\/code> \u2014 non-reversible, single-site, salt-rotated, dedup-safe. Cookies are httponly, samesite=Lax, secure on HTTPS, value = a single letter (a\/b\/c\/d), 30-day TTL.<\/p>\n\nabtest_visitor_has_consent<\/code> filter (return true to track, false\/null to block). Snippets for Complianz, CookieYes, and Cookiebot are in the README on GitHub.<\/p>\n\nTRUNCATE wp_abtest_events<\/code> to erase all A\/B testing data.<\/p>\n\nExternal services<\/h3>\n\n
Google Analytics 4 (Measurement Protocol)<\/h4>\n\n
https:\/\/www.google-analytics.com\/mp\/collect<\/code> with a JSON payload containing:<\/p>\n\n\n
client_id<\/code> \u2014 the plugin's internal visitor hash (truncated salted SHA-256 of IP + User-Agent; never the raw IP or UA)<\/li>\nevents[].name<\/code> \u2014 abtest_impression<\/code> or abtest_conversion<\/code><\/li>\nevents[].params.experiment_id<\/code> \u2014 the WordPress post ID of the experiment<\/li>\nevents[].params.variant<\/code> \u2014 the variant served (a<\/code>, b<\/code>, c<\/code>, or d<\/code>)<\/li>\nevents[].params.test_url<\/code> \u2014 the URL path under test (e.g. \/promo\/<\/code>)<\/li>\n<\/ul>\n\n\n
\n
\/wp-content\/plugins\/<\/code>.<\/li>\n\n
How is a visitor assigned to a variant?<\/h3><\/dt>\n
abtest_{experiment_id}<\/code> is set with value a<\/code> or b<\/code>. Subsequent visits read that cookie \u2014 the visitor always sees the same variant.<\/p><\/dd>\nWill admins see the test?<\/h3><\/dt>\n
edit_posts<\/code> capability are bypassed and always see the control. The admin bar shows a marker indicating which experiment is running on the page.<\/p><\/dd>\nHow do I upgrade without losing my experiments and stats?<\/h3><\/dt>\n
wp plugin update variolab-ab-testing<\/code> on the command line. Do not<\/strong> delete the plugin to reinstall a newer copy: deleting runs the uninstaller. As of v0.18.0 the uninstaller keeps your data by default (so an accidental delete no longer wipes your experiments, stats, page-import records, or settings), but the Update action is still the correct, cleanest way to upgrade. If you ever do want a full clean removal that erases everything, tick Delete all data on uninstall<\/strong> in Settings \u2192 Data & uninstall before<\/em> deleting the plugin.<\/p><\/dd>\nDoes it work with WooCommerce \/ Gutenberg blocks?<\/h3><\/dt>\n
My conversions aren't recorded \/ I use a CDN or a cache (Cloudflare, Cloudways, SiteGround, Kinsta, WP Rocket\u2026)<\/h3><\/dt>\n
no-store<\/code> headers and auto-excludes test URLs from WP Rocket and LiteSpeed, but server-level and edge caches it can't control (Cloudways\/Varnish, generic nginx caches, Cloudflare APO) may still cache the page. Two options:<\/p>\n\n\n
\/lp\/\u2026<\/code>) so one rule covers all of them. Step-by-step guidance for your host is shown in Settings \u2192 Caching & CDN<\/strong>.<\/li>\nnoindex<\/code> on those pages if SEO matters).<\/li>\n<\/ol><\/dd>\n\n<\/dl>\n\n\n0.20.1<\/h4>\n\n
\n
hsFormCallback<\/code> window message, but the current HubSpot embed (Forms V4) doesn't broadcast it \u2014 it dispatches a DOM event (hs-form-event:on-submission:success<\/code>) instead, so submissions weren't being counted. The tracker now listens for the V4 event (and still supports the legacy message for older embeds), reads the form GUID via HubSpot's getFormFromEvent<\/code> API when present, and records the conversion. If you used a HubSpot goal on 0.20.0, this is the fix that makes it fire.<\/li>\n<\/ul>\n\n0.20.0<\/h4>\n\n
\n
hsFormCallback<\/code> message HubSpot posts to the page \u2014 the same hook Google Analytics \/ GTM use), verifies it really comes from a HubSpot origin, and records the conversion. Leave the goal value empty to count any HubSpot form submission on the test page, or paste a HubSpot form GUID to count only that specific form. When you preview a running test as a logged-in admin, the browser console logs each HubSpot event so you can confirm the wiring with one test submission.<\/li>\n<\/ul>\n\n0.19.0<\/h4>\n\n
\n
0.18.0<\/h4>\n\n
\n
wp plugin update<\/code>); only delete when you really want the plugin gone. A new Settings \u2192 Data & uninstall<\/strong> section explains this and offers an opt-in \"Delete all data on uninstall\" checkbox (off by default) for when you want a clean removal that erases everything.<\/li>\n<\/ul>\n\n0.17.1<\/h4>\n\n
\n
0.17.0<\/h4>\n\n
\n
0.16.0<\/h4>\n\n
\n
?_abtcb=\u2026<\/code> redirect when you can't edit your cache rules. The admin cache notice now also detects Cloudflare and points to both options. (Default off; recommended fix remains a proper cache exclusion.)<\/li>\n<\/ul>\n\n0.15.11<\/h4>\n\n
\n
variolab-ab-testing\/assets\/js\/tracker.js<\/code> and AbtestTracker<\/code> from it manually.<\/li>\n<\/ul>\n\n0.15.10<\/h4>\n\n
\n
0.15.9<\/h4>\n\n
\n
0.15.8<\/h4>\n\n
\n
wp_salt('auth')<\/code>, so rotating your site's authentication keys silently reset visitor de-duplication (re-counting returning visitors). It now uses a dedicated salt seeded once from the current auth salt \u2014 existing counts are preserved (no reset on update), and future key rotations no longer disturb your stats. Last clean-up item from the 2026-06-12 internal security audit.<\/li>\n<\/ul>\n\n0.15.7<\/h4>\n\n
\n
unfiltered_html<\/code> capability) and, when rendering, re-filters anything that wasn't through WordPress's standard sanitizer. Single-site admins and existing imported pages are unaffected; the feature also remains available to multisite site administrators (their content is simply sanitized as WordPress already does on save). Closes the last actionable item from the 2026-06-12 internal security audit.<\/li>\n<\/ul>\n\n0.15.6<\/h4>\n\n
\n
hash_equals()<\/code>); and a misleading .gitignore<\/code> entry was cleaned up. No functional change for normal use.<\/li>\n<\/ul>\n\n0.15.5<\/h4>\n\n
\n
cron_schedules<\/code> filter, which fires before the init<\/code> action \u2014 tripping WordPress 6.7+'s _load_textdomain_just_in_time<\/code> notice on every cron run (visible with WP_DEBUG and flagged by Plugin Check). The label, only ever shown in cron-management tools, is no longer translated, so nothing loads the text domain early. No functional change.<\/li>\n<\/ul>\n\n0.15.4<\/h4>\n\n
\n
127.0.0.1<\/code>, 169.254.169.254<\/code>, 10.0.0.0\/8<\/code>, 192.168.x<\/code>) and at request time, where WordPress resolves the hostname and rejects targets that point inside your network (reject_unsafe_urls<\/code>, which also blocks redirect-based bypasses). Legitimate public endpoints (Zapier, Make, Slack, your own API) are unaffected. Hardening from the 2026-06-12 internal security audit.<\/li>\n<\/ul>\n\n0.15.3<\/h4>\n\n
\n
0.15.2<\/h4>\n\n
\n
<hr class=\"wp-header-end\"><\/code> marker injected at the top of Admin::render_brand_header()<\/code>, so all four plugin pages (List \/ Edit \/ Settings \/ Import) get the fix.<\/li>\n<\/ul>\n\n0.15.1<\/h4>\n\n
\n
templates\/blank-canvas.php<\/code> called UrlScripts::render_for_position()<\/code>, which was never defined on the class \u2014 every visit to an HTML-imported page running an A\/B test crashed with Call to undefined method<\/code>. Added the missing method as the return-string counterpart of the existing print_for_position()<\/code>; themed pages are unaffected.<\/li>\n<\/ul>\n\n0.15.0<\/h4>\n\n
\n