How to Test a Netlify Website

To test a Netlify website before a change reaches your live domain, open the Deploy Preview for its pull or merge request and review the changed pages and user journeys before merging. Use local development for quick checks, a branch deploy for ongoing review of a branch, and the production domain for a final check after publishing. Netlify describes Deploy Previews as a way to test and review changes before launch. Netlify Deploy overview.

Choose the right Netlify testing environment

Environment	Use it for	What to know
Local development	Fast feedback while you work	Runs on your machine; the command and local address depend on your project.
Deploy Preview	Reviewing a pull or merge request before merging	Request-scoped. Anyone with the link may be able to access it unless protection is configured.
Branch deploy	Ongoing review of a branch or early release	Branch-scoped and must be enabled in the site’s configuration.
Deploy permalink	Revisiting one successful deploy later	Its content stays associated with that specific deploy.
Production deploy	Checking the actual published site	Served at the primary domain and replaces the previous production version; a production deploy can be rolled back.

Netlify’s preview options comparison explains the scope differences. See its documentation for branch deploys and production deploys for details.

Test a change with a Deploy Preview

Push your change through the repository workflow connected to the Netlify site, then open or update its pull or merge request.
Wait for Netlify to create the Deploy Preview. Previews are created by default for pull or merge requests unless preview controls have been changed.
Open the preview URL from the deploy or request details. Check the routes touched by the change and representative user journeys, such as navigation, forms, and links.
Check the layout at the viewport sizes relevant to your users. Also check images, fonts, and other assets, plus any behavior that depends on environment variables or external integrations.
Share the preview only with people who should see it. Configure password or team login protection if the content must be restricted.
Fix issues, push another commit, and review the updated preview before merging.

Deploy Previews, unpublished production deploys, and old branch deploys receive an X-Robots-Tag: noindex by default according to Netlify. That directive concerns search indexing; it does not make a preview private. Netlify notes that the currently published production deploy and most recent branch deploys can be indexed. Check your own site’s headers and configuration as part of a production workflow. Netlify’s indexing and preview guidance.

Use branch deploys for persistent review

Choose a branch deploy when reviewers need a branch-level environment that remains available as that branch changes, rather than a preview tied to one request. Enable branch deploys for selected branches or all new branches in the project configuration, then use the branch URL to review its latest deploy. The URL’s content can update with later branch deploys, so use a deploy permalink when you need to revisit a fixed successful deploy. See Netlify’s branch deploy documentation.

Run local checks and automated audits

Local development

Run the development command documented by your framework or project, then open the local address it prints. Local checks are useful for rapid iteration and confirming that the application works in its framework. They do not replace checking the Netlify preview, where the proposed deploy and hosting configuration can be reviewed.

Lighthouse reports in deploys

Netlify’s Lighthouse build plugin can display audit reports in deploy details and logs, and can post scores in pull or merge request deploy notifications. Its audits cover performance, SEO, accessibility, and more. Netlify recommends configuring the plugin in netlify.toml for options such as auditing different URL paths. The documented integration does not support pages or paths that require login, so manually review important authenticated flows. Treat an audit as one check, alongside exercising the pages and journeys that matter. Netlify Lighthouse scores and reports.

Verify the production site after publishing

Confirm the production deploy completed successfully.
Open the primary domain in a browser and check the routes changed by the release.
Repeat critical user journeys and check any production-only settings or integrations.
If the published version has a problem, use Netlify’s deploy management to roll back as needed, then investigate and deploy a correction.

For a failed deploy, inspect the deploy logs and fix the underlying build or configuration issue. Netlify supports retrying from the latest branch commit, including a retry with a cleared cache. A retry builds from the branch HEAD, which may differ from the commit that created the original deploy; check the commit before retrying. Netlify manage deploys.

Capture a preview for visual review

A browser screenshot can help compare a preview page with its expected appearance or share a visual record with reviewers. Capture the exact preview URL and relevant viewport, and remember that a screenshot documents appearance at a point in time; it does not verify interactions, access control, or the full behavior of a page.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://YOUR-DEPLOY-PREVIEW-URL -o preview.webp

Replace https://YOUR-DEPLOY-PREVIEW-URL with the actual preview URL. See the ScreenshotNeo API documentation for the request options.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server from ScreenshotNeo. One GET request can capture a Netlify preview as an image or PDF. Cookie banners are accepted and removed before the shot, along with known newsletter popups and chat widgets; those steps can be turned off. Bot checks, blank pages, and failed loads are never billed, and response headers report the page verdict and billing status. An MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://YOUR-DEPLOY-PREVIEW-URL -o preview.webp

Read the ScreenshotNeo API docs. Sign up for 1,000 free screenshots a month, with no card.

Troubleshooting Netlify website tests

Symptom	Likely cause	What to do
No Deploy Preview appears	Preview controls or repository integration settings may differ from the defaults.	Check the site’s deploy settings and the connected repository workflow. Netlify documents preview configuration in its Deploy overview.
A teammate cannot open the preview	Access protection may require a password or team login.	Check the site’s configured protection and share access through the intended method.
A preview is visible to someone who should not see it	Preview URLs may be accessible to anyone with the link unless protection is configured.	Set password or team login protection before sharing sensitive preview content. `noindex` does not restrict access.
A branch URL changes unexpectedly	Branch deploy URLs reflect deploys for that branch.	Use a deploy permalink to inspect a specific successful deploy later.
Lighthouse does not report a login-gated page	The documented Netlify integration does not support pages or paths requiring login.	Manually audit the authenticated page or use an appropriate separate audit workflow.
A retry does not reproduce the original deploy	Retry uses the latest branch HEAD, which may have advanced.	Check which commit the retry will build and inspect the relevant deploy logs before retrying.
The preview looks right but production does not	Production may use domain-specific settings or integrations.	After publishing, check the primary domain and repeat the affected journey.
A screenshot shows a challenge page or blank result	The target may be showing a bot check, loading blank, or failing before content appears.	Open the URL directly to determine whether the page is accessible and wait for its intended content before capturing again.

Performance, reliability, and cost considerations

Review early: check the preview as soon as it is available so problems can be corrected before merging.
Use the smallest useful scope: test changed routes and important journeys on each review; run broader checks when a change affects shared layouts or site-wide behavior.
Make audits repeatable: configure Lighthouse paths in netlify.toml when the relevant pages are public and supported.
Preserve evidence: use a deploy permalink to return to a particular successful build, and record the commit when reporting an issue.
Keep access in mind: preview indexing defaults do not provide privacy; configure protection where needed.
Screenshot cost: ScreenshotNeo bills only clean shots. Bot checks/CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing. Plans include 1,000 monthly shots free, then paid options from $5 for 3,000; see its docs for capture configuration.

FAQ

Does a Netlify Deploy Preview change my live site?

No. It is for reviewing a proposed change before it is merged and published to production.

Does noindex make my preview private?

No. It is an indexing directive, not access control. Configure password or team login protection if the preview should be restricted.

When should I use a branch deploy instead of a Deploy Preview?

Use a branch deploy for ongoing branch-level review; use a Deploy Preview for a specific pull or merge request.

The documented Netlify Lighthouse integration does not support pages or paths that require login.

Can I roll back a production deploy?

Netlify documents production deploy rollback. Review its production deploy documentation for the workflow.