Why A/B testing on a static host is different
A/B testing on a dynamic site is usually handled by a testing platform: it splits traffic on the server side, tracks conversions, and reports results. On a static host, that approach does not apply directly. There is no server-side logic to split users into groups. There is no application to run experiments. What you have is a set of HTML files served as-is.
This does not mean A/B testing is impossible. It means the mechanics are different. You work at the level of URLs, redirects, and client-side code instead of server logic. In some ways this is simpler; in others, it requires more care to avoid skewed results.
This article is about how to run an A/B test between two static pages on a static host, what you can realistically test, and how to read the results without fooling yourself.
What you can and cannot test on a static host
Before setting anything up, it helps to be clear about what is possible.
You can test:
— two versions of the same page with different copy;
— two versions with different layout or visual emphasis;
— two different offers on the same traffic;
— two different calls to action;
— two different hero sections above the fold.
You cannot easily test:
— changes that require server-side personalization;
— experiments that depend on user accounts;
— tests where a user must see the same version across sessions without extra work;
— tests that need real-time bidding or backend logic.
For most marketing pages, the first list covers what matters. The limits are real, but they do not prevent useful testing.
How to split traffic between two static pages
There are several ways to split traffic between two static pages. Each has trade-offs.
The simplest method is to use two URLs and share them through different channels. For example, version A goes into social posts and version B into email. This is not a true A/B test, because the audiences differ, but it can still give you a signal if the channels are similar enough.
A more controlled method is to use a single entry URL that redirects users to one of the two pages. The redirect can be handled by a short link service with rotation or by a small script on a gateway page. This keeps the audience closer to the same and gives each version a random share of traffic.
A third method is to build both versions into the same HTML page and switch between them with client-side JavaScript. The user sees one version, but the URL stays the same. This is convenient for tracking but requires care to avoid flicker and inconsistencies.
For most static host scenarios, the redirect method is the most practical. It keeps the split controlled, works with existing hosting, and does not require changes to how pages are built.
For a related approach using short links, see URL rotation and A/B testing for short links.
What to change between versions
A common mistake in A/B testing is changing too much at once. If version A and version B differ in headline, layout, offer, and call to action, you will not know which change caused the difference in results.
A better approach is to isolate one thing per test:
— test the headline while keeping everything else identical;
— test the call to action while keeping the rest the same;
— test the placement of a form while keeping the copy identical;
— test the visual emphasis of a key element while keeping the content the same.
This makes results interpretable. You learn what worked, not just that something worked.
If you want to test multiple things, run multiple tests — one after another. Each test answers one question.
Tracking results without a heavy stack
On a static host, you do not have a full testing platform. But you can still track what matters.
The two things you need to know are:
— how many people saw each version;
— how many of them did the thing you care about.
For the first, you can use a simple redirect service that counts clicks per version, or two separate URLs with their own analytics.
For the second, you need a conversion event. This could be a form submission, a click on a specific button, a purchase, or any other measurable action. If you use a site analytics tool, you can set up events for each version separately and compare.
If you do not have analytics, you can use a lightweight approach: route conversions through a specific page that records the event. For example, both versions send users to the same thank-you page, but with a parameter that identifies the version.
The goal is not to build a testing platform. The goal is to know which version performed better for the specific action you care about.
How long to run a test
A common question is how long an A/B test should run. The answer depends on traffic and on how big a difference you expect.
If traffic is low, the test needs to run longer to gather enough data. If traffic is high, a few days may be enough.
A practical rule: do not stop a test after a few hours just because one version is ahead. Early results are noisy. Wait until each version has enough visitors to make the comparison meaningful.
Another rule: avoid running a test during an unusual period. Holidays, promotions, and unusual events can skew results. If you can, run the test during a normal week.
If you cannot wait long enough to reach a meaningful sample, it may be better not to run the test at all. Acting on insufficient data can lead to the wrong decision.
Common pitfalls in static A/B testing
A few issues come up often and can quietly ruin a test.
Pitfall one: different audiences. If version A is shared in one channel and version B in another, the audiences may differ in ways that affect results. Keep the source of traffic as similar as possible.
Pitfall two: uneven split. If the redirect favors one version, results become unreliable. Check that the split is roughly even.
Pitfall three: caching. Static pages are often cached aggressively. If the redirect is cached, users may keep seeing the same version even after the test changes. Make sure caching does not interfere with the split.
Pitfall four: bot traffic. Bots can hit both versions and inflate numbers without representing real users. Filter bot traffic when possible.
Pitfall five: too many changes at once. As mentioned earlier, this makes results hard to interpret.
Pitfall six: stopping too early. Early results are noisy. Wait for enough data.
Pitfall seven: ignoring context. A version that wins in one context may lose in another. Consider whether the result generalizes or is specific to the test conditions.
What to do after the test
Once the test is done, the important step is to act on the result.
If one version clearly performed better, use it as the default. Replace the losing version. If the result is unclear, either run the test longer or design a new test that isolates a different variable.
Document what you tested, what you changed, and what the result was. This becomes a reference for future decisions and prevents repeating the same tests.
If the test produced no clear winner, that is also useful information. It suggests that the difference you tested may not matter much for your audience, and you can focus on other variables.
For more on how static pages can be set up for different purposes, see static portfolio site for photographers without code.
When A/B testing is not worth it
A/B testing is not always the right tool. It takes time, traffic, and attention. In some cases, the effort is not justified.
If traffic is very low, tests take too long to produce meaningful results. If the difference between versions is small, the test may not detect it. If you are not going to act on the result, there is no point running the test.
Sometimes it is better to improve a page based on clear principles — better copy, clearer call to action, faster load — than to test small variations. Testing is most useful when you have a specific hypothesis and enough traffic to evaluate it.
Frequently asked questions
Can I run an A/B test on a static host?
Yes, but the mechanics are different from a dynamic site. You split traffic at the level of URLs, redirects, or client-side scripts instead of server logic. It works for most marketing pages.
What is the best way to split traffic between two static pages?
The most practical approach is a single entry URL that redirects users to one of the two versions. This keeps the split controlled and the audience similar.
How many changes should I make between versions?
One change per test. If you change multiple things at once, you will not know which change caused the result.
How long should a static A/B test run?
Long enough for each version to have enough visitors to make the comparison meaningful. Avoid stopping after a few hours. Run during a normal period if possible.
Can I use a short link service for A/B testing?
Yes, if the service supports rotation. It can split traffic between two destination URLs and track which version got more clicks and conversions.
What if the test shows no clear winner?
That is useful information. It may mean the difference you tested does not matter much for your audience. You can either run the test longer or focus on other variables.
What should I do with the losing version?
If one version clearly performed better, make it the default and replace the other. Document the result for future reference.
