How to Preview a Website Before Publishing

Direct answer: Preview a website in the environment that matches the change. Use your CMS or site builder’s draft preview for content edits, a local development server for code on your machine, a branch or pull-request deployment for collaborative review, or a protected staging environment for longer-running work. Then verify the intended draft data, inspect desktop and mobile layouts, test visitor-facing interactions, check who can access the URL, and publish only after the review passes.

A preview is useful only when it represents the version you intend to publish. A page can look correct while still loading production CMS data, exposing unpublished content through an unprotected URL, or failing at a mobile breakpoint.

1. Choose the preview method that matches your change

Change	Preview to use	Verify
Copy, images, or a page edited in a hosted builder	Built-in page or draft preview	Draft content, desktop layout, mobile layout, and visitor-like interactions
Unpublished CMS entries	CMS draft or staging preview	The preview reads draft data and the item is not already live
Code on your own machine	Local development server	The site builds, runs, and uses development data and environment variables
Pull request or merge request	Deployment preview attached to the change	The URL reflects the latest commit and has the intended access controls
Several changes reviewed over days	Branch deploy or staging environment	Reviewers know the branch, data source, and publishing target
Headless CMS draft on a rendered site	Framework draft mode	Draft access is protected and the expected CMS content is rendered

Netlify documents local development, branch deploys, Deploy Previews, and Preview Servers as separate workflows. Pull or merge requests in a connected repository can create a unique Deploy Preview URL. Netlify also notes that Deploy Preview and branch URLs can be accessible to anyone with the link unless password protection or team login is enabled. See Netlify Deploy Previews and its environment variable documentation.

Webflow separates staged CMS content from live published content and recommends reviewing staging before production publication. Squarespace provides full-page preview while editing and mobile appearance checks; closing the editor in version 7.1 hides the editing toolbar for a visitor-like review. Vercel’s Draft Mode documentation describes protected previews of unpublished headless CMS content for Next.js and SvelteKit. Exact controls and URLs vary by platform, so confirm the current documentation for your stack.

2. Set up a safe preview environment

For a CMS or site builder

Open the page or entry as a draft.
Start the platform’s preview mode rather than opening the production URL.
Confirm the title, copy, images, links, and metadata are the draft versions.
Check whether the preview URL is private, team-only, password protected, or public to anyone with the link.
Use the platform’s mobile preview, then open the URL in a real mobile browser if the change affects responsive behavior.

For a local code change

Check out the intended branch and install the project’s locked dependencies.
Load development environment variables, including the CMS project, dataset, API mode, and preview token where required.
Start the documented development command, commonly npm run dev or an equivalent command for the framework.
Open the local URL in a private browser window so cached authentication and extensions do not hide problems.
Test the changed route, assets, forms, navigation, and responsive breakpoints.

Netlify’s Preview Server guidance uses netlify dev as the starting point for local preview. A CMS-backed site may need development connection parameters changed so the preview retrieves updated and unpublished content rather than production content.

For a pull-request or branch preview

Push the branch and open the pull request or merge request.
Wait for the hosting provider to create the deployment preview.
Confirm the commit identifier or deployment status matches the change under review.
Check preview-specific environment variables and CMS credentials.
Share the URL only with people who should see the draft; enable password or team protection when the content is restricted.

3. Confirm the preview contains the intended data

Data mismatches are one of the most common preview failures. A correctly rendered page may still be wrong if it reads production content, a stale cache, or the wrong CMS space.

Compare a changed headline or unique draft value against the CMS record.
Check that unpublished images and references resolve.
Verify the preview API token has draft-reading permission and is stored only in the preview environment.
Inspect the network requests or server logs to confirm the draft endpoint, project, dataset, or branch.
Check date, locale, feature-flag, and personalization settings that can change the rendered page.
Rebuild or refresh after changing environment variables; many frameworks read them only at startup or build time.

4. Review the page like a visitor

Desktop and mobile layout checklist

Check the smallest supported phone width, a tablet width, and a typical desktop width.
Look for horizontal scrolling, clipped text, overlapping controls, and images that distort.
Verify sticky headers, menus, modals, cookie controls, and footers at each breakpoint.
Check keyboard focus, visible focus states, labels, contrast, and reduced-motion behavior.
Test a slow connection or throttled device when large images or client-side code changed.

Interaction checklist

Open primary navigation and important internal links.
Submit forms with valid and invalid data and verify the success and error states.
Test search, filters, accordions, tabs, carousels, video, and other changed components.
Confirm external links, downloads, analytics consent, and redirects use the intended destinations.
Close the editor or preview toolbar when the platform supports it, then repeat the key path as a visitor.

Assume a preview URL may be forwarded. Netlify states that Deploy Preview and branch URLs are accessible to anyone with the link unless password protection or team login is configured. Before sharing:

Determine whether the URL is indexed or publicly reachable.
Enable password protection, team login, VPN access, or another control when the draft is confidential.
Keep preview credentials and draft CMS tokens out of client-side code.
Remove sensitive test data and use a non-production payment, email, and webhook configuration.
Tell reviewers which branch or deployment they are viewing and when it may be replaced.
Revoke temporary access after approval or publication.

6. Capture a shareable visual record

A screenshot lets reviewers compare revisions and leaves an audit trail. Capture the same viewport, URL, and state for each revision. For long pages, use a full-page capture; for a component review, capture the element by selector. If a page contains cookie banners, newsletter popups, or chat widgets, dismiss or hide them before capture so they do not obscure the change.

7. Or skip the browser setup

ScreenshotNeo provides a website screenshot API and MCP server. One GET request returns a PNG, JPEG, WebP, or PDF. Before capture it can accept the cookie or consent banner like a visitor and remove more than 60 known consent platforms, newsletter popups, and chat widgets; each cleanup step can be turned off. Only clean shots are billed: bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and the response identifies the result with X-Page-Verdict and X-Billed headers.

See the ScreenshotNeo API documentation for the complete parameter list. This example captures a preview URL as WebP:

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://example.com/preview \
  -o preview.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com/preview"},
    timeout=90,
)
r.raise_for_status()
open("preview.webp", "wb").write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com/preview'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot failed: ${res.status}`);
const fs = await import('node:fs/promises');
await fs.writeFile('preview.webp', Buffer.from(await res.arrayBuffer()));

Useful preview capture options

Need	ScreenshotNeo configuration
Compare responsive layouts	Choose a device preset or any viewport; set retina scale when reviewing fine detail.
Capture a long landing page	Enable full-page capture; lazy-loaded images are loaded before the shot.
Review one component	Capture one element by CSS selector.
Test theme variants	Set dark mode, custom CSS, or JavaScript.
Wait for app content	Wait for a selector, a delay, or network idle; click an element before capture when needed.
Remove obstructive content	Hide selectors and block ads, trackers, requests, or resource types.
Reproduce a user context	Set headers, cookies, user agent, Authorization, timezone, or geolocation.
Share a public image	Use signed links for public `<img>` tags.
Run many review URLs	Use bulk capture for up to 100 URLs per call.
Keep results consistent	Choose a cache TTL; use async jobs with signed webhooks for longer workflows.
Produce a handoff document	Capture a PDF with paper size, margins, landscape mode, and page ranges.

ScreenshotNeo also supports HTML/CSS-to-image, image resizing, a usage API, an OpenAPI specification, and parameter names used by other screenshot APIs to simplify migration. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients, so an AI agent can inspect a preview without custom browser setup.

Plans: 1,000 screenshots per month are free with no card. Paid plans start at $5 for 3,000 shots; Growth is $15 for 15,000, Pro $39 for 60,000, Scale $99 for 250,000, and Business $249 for 1,000,000. Yearly billing gives two months free, and every feature is included on every plan. Create a free ScreenshotNeo account.

8. Troubleshooting preview problems

Symptom	Likely cause	Fix
Draft text is missing	The preview reads production CMS data or uses the wrong dataset.	Set preview-specific CMS connection variables and verify the draft token and endpoint.
The preview URL shows an old build	The deployment or browser cache is stale.	Confirm the deployment commit, trigger a new build, purge the relevant cache, and use a private window.
Preview works locally but fails in deployment	A missing environment variable, runtime version, or server-only secret.	Compare preview and local configuration, then inspect build and runtime logs without exposing secrets.
Reviewers cannot open the URL	Password, team login, VPN, or an expired deployment.	Check access policy and deployment retention, then issue a new protected URL.
Unpublished content is exposed	The preview is public or draft authentication is disabled.	Enable protection immediately, remove sensitive data, and rotate exposed preview credentials.
Mobile layout differs from the builder	Builder simulation and real browser viewport behavior differ.	Test the actual URL on a device or responsive browser viewport and fix CSS at the failing breakpoint.
Screenshot contains a consent banner or popup	The overlay appears after page load.	Dismiss it, hide its selector, wait for the post-consent state, or use ScreenshotNeo cleanup options.
Screenshot is blank or times out	Client rendering is incomplete, a bot check blocked the request, or the page is unavailable.	Wait for a selector or network idle, check server logs and access rules, and inspect `X-Page-Verdict` and `X-Billed` when using ScreenshotNeo.
Lazy images are absent	The capture occurred before scroll-triggered loading.	Use full-page capture with lazy-image loading or wait for the relevant selector.

9. Performance, reliability, and cost

Keep previews reproducible: pin the branch or commit, use fixed viewport settings, record the URL and timestamp, and keep preview data separate from production where possible.
Reduce review time: capture only changed elements for quick feedback, then take a full-page capture before approval.
Control asynchronous pages: wait for a stable selector or network idle instead of relying only on a short delay.
Control screenshot spend: cache repeated captures with a chosen TTL, batch up to 100 URLs, and monitor usage through the usage API.
Handle failures explicitly: treat bot checks, blank pages, timeouts, and failed loads as review failures even when your workflow continues; ScreenshotNeo does not bill those results and reports the verdict in response headers.
Protect credentials: keep API keys, preview tokens, cookies, and Authorization headers on the server or in a secret manager. Do not put them in public image URLs unless the link is intentionally signed.

10. Publishing checklist

Correct branch, draft, or CMS entry is being reviewed.
Preview data matches the intended unpublished content.
Desktop, tablet, and mobile layouts are checked.
Navigation, forms, media, redirects, and important interactions work.
Accessibility basics and keyboard paths are checked.
Preview URL access is appropriate and credentials are protected.
Production environment variables, analytics, payments, email, and webhooks are not being used accidentally.
Reviewers approved the exact deployment or commit.
Publication target is confirmed before clicking Publish.
Post-publish smoke checks are planned for the live URL.

FAQ

Is a staging site the same as a preview?

They can serve similar purposes, but a preview is often short-lived and tied to a draft, branch, or pull request. Staging is usually a longer-running environment with its own data and access rules.

Only when the content is safe to disclose. Some hosting providers make preview URLs available to anyone with the link by default, so enable password or team protection for private drafts.

Why does my preview show published content?

The preview environment is probably connected to production CMS data, using a production token, or serving a cached response. Verify the preview data source and credentials.

Should I test the live site after publishing?

Yes. A final smoke check catches production-only configuration, DNS, caching, and access differences that a preview cannot reveal.

Can an AI agent review a website preview?

Yes. ScreenshotNeo’s MCP server exposes take_screenshot, get_page_info, and capture_pdf for MCP clients such as Claude and Cursor.