How do I actually see a website change before it's live, instead of approving it from a screenshot?

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

A screenshot shows you one state of one page at one screen size. It can't show you whether a form actually submits, whether a link goes where it should, or how the page behaves on a phone. Reviewing from screenshots isn't really reviewing; it's hoping, and the mistakes that get through are exactly the kind screenshots can't catch.

What a Deploy Preview actually is

When a site's code lives in a connected repository, Netlify automatically generates a full, working, separately-hosted version of the site for every proposed change, before it ever touches the live site. Each one gets its own URL, following a predictable pattern (something like deploy-preview-42--yoursite.netlify.app for a numbered pull request), and every preview automatically carries a header telling search engines not to index it, so these test versions don't accidentally show up in Google results.

This isn't limited to human-written code changes either; if your site connects through an AI coding agent that proposes changes directly, those get their own preview too, in a slightly different URL pattern, so you can review AI-made changes the same way you'd review a human's.

Step by step: how to actually use this

1. Confirm your site is connected to a code repository with continuous deployment enabled. Deploy Previews only generate for sites set up this way; a plain file-drop deploy has nothing to preview against.
2. Have whoever is making the change open it as a pull or merge request, rather than pushing it straight to the live branch. This is what triggers the preview to generate in the first place.
3. Open the preview link and actually use the site, not just look at it. Click through pages, submit any forms, check it on your phone. The entire point of a real preview is that you can test behavior, not just appearance.
4. Leave feedback directly on the preview if you need changes. Netlify's own in-preview tool (sometimes called the Netlify Drawer, opened with a keyboard shortcut while viewing the preview) lets you leave comments, take screenshots, and check how the page looks at different screen sizes, all without leaving the preview page.
5. Only approve the merge once you're satisfied with what you actually saw working. That approval is what triggers the real, live deploy.

Password protection and who can see the preview

Deploy Previews are already excluded from search engine indexing by default, but the link itself isn't automatically private in every setup; anyone with the URL could potentially open it. If you're reviewing something sensitive, like an unreleased price change or a client project nobody else should see yet, you can turn on password protection at the project level so previews require a password before they load, though this specific feature requires the Pro plan or Enterprise, not Free or Personal.

What this actually costs

Deploy Previews and branch deploys don't consume credits on Netlify; they're included at no extra charge across every plan, with no published limit on how many you can generate. Password protection, if you want that extra layer, is a Pro-plan or Enterprise feature, not included on Free or Personal. The only other cost consideration is the production deploy that eventually happens once a change is approved and merged, which is the same 15-credit cost as any other deploy, regardless of how many preview iterations happened first.

The alternatives, and when they fit better

A staging site on a WordPress host gives you a similar "see it before it's live" setup, though typically as one single staging environment you overwrite each time, rather than a separate preview per proposed change running in parallel.

Vercel's own preview deployments work almost identically to Netlify's, generating a per-change preview link automatically from a connected repository; which one fits better usually comes down to which platform the rest of your hosting setup already uses.

When to skip this

Deploy Previews only exist for sites built from a connected code repository. If your site is a plain file drop with no repository behind it, there's nothing for a preview system to generate from, and reviewing changes before publishing means manually testing a local copy of the files instead.

A worked example: catching a broken checkout before launch

Say a small online store's developer updates the checkout page to add a new discount code field. Reviewed from a screenshot, everything looks right: the field is there, styled correctly, in the right place on the page. What a screenshot can't show is that the discount field was wired up to validate codes against the wrong product category, so a code meant for one collection silently applies to everything in the cart. Opening the actual Deploy Preview and running a real test order, entering a real discount code and watching what total it produces, catches this in under a minute. A screenshot approval would have let it go live, and the store owner likely wouldn't have found out until a customer either complained about a discount that didn't apply, or noticed one that applied when it shouldn't have.

This is the general pattern worth internalizing: anything involving a calculation, a form, a redirect, or a condition ("if this, show that") needs to actually be clicked through and tested on the preview, not just looked at. Visual review catches typos and layout problems. Only using the real, working preview catches the problems that actually cost money or trust once they're live.

Common mistakes with review previews

• Only checking the preview on a desktop screen. A majority of traffic for most small businesses is mobile. A layout that looks fine at desktop width can break completely at phone width, and that's exactly the gap a preview is meant to catch before real visitors do.
• Approving based on "it looks the same as before." If a change is supposed to be subtle, confirm it's subtle in the right way, not that nothing changed at all, which can also mean the change didn't actually apply the way you expected.
• Skipping the preview for "small" changes. Small changes cause a disproportionate share of surprises precisely because they get less scrutiny. A one-line text edit is low-risk enough to skip reviewing; a one-line logic or pricing change usually isn't, even though both look equally small in a change log.

How I'd approach this

I set this up as standard on every project I build that has an ongoing development relationship behind it, specifically because "I approved it from a screenshot and it broke" is one of the most avoidable, recurring sources of frustration I see. If your current setup doesn't have this and changes keep slipping through broken, it's usually a quick fix once the underlying code is properly in a repository. Get in touch if you want this set up properly, or if the deeper problem is that there's no real repository behind your site yet at all.