I want to try a new price page or listing layout without breaking what's already working.

This page may contain affiliate links from which Blur Studio earns commissions.

Editing a live price page or listing layout directly is a specific, avoidable risk: if the new version has a mistake, every visitor sees it immediately, including the ones about to buy. The fix isn't to be more careful editing the live version; it's to not touch the live version at all until the new one is actually proven.

Branch deploys give the draft its own real URL

If your site's code lives in a connected repository, creating a new branch and building the new price page there triggers a branch deploy: a fully working, separately-hosted version of that branch, live at its own predictable URL (following a pattern tied to the branch name), completely separate from your production site. You can visit it, share it, and keep refining it, and none of it touches what's currently live for actual visitors. Netlify's own branch deploy feature handles this automatically once branch deploys are enabled for the repository.

Step by step: how to test safely

1. Create a new branch specifically for the new price page or layout. This keeps the change isolated from your live, production branch entirely.
2. Enable branch deploys for that branch if they aren't on by default. This is a one-time setting; once enabled, every push to that branch deploys automatically.
3. Build and refine the new version at its own dedicated URL. Treat it as a real working page, not a mockup; click through it, test it on a phone, check that pricing numbers and links are correct.
4. Share it with whoever needs to weigh in (a business partner, a designer, yourself a day later with fresh eyes) before deciding anything.
5. Only merge it into your live branch once you're confident it's right. That merge is what actually makes it the live version visitors see.

What this actually costs

Branch deploys don't use Netlify's credit system and are included at no extra charge on every plan, including the free one that comes with 300 monthly credits. The only credit cost involved is the eventual production deploy, at 15 credits, once the new version is approved and merged into the live branch. You can iterate on the branch version as many times as you need without that costing anything extra.

The one alternative, and when it makes sense

A full copy of the site on a second domain achieves a similar separation, a place to test without touching the live version, but it's heavier to maintain: you're now keeping two separate copies in sync manually, rather than having one codebase where a branch is just a different, clearly-labeled version of the same thing. It's worth considering only if your current setup has no code repository for a branch deploy to attach to. The manual-sync cost compounds the longer the test runs: a one-day experiment on a second domain is a minor inconvenience to keep aligned, but a multi-week pricing overhaul kept in sync by hand across two separate copies is real, ongoing work that a branch deploy simply doesn't require, since there's only ever one codebase with different branches pointing at different states of it.

When to skip this

If you genuinely never touch the site, none of this applies; there's no change to test safely. This approach is specifically for the moment you want to try something different (a new price structure, a redesigned listing layout) without committing to it on the live site first.

A worked example: testing a restructured pricing table

Say a subscription software business decides to restructure its pricing page from three flat tiers into a usage-based model with a calculator widget, a meaningfully bigger change than swapping a few numbers. Building this directly on the live pricing page would mean every visitor during development sees a half-finished calculator, possibly showing wrong numbers while the logic is still being worked out, exactly when some of those visitors are actively deciding whether to buy. Building it on a branch instead means the half-finished version only exists at its own separate URL, visible only to whoever has that specific link, while the actual pricing page customers see stays completely untouched and fully functional the entire time.

Once the calculator's logic is actually correct, tested with several different usage scenarios to confirm it calculates the right price every time, the branch gets merged and the new page goes live in one deliberate step, rather than having been visibly broken in public for however long the build took. The business gets to take as long as it needs on something genuinely complex, without that time pressure ever showing up as a live, half-working page.

Common mistakes when testing changes this way

• Forgetting the test URL is still a real, working page. If it's not password protected and the link gets shared more widely than intended, anyone with it can see your in-progress work, including a pricing change you haven't announced yet. Treat the link with the same care you would any unreleased information.
• Merging without a final, fresh look at the branch URL. It's easy to approve a change based on memory of what it looked like a few edits ago. Always do one last pass on the actual current branch deploy immediately before merging, since the version you're approving should be the version you're about to publish.
• Letting a test branch sit unused indefinitely after the idea gets shelved. An old, forgotten branch deploy isn't dangerous, but tidying up branches you're not actively testing keeps the list of what's "in progress" honest and easy to scan.
• Using a branch deploy for a change simple enough not to need one. A single-word text fix doesn't carry much risk either way; save the branch-and-review workflow for changes substantial enough that a half-finished state showing up live would actually be a problem.

Checking current Netlify pricing before you commit

Branch deploys are included free regardless of which plan you're on, so cost isn't really a factor in deciding whether to use this approach. If you're evaluating Netlify more broadly for your site, its current pricing page breaks down what each paid tier adds beyond the free plan, mainly around concurrent builds and team features rather than anything specific to branch deploys themselves.

How I'd approach this

I use branch deploys as the default way to test anything meaningfully different before it touches a live site, specifically because the downside of testing on production (a real customer seeing a broken draft) is entirely avoidable for close to zero extra effort. If you're regularly testing pricing changes, promotions, or layout experiments, it's worth having this set up as a standing habit rather than something you remember to do only after a close call. Get in touch if you want a safe testing workflow set up properly around your site.