How to A/B test a landing page without a developer
Building the variant is the part that no longer needs engineering. Here's how the two halves of a landing-page test split, and how to run one without a sprint.
Can you A/B test a landing page without a developer?
Mostly yes — and the part that's changed is the part that used to take the longest.
A landing-page test has two halves, and they have very different requirements. Building the variant — rewriting the headline, moving the form, adding the proof — no longer needs engineering: with 6to9 you describe the change in plain language and it happens on the real page in your browser, ready to share as a link. Serving that variant to real visitors does touch your site, either through the experimentation tool you already run or through your normal release process.
That second half is smaller than it sounds. What kills most landing-page tests isn't the mechanics of splitting traffic; it's the three weeks between "we should try a different headline" and having something concrete to test.
What makes this possible
6to9 is a browser-level agent: a Chrome extension you open on the page itself. You describe the change in plain language — or point at the element and edit it directly — and it happens on the rendered page, then shares as a link that shows the same change on the same real page.
The distinction that matters is what the tool is attached to.
Live editing already exists in the experimentation and CMS world, and it's attached to a property you control. Optimizely is the clearest example: its Visual Editor, in Optimizely Experimentation, edits pages on a site you've added its snippet to; its Visual Builder and Live Preview, in Optimizely CMS, edit content that lives inside that CMS. Both are excellent, and both start from the same requirement — the site is yours, and it's been instrumented or built on their platform first.
6to9 is attached to the browser instead. It edits the page as rendered, so there's nothing to add to the site, no CMS to be on, and no template to own. Browser devtools are also install-free but can't do the rest: edits vanish on refresh, they need CSS rather than a sentence, and there's nothing to hand to a colleague.
Install 6to9 for Chrome →What actually needs a developer, and what doesn't
| Task | Needs engineering? | Why |
|---|---|---|
| Rewriting copy, moving elements, adding proof | No | With 6to9 the change is made on the rendered page — described in words, or dragged to size by hand |
| Seeing the variant on the real page, in context | No | Real DOM, real styles, real content — no clone to build |
| Getting the team to agree on it | No | Everyone opens one link and sees the same page — and can edit on top of it and send theirs back |
| Prototyping a page behind a login | No | Sign in as yourself and change it like any other page — a product page, a dashboard, a settings screen |
| Sharing a logged-in page with the team | No, with one condition | Whoever opens the link needs their own access to that page |
| Splitting live traffic between versions | Usually not | Whatever experimentation tool you already run does this |
| Making the winner permanent | Yes | It becomes a real change to the page, shipped normally |
| Running a live test through checkout or billing | Yes | Those flows move money and carry real state — treat the test itself as engineering work |
The honest summary: you can go from idea to a variant everybody has seen and agreed on without a developer, on public pages and on pages behind your own login alike. You cannot skip your release process to make it permanent, and you shouldn't want to.
How to run one
- 1
Pick one page and one metric
The page you spend the most on sending traffic to, and the single action that page exists to produce — a signup, a demo request, a paid conversion. One metric decided before you start, not chosen afterwards from whatever moved.
- 2
Write down what you think is wrong
Be specific enough to be wrong: 'the headline describes the category, not what we do better' beats 'the hero needs work.' A test of a vague hypothesis teaches you nothing whichever way it lands.
- 3
Build the variant on the real page
Open 6to9 on the live page and say what to change. Look at it in context, then try three or four versions — with the cost of another attempt down to a minute, the first idea shouldn't win by default.
- 4
Get agreement before you launch
Share the link. Design, product and whoever owns the page open the same real page with the same change on it — and can adjust it themselves and share it back, with the history of who changed what attached. Settle it here, in one pass, rather than after the test is running.
- 5
Split the traffic and leave it alone
Run it through your existing experimentation tool. Decide the duration up front and don't peek at significance daily — checking until you see a result you like is how teams ship changes that do nothing.
- 6
Ship the winner, keep the loser written down
The winner goes out through your normal release. The loser is worth as much: it's evidence about your customers, and it stops someone proposing the same thing next quarter.
What to measure
One metric, chosen before the test starts. It should be the thing the page exists to produce, not the thing that's easiest to move.
The common failure is testing against a step that's too early in the funnel. "Start free trial" clicks are easy to lift with a bolder button and a softer promise — and a variant that lifts trial starts while lowering paid conversions has made your business worse while showing you a green number. If the real outcome happens further down the funnel, measure it there, even though it's slower and noisier.
Two caveats worth being honest about. A page with light traffic often can't detect the size of change you're making — in that case, make the obviously-better change and spend your testing budget on a page that has the traffic to answer. And a test that runs for three days over a weekend is measuring the weekend, not the change.
Why this order matters
The sequence above puts agreement before launch, which is the opposite of how most teams do it. It's deliberate. When the variant exists only as a description, the argument about whether it's right happens after the test is already running — and a test everyone is still arguing about produces a result nobody acts on.
When the variant is a real page anyone can open, that argument happens in one pass, in advance, on the actual thing. Then the test only has to answer the question it's good at answering: which version performs better.
Frequently asked
Do I need to install anything on my website?
No. 6to9 installs in your browser as a Chrome extension, not on your site — there is no script to add, no tag to deploy and nothing for your engineers to review before you can start. Building and sharing a variant happens on top of the live page and leaves your site untouched. Putting a variant in front of real visitors is the part that involves your site: either through the experimentation tool you already use, or through your normal release.
How much traffic does a landing page need before a test is worth running?
Enough that a real difference would be visible above the noise, which depends on your current conversion rate and the size of the change you're testing. A page with a few hundred visitors a month is usually better served by making the obviously-right change than by trying to measure it. Use a sample-size calculator before you start, not after.
Can I test a page built in a CMS I can't edit?
You can build and share the variant, yes — the change happens on the rendered page, so it doesn't matter whether WordPress, Webflow or a custom app produced the HTML, or whether you have permission to edit the template. Making it permanent still goes through whoever owns that template.
Does it work on pages behind a login?
Yes. You open 6to9 on the page while signed in as yourself, so a dashboard, an onboarding step or a settings screen works the same way a public landing page does. The one thing to know: anyone you share the link with needs their own access to that page, since the change is applied on top of the real page rather than a copy of it.
What if the variant wins?
Then the change ships the way every other change at your company ships — same review, same release. The test tells you it's worth shipping; it doesn't bypass how your team ships things.
Is this the same as a personalization tool?
No. Personalization shows different visitors different things on an ongoing basis. A/B testing shows a split of visitors one of two versions long enough to learn which performs better, then you ship the winner to everyone.
Published July 29, 2026
6to9 is a Chrome extension — open it on any page you're allowed to change and describe what you want different. Install it for Chrome, or have us walk one of your pages.