Guides 23 Sep 2026 4 min read by Kalum

A/B testing titles on a WordPress site without upsetting Google

Split-testing headlines is standard practice everywhere except SEO, where everyone is quietly afraid of cloaking. Here is what is actually risky, what is not, and how to run a test on a small site that gives you an answer rather than noise.

Every other part of the web tests its headlines. News sites run four versions of a headline in the first ten minutes and keep the winner. Ecommerce tests button colours to three decimal places.

In SEO, people mostly change a title, wait a month, look at a graph that also contains a Google update, a seasonal dip and a competitor's new post, and declare a result. That is not a test.

Where the worry comes from

The fear is cloaking: showing search engines one thing and users another. That is a genuine violation and it gets sites removed, so the caution is reasonable. But cloaking means showing materially different content based on who is asking. Showing two variants of a headline to a random split of all visitors, including Googlebot, is not that.

Google has been clear about this for a long time: A/B testing is a normal part of running a website, and testing does not carry a penalty as long as you are not singling out search engines, you keep tests temporary, and you use rel="canonical" properly if variants live on separate URLs.

What is actually safe

Safe:

• Serving two versions of a headline, intro or layout to a random split of visitors, Googlebot included in the split like anyone else.
• Running the test for a defined period and then shipping the winner to everyone.
• Testing on one URL with the variation applied server-side, which is the simplest case and needs no canonical gymnastics.

Risky:

• Detecting Googlebot and serving it a fixed version. This is the actual line.
• Leaving a test running for six months. A permanent "test" is just two versions of your site.
• Variants on separate indexable URLs with no canonical, which is a duplicate content problem rather than a penalty.
• Client-side swaps that flash the old version first. Not a Google problem — a user and Core Web Vitals problem.

What is worth testing

On a small site, most tests are not worth running. These are:

• The H1 on a page with traffic but weak engagement. Especially where Clarity shows people bouncing straight back to Google — that is a promise-versus-delivery problem, and the headline is half the promise.
• The first paragraph. The highest-leverage 50 words on any page. Answer-first versus story-first is a real difference and it is measurable in scroll depth.
• The position of the main call to action. Above the fold versus after the explanation.
• The title tag, for click-through rate — which is a different kind of test, covered at the end.

Not worth it on a small site: button colours, minor wording, anything where the honest effect size is under a few percent. You will never have the traffic to detect it, and you will convince yourself you did.

The maths nobody wants to hear

To detect a change reliably you need enough visitors that the result is not luck. Roughly: to spot a jump from 5% to 6% on some action, you need thousands of visitors per variant. To spot 5% to 10%, a few hundred.

What this means practically for a site with a few thousand monthly visitors:

• Test on your busiest pages only. A test on a page with 40 visits a month will never conclude.
• Test big changes. "Which of these two completely different angles works" is answerable. "Does a comma help" is not.
• Run it for at least two full weeks so weekdays and weekends are both represented.
• Accept "no detectable difference" as a result. It means the thing you tested does not matter much — useful information, and it saves you from shipping a change on a coin flip.

Running one properly

1. Pick one page and one change. Two changes at once and you will not know which one did it.
2. Write the prediction down first. "B will reduce quick-backs because it says what the page actually delivers." Without this, whatever happens will look like it confirms something.
3. Split randomly and stably. A given visitor should keep seeing the same variant, or your numbers are mush.
4. Decide the end condition before you start — a date, or a number of views per variant. Stopping the moment one version pulls ahead is the classic way to get a confident wrong answer.
5. Measure something that matters. Scroll depth, time on page, quick-backs, clicks on the CTA. Not "impressions", which the test does not affect.
6. Ship the winner to everyone and take the test down. Then leave it alone for a month before testing that page again.

Our WordPress plugin does the serving side of this — two variants on one URL, a stable random split, one canonical, and the engagement numbers collected per variant — so what you have to supply is the hypothesis and the patience.

Testing the search result itself

The title tag is a special case, because the thing you are testing happens on Google's page, not yours. You cannot split-test it; everyone searching sees the same one. So it is a before-and-after test instead:

1. Record the page's CTR and average position in Search Console for the last 28 days.
2. Change the title. Change nothing else.
3. Wait 28 days and compare, checking that average position did not move much — if it did, the CTR change is about position, not your title.

Two things to expect. First, Google rewrites titles it does not like, so check what is actually being shown before concluding your new title failed. Second, CTR moves with position anyway, which is why the position check matters. Done carefully this is still one of the highest-return edits available: same rankings, same content, more clicks.

Read next

Rage clicks, dead clicks and quick-backs: reading Microsoft Clarity properly

Clarity is free, unlimited, and shows you the three things Analytics never will — where people get angry, where they click nothing, and where they give up and go back to Google. Here is what each signal actually means and what to change.

Google Site Kit: what it is actually good for (and what it is not)

Site Kit connects Search Console, Analytics and AdSense to WordPress with one sign-in. That is genuinely useful. The dashboard it puts in your admin is mostly not. Here is how to set it up and what to ignore.