Google Optimize shut down on September 30, 2023. If you log in now, your experiments have stopped, and any test still running on your site ended on that date. So the real question is which Google Optimize alternatives to use for A/B testing now, and what to clean up on your site first.
The short answer: pick a dedicated testing tool that sends data to GA4, remove the old Optimize code, and restart only the tests that still matter. In this guide I explain what changed, how I’d choose a replacement, and how to keep your tests safe for SEO.
What Happened to Google Optimize
Google announced in January 2023 that Optimize and Optimize 360 would be sunset. On September 30, 2023, both products stopped being available, and every experiment and personalization that was still live came to an end.
Google’s reason was simple. In its own words, Optimize did not have many of the features and services that customers ask for in experimentation. Instead of building those, Google chose to invest in testing tools that work with Google Analytics 4 (GA4).
Google also said it would work with other testing companies, naming AB Tasty, Optimizely and VWO, and that it has made its APIs public so any A/B testing tool can connect to GA4. You can read the official notice on the Google Optimize sunset page in Google Analytics Help.
What This Means in Practice
- No new tests: you can’t create or run experiments in Optimize anymore.
- Live tests have ended: visitors now see your original page, unless your tool’s code is still doing something on the page (more on that below).
- No direct replacement from Google: there is no “GA4 Optimize”. Testing now happens in a separate tool that reports into GA4.
- The timing matches the GA4 move: standard Universal Analytics properties already stopped processing data in July. I covered that in what to do now that Universal Analytics has stopped.
First, Clean Up the Old Optimize Code
This is the step most guides skip, and in my experience it is the one that causes real problems. Many sites still have the Optimize snippet and the anti-flicker snippet in their page templates.
The anti-flicker snippet (a small piece of code that hides the page for a moment while the test loads) was there to stop visitors seeing the original page flash before the variant. With Optimize gone, it can still hide your page while it waits for a script that does nothing useful.
Here is what I check on every site that used Optimize:
- Search your theme or template files for
optimize.js,googleoptimize.comandasync-hide. The last one is the class the anti-flicker snippet adds to the page. - Open Google Tag Manager and look for any Optimize tags or Optimize settings in your old Universal Analytics tags.
- Check plugins. On WordPress, some analytics and header plugins added Optimize code through their own settings.
- Remove the code, publish, and load a few key pages in a private browser window to make sure nothing looks broken.
- Run your main templates through PageSpeed Insights before and after, so you can see if the change helped load time.
If you are not sure how to read that report, my PageSpeed Insights guide walks through each section.
I’d do this cleanup before installing any new tool. Otherwise you end up with two testing scripts fighting over the same page, and that is hard to debug later.
What to Look for in Google Optimize Alternatives
Most of the top Google Optimize alternatives can run a basic A/B test. The real differences are in how they connect to your data, how they affect page speed, and what they cost as your traffic grows.
These are the points I compare before recommending a tool:
GA4 Integration
If GA4 is your main analytics tool, you want test data inside it. Google has published a standard way for testing tools to send an experience_impression event to GA4 when a visitor is put into a variant. The variant details travel in a parameter called exp_variant_string.
Ask any vendor whether they support this, or a similar GA4 integration. It lets you build audiences for each variant and compare conversions in GA4 reports, not only inside the testing tool.
Client-Side or Server-Side Testing
Client-side testing changes the page in the visitor’s browser with JavaScript. This is how Optimize worked. It is easy to set up, and marketers can use a visual editor without a developer.
Server-side testing decides which version to show on your server, before the page reaches the browser. It avoids flicker and is better for bigger changes like new layouts, pricing logic or checkout steps. It needs developer time.
For most small and mid-size business sites, I’d start with client-side testing and only move to server-side when tests grow beyond headlines, buttons and page sections.
Page Speed Impact
Client-side tools load a script that has to run before the variant shows. If the script is heavy or loads slowly, it can hurt Largest Contentful Paint (how fast the main content appears) and Cumulative Layout Shift (how much the page jumps around).
Check whether the tool loads asynchronously, how large its script is, and whether it uses an anti-flicker method with a short timeout. I always test a tool on a staging page first and compare load times before rolling it out.
Statistics and Reporting
Testing tools use different maths to decide a winner. Some use Bayesian statistics (which shows the chance that a variant is better), like Optimize did. Others use frequentist statistics (which shows whether a result is likely to be real or just chance).
You don’t need to be a statistician. Just make sure the tool explains results in plain terms, shows how confident it is, and warns you when a test doesn’t have enough data yet.
Price and Traffic Limits
Optimize was free for most users, so this is the part that stings. Paid tools usually price by monthly visitors tested, features or both. Before signing up, work out how many visitors actually reach the pages you want to test, not your whole site.
Privacy and Consent
Testing tools often set cookies to remember which variant a visitor saw. If you serve visitors in regions with strict privacy rules, check how the tool handles consent and where it stores data. Talk to whoever handles privacy for your business before you install anything.
The Main Types of A/B Testing Tools
Rather than rank tools that change their features and plans often, I find it more useful to group them by type. Then you can shortlist two or three and try them.
| Type of tool | Examples | Best for | Watch out for |
|---|---|---|---|
| Google’s named partners | AB Tasty, Optimizely, VWO | Teams that want a visual editor and GA4 integration | Plans and limits vary, so check pricing for your traffic |
| Other dedicated testing platforms | Convert, Kameleoon | Teams that want similar features from a different vendor | Confirm how they connect to GA4 |
| Open-source and developer tools | GrowthBook | Teams with developers who want control and lower cost | Needs technical setup and upkeep |
| Testing built into your platform | Features in some CMS, landing page and email tools | Simple tests on landing pages or emails | Usually limited to that platform’s pages |
My honest view: if you ran a handful of simple tests a year in Optimize, you may not need an expensive enterprise platform. A lighter tool, or the testing feature already in your landing page builder, may do the job.
If testing drives real revenue decisions, such as checkout or pricing, it is worth paying for a tool with strong reporting, server-side options and good support.
How to Move Your Testing Program After Optimize
Whatever tool you choose, the move follows the same steps. This is the order I use.
- List your old experiments. Write down what you tested, the result and the date. If you saved Optimize reports or screenshots, keep them with this list. Your test history is still useful even if the tool is gone.
- Remove the Optimize and anti-flicker code. Follow the cleanup steps above so you start with a clean page.
- Check that GA4 is tracking conversions. Your new tests are only as good as the goals you measure. Make sure your important actions, like form sends and purchases, are marked as conversions in GA4.
- Shortlist and trial two tools. Use the points above. Install each on a test page and check the GA4 link, page speed and how easy the editor is for your team.
- Run one simple test first. A headline or call-to-action test on a busy page is a good start. It shows you whether the data flows into GA4 correctly before you test anything important.
- Restart only the tests that still matter. Don’t copy every old experiment. Your site and audience have changed since many of them were set up.
How to Keep A/B Tests Safe for SEO
A new tool is a good moment to check your testing habits against Google’s guidance. Google has a help page on how to minimize the impact of A/B testing in Google Search, and the rules are clear.
- Don’t cloak. Cloaking means showing Googlebot different content from what visitors see. Never set up a test that sends Googlebot to one version on purpose. That breaks Google’s spam policies.
- Use a canonical tag on variant URLs. If your test uses separate URLs (a split URL test), add a
rel="canonical"tag on each variant that points to the original page. Google advises against using noindex here. - Use 302 redirects, not 301. If you redirect visitors from the original page to a variant, use a temporary 302 redirect. It tells Google to keep the original URL in its index. JavaScript redirects are also fine.
- Don’t run tests longer than needed. Once you have a reliable result, update the page with the winner and remove the test code and URLs.
Google also says that small changes, such as button colour or call-to-action wording, usually have little or no effect on rankings or snippets. So don’t let SEO fears stop you from testing. Just follow the basics.
Here is what a canonical tag on a variant page looks like:
<!-- On https://example.com/pricing-b/ -->
<link rel="canonical" href="https://example.com/pricing/" />
A mistake I often see is a variant URL left live and indexable months after the test ended. Add “remove test URLs and redirect them” to your end-of-test checklist, and check the URLs in Search Console afterwards.
Testing Without a Dedicated Tool
Not every site needs an A/B testing tool right away. If your traffic is low, a proper test may take months to reach a clear result. In that case, other methods can tell you more, faster.
- Before and after changes: make one clear change, note the date, and compare results over the same weekdays before and after. It is less precise than a split test, but useful for small sites.
- GA4 Explorations: use funnel and path reports to find where people drop off. This tells you which page to fix first.
- Search Console data: for SEO tests like title changes, compare clicks and click-through rate for the page before and after the change.
- Session recordings and heatmaps: these show how people use a page, and often point to obvious problems you can fix without a test.
- Talk to customers: a few quick questions on a form or a sales call can reveal why people don’t buy.
In my experience, many small sites learn more from fixing clear problems than from testing tiny button changes. Save formal A/B tests for pages with enough traffic to give a real answer.
How Much Traffic Do You Need for an A/B Test?
There is no single number, because it depends on your conversion rate and how big a change you expect to see. But the rule of thumb is simple: the lower your traffic and conversion rate, the longer a test must run.
Most testing tools have a sample size or test duration calculator. Use it before you start, not after. If it says the test needs to run for many months, test a bigger change or pick a busier page.
I also like to run every test for at least one or two full weeks, even if the tool calls a winner sooner. That way the result covers weekdays and weekends, which often behave very differently.
Common Mistakes After the Optimize Shutdown
- Leaving dead code on the site. The anti-flicker snippet can keep slowing pages long after the tool has gone.
- Picking a tool on price alone. A cheap tool that slows your pages or can’t send data to GA4 may cost you more in lost sales.
- Testing without clear goals. Decide what success looks like, and set it up as a GA4 conversion, before the test starts.
- Stopping tests too early. Early results often swing a lot. Wait for the planned sample size.
- Running too many tests on one page. Overlapping tests on the same page can blur the results unless your tool is built to handle that.
- Forgetting Core Web Vitals. Watch LCP, FID and CLS after adding any new script. FID is due to be replaced by INP in March 2024, so it is worth reading how to prepare for INP now, since testing scripts can slow down how fast a page responds to clicks.
Conclusion: Your Next Step
Google Optimize is gone, but A/B testing isn’t. The best Google Optimize alternatives for you depend on your traffic, your team and how much testing affects your revenue.
My advice is to start with the boring part. Remove the old Optimize and anti-flicker code, confirm your GA4 conversions are right, and then trial two tools that send data to GA4. Run one simple test to prove the setup, and follow Google’s SEO rules for every test after that.
If your GA4 setup still feels shaky after the Universal Analytics switch, go back through the GA4 migration checklist first. Good tests depend on good tracking.



