Conversion rate optimisation for low-traffic websites

Conversion rate optimisation is written about almost entirely by people with enormous traffic. Read it and you will conclude that CRO means running simultaneous multivariate tests. Then you open your own analytics: a small weekly visitor count and too few enquiries for a short, well-powered experiment. The calculation below shows how the required sample and traffic rate affect duration.

This is what we do at that scale, which is the scale most businesses actually operate at.

Work out whether you can test at all

Calculate the sample before choosing a test. For an illustrative increase from 2% to 2.4% (a 20% relative lift), equal allocation, a two-sided 5% significance level and 80% power, a normal approximation gives 21,109 visitors per variant, or 42,218 in total. That is about 422 expected conversions in the control and 507 in the alternative, not thousands of conversions in each.

The calculation uses p1 = 0.02, p2 = 0.024, pbar = 0.022, z_alpha = 1.959964 and z_power = 0.841621:

n = ceil((z_alpha sqrt(2pbar(1-pbar)) + z_power sqrt(p1(1-p1)+p2(1-p2)))^2 / (p2-p1)^2)

This is a planning approximation for independent binary outcomes. Define the eligible visitor and conversion consistently, randomise assignment and account for repeat visitors, exclusions and the planned analysis. At 400 eligible visitors a week in total, this example needs roughly 106 weeks; at 10,000, about five weeks rounded to whole weeks. Traffic and seasonality still matter. NIST explains the large-sample two-proportion test.

Be honest about this early. A test that cannot conclude is worse than no test, because it produces a number that looks like evidence and is not.

There is no universal monthly conversion threshold. The baseline rate, smallest effect worth detecting, false-positive tolerance, power and eligible traffic determine the sample and duration. If that duration exceeds the decision window, use qualitative research and carefully described observational comparisons.

Instrument before you optimise

Before judging a page change, check whether the events reflect the actions you intend to measure. A form button click, a confirmed submission and a qualified enquiry are different events.

The minimum: every form submission fires a named event with the form identified. Phone clicks and email clicks are tracked. The thank-you page is not the only conversion signal, because single-page forms often never reach one. Events fire once, not three times. Tags load after consent, and the consent state is recorded.

Then reconcile. Over a recorded period, compare confirmed form receipts with the enquiries that actually reached your team. Consent choices, spam filtering and failed storage can affect the comparison. Resolve measurement gaps before using the count to judge a page change.

Check the complete path. A submission may succeed without reaching a thank-you page, or a click event may fire even though the enquiry was not saved. Also test phone and email links on mobile, where customers may use them instead of the form.

Fix the obviously broken first

There is a stage before testing, and most sites are still in it. These changes do not need a test, because there is no plausible argument for the current state.

Forms asking for eleven fields when four would do. Phone numbers that are not links on mobile. A thank-you page that says nothing about what happens next. Pricing pages with no numbers on them. Errors that appear only after submission, in red, above a fold you have already scrolled past. Load times over four seconds on mobile.

Review whether every required form field is needed to answer the enquiry, and make phone numbers usable as links on mobile. Record the changes and check the complete submission path. A before-and-after increase without a control does not establish which change caused it.

Use qualitative evidence, seriously

At low traffic, the highest-yield tool is watching people.

Session recordings. Watch twenty sessions that reached the enquiry page and did not convert. Use an initial sample to identify possible patterns, then check those observations against other evidence. The sample size and recordings available do not establish how common a problem is across all visitors.

Five-user tests. Give five people a task on your site and watch them do it. A small round can reveal usability problems worth investigating. The appropriate participants and tasks matter more than treating five as a universal threshold.

Ask the people who did convert. One question on the thank-you page: what nearly stopped you getting in touch? The answers are startlingly direct and they cost nothing to collect.

Read the sales inbox. Every question a prospect asks by email is a question your page failed to answer. We keep a running list of those on client projects and it becomes the next quarter's page edits.

Sequential testing, done carefully

When you must compare and cannot split, compare over time, with discipline.

Run the current version for a full cycle, usually four weeks, and record the conversion rate. Change one thing. Run four more weeks. Compare, then check the obvious confounds: a seasonal change, a campaign that started, a competitor's promotion, a Google update.

This is an observational comparison, not equivalent to a randomised A/B test: differences may come from seasonality, traffic mix or other changes. We state that limitation when reporting results. It is still much better than shipping changes and never looking. The rules that keep it honest: one change at a time, equal-length windows, whole weeks, and a written note of everything else that changed in the same period. That note is the part people skip, and it is the reason so many before-and-after claims fall apart under questioning.

The changes that pay most often

Useful improvements to investigate include reducing form fields; adding specific proof next to the form, a named client, a number, a photograph of real work; stating price ranges instead of "contact for a quote"; making the primary action visible without scrolling on mobile; and rewriting the headline to match the ad or the search term that brought the visitor.

The last one is the most underrated. Someone who arrived searching shopify migration cost and lands on a page headed Digital Transformation Partners has already decided to leave. This is also where conversion work and paid search meet: the same mismatch shows up as a poor quality score, and our small-budget PPC guide covers the ad side of it.

What we do not do at this scale

Multivariate testing. Personalisation engines. Heatmap-driven redesigns where the heatmap is decoration rather than evidence. AI-generated variant copy tested against itself, which optimises for a metric nobody checked the meaning of. And changing the decision threshold or stopping rule after seeing the results. That raises the risk of a false conclusion.

When to bring us in

Two situations are worth paying for. The first is the reconciliation, because incomplete tracking makes the next decision harder and needs a documented comparison with confirmed receipts. The second is when the obvious problems are already fixed and enquiries are still flat, which usually means the problem is the offer or the page's argument rather than its buttons. Both are what our conversion rate optimisation work consists of, and if the site is slow as well, start with Core Web Vitals instead.

If the review identifies a broken form, an unclear page or a loading problem, define the implementation and acceptance checks as website development work. A repaired defect can be verified directly; it does not need to be presented as a winning experiment or a measured revenue uplift.