Archiving your landing page before every A/B test means saving a complete, working copy of the current version before you change a single element. That copy gives you instant rollback when a variant loses, a frozen baseline to compare results against, and evidence of exactly what was live on any given date.
Most buyers skip it. The builder has an undo button, the host has "backups," and the test only changes a headline — what could go wrong? Then the variant tanks conversion, the undo history is buried under forty later edits, and nobody can reconstruct which exact page produced last week's numbers. The test didn't just fail. It failed and took the baseline with it.
A pre-test archive is cheap insurance: minutes to create, nothing to maintain, and the one version of events nobody can argue with later.
What "archiving" means — and what it doesn't
An archive is not a screenshot. A screenshot proves what the page looked like; it can't be served, measured, or restored. An archive is not your page builder's revision history either. That history lives inside the same tool you're testing in, and it vanishes the day the subscription lapses or the account closes.
A real archive is an independent, downloadable copy of the page as it actually rendered: the HTML a browser produced, the assets it loaded, and captures of the result. If the original disappeared tonight, the archive is what you'd put back online in the morning.
That independence is the whole point. A backup that depends on the thing it's backing up is a spare house key kept inside the house.
Version control doesn't cover it either. Git tracks source, and a builder-hosted landing often has no accessible source to commit — the page is the rendered output of a hosted system. And even with clean source in a repo, nobody wants to rebuild a deployment pipeline at 11 p.m. because a headline test went sideways. The archive is the page as served, not a recipe for rebuilding it.
Three things a pre-test archive buys you
1. Rollback that actually works. When a variant underperforms, the fix is "put the old page back." Without an archive, "the old page" is a memory plus forty edits of undo history. With one, it's a file. Restore, re-point, done. The losing test costs you the test budget — not the baseline page too.
2. An honest baseline. A/B results only mean something against the page that actually ran as control. If the control drifts mid-test — a plugin update, a font swap, a tracking change someone forgot to log — your "A vs B" comparison quietly becomes "A vs B vs the page A used to be." A frozen archive settles any later argument about what the control really was. This matters most on long tests: two weeks of data against a casually edited page is two weeks against a moving target, and the "lift" you measured may belong to an edit nobody logged.
3. Evidence with dates. Disputes happen: with a partner about which page ran, with a platform about what was live during a review, with yourself about when a change shipped. An archived copy with a timestamp is evidence. "I'm pretty sure we changed the headline in March" is not.
There's a fourth, quieter benefit: braver tests. When rollback is free, you can afford bolder variants — a restructured hero, a new pricing block, a different offer angle — instead of timid headline tweaks. Teams that can't roll back test timidly, because every variant risks the page they depend on. Teams that can roll back test the things that actually move numbers.
What a useful archive contains
A page archive is only as good as its completeness. The checklist:
- Rendered output, not just source. Modern builders assemble pages in the browser. Saving raw source can miss half the DOM.
- Assets: images, fonts, CSS, scripts — the files the page references, not links back to a CDN that can change or expire.
- Both viewports: desktop and mobile captures. Paid traffic lands mostly on phones; a desktop-only archive misses the layout your visitors actually saw.
- A manifest or report: what was captured, when, from which URL, and what didn't survive the capture.
- A name you'll find later:
page-name_YYYY-MM-DD_pre-test-<hypothesis>, stored with the test doc, not in a downloads folder.
Web Archive produces exactly this shape for sites you own or are explicitly authorized to archive: a bounded same-origin capture (up to 20 pages, 4 levels deep) across desktop and mobile viewports, plus a validation report listing what won't work offline. Every job requires an ownership attestation and a written authorization statement — the tool is for your own pages, full stop.
One practical note on retention: keep the archive next to the test record, and keep it at least until the test's learnings are baked into a new control. Old archives are cheap to store and expensive to wish for.
The pre-test archiving workflow
Five steps, in order, before any variant goes live:
- Freeze the control. No edits for a day before the archive. A moving target archives badly.
- Archive the page. Run the capture and download the bundle immediately. Download links expire — Web Archive's live 24 hours — so "I'll grab it later" is how archives don't happen.
- Read the validation report. A status of "completed with limitations" means something didn't capture: a dynamic API, a form, a script. Know what's missing before you need the copy.
- File it with the test. Archive, hypothesis, start date, and traffic split in one place. An archive without its context is half the value.
- Only then launch the variant.
The whole routine takes under half an hour. Compare that to the cost of rebuilding a baseline from memory — or discovering the undo history doesn't go back far enough. The cadence matters more than the tooling: archive before every test, no exceptions for "small" ones. The test that destroys a baseline is always the small one nobody archived. To turn this one-off habit into a system, the companion piece on a landing page backup strategy for media buyers covers what to snapshot, how often, and where to keep it.
Mistakes that make archives useless
Archiving after the test starts. The baseline must freeze before the first variant impression. Otherwise you're archiving a page that already drifted.
Trusting the builder's export. Builder exports are written for re-import into the same builder. They're not servable pages, and they're hostage to the same subscription. If you're leaving the builder entirely, that's a migration, not an archive — see moving a landing off a dying page builder.
Keeping one copy in one place. An archive that lives only in your downloads folder dies with your laptop. Copy it to cloud storage the day you make it. Two locations minimum — the rule from the backup world applies here unchanged.
Skipping the validation report. A bundle that looks right in a folder may be missing the form handler or a dynamic block. Visual similarity is not functionality — the report tells you the difference.
FAQ
Isn't my page builder's version history enough?
It's better than nothing, but it's the same system you're testing inside. Revision history can't protect you from the builder itself: a lapsed subscription, a closed account, a broken update. An independent archive survives all three. There's also the exit problem — history is reachable only while you have the account. A downloaded archive is reachable while you have the file.
How long does archiving a page take?
Minutes for a single landing. The capture runs, you download a bundle, you file it. The discipline costs less time than one "what did the control look like again?" thread.
What if my page has dynamic elements — forms, scripts, APIs?
They may not work offline in a static copy. Dynamic APIs, service workers, signed media, and authentication are known limits. That's what the validation report is for: it lists what didn't survive, so you archive knowing the gaps instead of discovering them mid-rollback.
Can I archive pages that aren't mine?
No. Archiving is for sites you own or are explicitly authorized to archive. Every Web Archive job requires an ownership attestation and a written authorization statement before it runs. Copying other people's pages is not what this tool is for.
How often should I re-archive the control?
Before every test, and after any significant edit outside a test. If the live page changed since the last archive, your archive describes a page that no longer exists. The cost of re-archiving is minutes; the expensive direction is always the other one.
Archive your control before the next test
Web Archive is free with a registered account: paste your URL, attest ownership, and download a validated copy of your page across desktop and mobile — with a report of what won't survive offline. Do it before the variant goes live, not after it loses.
By the FictioFactori editorial team — we run these tools in our own buying workflow. Last updated: July 2026.