Does A/B testing hurt SEO? What Google says

Before you run an A/B test on a page that gets search traffic, it's fair to ask whether the test will cost you rankings. Google's answer is reassuring. Its guide to testing says that changes like a button's color or a call to action's words:

can have a surprising impact on users' interactions with your page, but often have little or no impact on that page's search result snippet or ranking.

For everything else, it sets out four rules. This post goes through them, shows how each way of running a test looks to Google, covers the risks that remain, and ends with a checklist.

What Google says about A/B testing#

Google Search Central's page on the subject, Minimize A/B testing impact in Google Search, was last updated in December 2025. It doesn't tell you how to design a test. It tells you how to run one without confusing Google, in four rules.

1. Don't cloak#

Don't show one set of URLs to Googlebot, and a different set to humans. This is called cloaking, and is against our spam policies, whether you're running a test or not.

Cloaking can get a site demoted or removed from Google's results, and Google adds that it counts "whether you do it by server logic or by robots.txt, or any other method". The safe reading: don't decide what Googlebot sees by checking whether it's Googlebot. Let it get what an ordinary visitor could get.

One detail matters for how tests choose a version. Google notes that "Googlebot generally doesn't support cookies", so it "will only see the content version that's accessible to users with browsers that don't accept cookies". Whatever your test shows a first-time visitor without cookies is what Google sees.

2. Use rel="canonical" on test URLs#

If you're running a test with multiple URLs, you can use the rel="canonical" link attribute on all of your alternate URLs to indicate that the original URL is the preferred version.

Not a noindex tag: Google says a canonical link "more closely matches your intent", and that noindex "can sometimes have unexpected bad effects". This only matters when your versions live at their own URLs, as in a split URL test. When every version shares the page's address, there's nothing to point back to.

3. Redirect with a 302, not a 301#

If you're running a test that redirects users from the original URL to a variation URL, use a 302 (temporary) redirect, not a 301 (permanent) redirect.

A 302 tells search engines to keep the original URL in their index. A 301 says the page has moved for good, so Google may replace your original with the test page. Redirects made with JavaScript are fine too, Google adds.

4. Run the experiment only as long as necessary#

If we discover a site running an experiment for an unnecessarily long time, we may interpret this as an attempt to deceive search engines and take action accordingly.

That's "especially true if you're serving one content variant to a large percentage of your users". Once a test has its answer, update the page and remove the test: alternate URLs, testing scripts, and test markup. How long should you run an A/B test? shows how to work out what "necessary" means before you start.

How each kind of test looks to Google#

There are three ways to serve a test's versions, and each looks different to a crawler:

Three ways to serve a test, as Google sees them

• Chosen in the browser

  /pricingscript

  What Google sees

  One URL. Googlebot runs the page's scripts, so it may index either version.

  Watch for

  Speed. A script that holds up or hides the page delays Largest Contentful Paint for every visitor.

• Separate URLs, with a redirect

  /pricing302/pricing-b

  What Google sees

  Two URLs. A 302, and a canonical link on the variant's URL pointing back, tell it to keep the original in its index.

  Watch for

  A 301 by mistake, a missing canonical link, and test URLs left up afterwards. The redirect also costs visitors a round trip.

• Chosen on the server

  /pricing

  What Google sees

  One URL, and one of its versions, as a first-time visitor without cookies would get it.

  Watch for

  Rules that look for Googlebot to decide what it sees. That's cloaking.

Choosing the version on the server is the simplest for search: one URL, no redirect, nothing for Google to reconcile. Choosing it in the browser keeps one URL too, but puts a script between the visitor and the page. Separate URLs work when you follow rules 2 and 3, and leave the most to clean up afterwards.

How to see which version Google got#

You don't have to guess. In Search Console, the URL Inspection tool shows a page as Google last indexed it, and Test live URL fetches it now, as Googlebot would, with the HTML it rendered and a screenshot.

Run the live test a few times on a page under test. With a test that splits visitors at random, and no cookies to keep Googlebot on one version, different runs can show different versions, and that's expected. Look for two things instead:

• A version no visitor could get. If Googlebot sees something your visitors never do, a rule somewhere is treating it differently, which is cloaking.
• A blank or half-built page. If the screenshot shows an empty page, or the original before a swap, a testing script was still loading or hiding the page when Google rendered it. Visitors on slow phones see the same thing.

The real SEO risks of A/B testing#

Follow the four rules and the remaining risks are quieter ones:

• Slower pages. Testing scripts that hold up the page, or anti-flicker snippets that hide it until they're ready, delay Largest Contentful Paint, one of the Core Web Vitals that Google's ranking systems use. That affects every visitor to the page, in the test or not. A/B test flicker: what causes it and how to fix it covers it in full.
• Leftovers. Test URLs that stay live after the test, redirects nobody removed, and testing scripts on pages with no tests left. Google asks you to remove them, and they confuse whoever works on the site next.
• Tests of what search reads. Google's reassurance is about small changes. A test that rewrites a page's title, headings, or main content changes what Google may crawl, index, and show, for as long as the test runs. Keep those tests short.
• Splits left running. A test left at 95% to one version for months is exactly the case Google singles out. When a version wins, ship it.

A checklist for testing pages that rank#

Before the test

• Keep every version at the page's own URL if you can. If versions have their own URLs, give each a rel="canonical" link to the original, not a noindex.
• Redirect to test URLs with a 302, never a 301.
• Make sure a first-time visitor without cookies gets a real version of the page: that's what Googlebot sees.
• Don't decide what Googlebot sees by checking for Googlebot.
• Check the page's speed with the test running, on a slow phone connection.
• Work out how long the test needs, so you know when it's done.

While it runs

• Watch the tested pages' Core Web Vitals.
• Keep tests of titles, headings, and main content short on pages that rank.

When it ends

• Put the winning version into the page itself.
• Remove test URLs, redirects, testing scripts, and test markup.
• If the test moved a page to a new URL for good, redirect the old URL with a 301 now.

How Mockly handles it#

Mockly was built so that the safe way is the default:

• One URL. Every version of a page lives at the page's own address, so there are no test URLs to canonicalize and no redirects. Each page gets its canonical link once the site's URL is set, and the sitemap and robots.txt are written with every publish.
• Chosen on the server. Googlebot asks for the page and gets one of its versions, picked by the same rule as for any visitor without cookies. Nothing checks for Googlebot to decide what it sees.
• Bots don't skew results. Crawlers get the same pages as everyone else, but they aren't counted in experiments, so they can't dilute your results.
• No testing script. The page arrives as its version, so nothing flickers and nothing is hidden while a script loads. The Performance tab shows Core Web Vitals from your real visitors.
• Easy to finish. Ship a winner and everyone sees it from the next page view. Replace the experiment with the winning markup and publish, and the test is gone.

How Mockly works explains how pages are served, and how bots are told apart.

Frequently asked questions#

Will Google penalize my site for A/B testing?#

Not for testing. Google acts against cloaking, whether you're testing or not, and may act on experiments that run for an unnecessarily long time. Follow its four rules and testing is fine.

Should I noindex my test pages?#

No. Google recommends a rel="canonical" link from each test URL to the original instead, and warns that noindex "can sometimes have unexpected bad effects".

Should I exclude Googlebot from my tests?#

Google's guidance doesn't ask you to, and it warns against showing Googlebot something different from what people see. Treat Googlebot like a first-time visitor without cookies, and if your tool counts visitors, leave bots out of the results instead.

Can I A/B test page titles for SEO?#

Not with an ordinary A/B test. Google, not the visitor, decides what appears in search results, so a test of what earns more clicks from search changes a group of similar pages and compares them with a group left as they were, over several weeks. An ordinary A/B test splits the visitors who are already on the page.