How do I let a content editor preview changes on the real site design before publishing?

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

A lot of content management systems show you a preview that's close to, but not quite, what the live page will actually look like, which is exactly how typos and layout problems end up live: the editor approved what they saw, and what they saw wasn't the real thing. Netlify's Preview Servers fix this specific gap by running an actual live copy of your site in development mode, with a stable link, so a reviewer sees genuinely real-time changes on the genuinely real design, not an approximation.

How this differs from your CMS's own preview

A typical CMS preview renders your content through a simplified template, which is usually close enough for text changes but can miss custom components, specific spacing, or anything that depends on code outside the CMS's own content model. A Preview Server instead runs your actual development environment, meaning what the reviewer sees is produced by the same code that will eventually go live, not a CMS's best guess at what that code will do with the content. For a lighter alternative, see reviewing website changes before they go live.

The real usage limits, which matter more than people expect

One Preview Server is included on Free, Personal and Pro plans, with additional ones on Pro costing $15 a month each. The Free plan specifically caps usage at 2 hours a day and 62 hours a month total, with the server automatically shutting down after 30 minutes of being idle, which resets your session the next time you need it. This matters in practice: if your team treats a Preview Server like an always-on staging environment rather than something you spin up for an active review session, you'll burn through the Free tier's hours fast, and the idle shutdown means you can't just leave it running in a background tab all day expecting it to stay warm.

One more real constraint: Git Contributors (a specific collaborator role on Netlify) cannot access Preview Servers, so make sure whoever actually needs to review content has the right access level before they try to open the link and hit a wall.

Step by step: setting one up

1. Confirm your plan includes at least one Preview Server (Free, Personal and Pro all include one; Pro lets you add more at $15/month each).
2. A developer sets up the CLI connection, which is the real technical step here; this isn't a no-code toggle, it needs someone comfortable with Netlify's command-line tooling to get the development environment running and linked.
3. Share the stable preview link with whoever needs to review content, confirming they have the right collaborator role (not Git Contributor) to actually open it. For sharing with clients, see getting client approval on a real website.
4. Treat it as a session, not a permanent environment, especially on Free: use it for the active review, then let it idle out rather than relying on it being always-on.

When a normal CMS preview is simpler

If your team is small and the main thing you're previewing is text and image changes within a standard CMS template, your CMS's own built-in preview (WordPress's, for example) is usually good enough and needs no developer involvement at all. Reach for a Preview Server specifically when the gap between what the CMS preview shows and what actually ships has caused real problems, custom components rendering wrong, layout breaking in ways the CMS preview never showed, not as a default upgrade for every content review. Weighing WordPress against Netlify is covered in Netlify vs WordPress hosting.

A worked example: a marketing team catching a broken layout before it shipped

A SaaS company's marketing team used their CMS's standard preview to approve a new pricing page layout with a custom comparison table component, a table that wasn't part of the CMS's own content model and rendered as a simplified placeholder in the built-in preview rather than the real component. The content looked fine in that preview, got approved, and went live, at which point the real comparison table rendered with broken column widths on mobile that nobody had actually seen before customers did, since the CMS preview had never shown that component correctly in the first place.

After that incident, the team set up a Preview Server specifically for any page using a custom component, reserving it for those pages rather than every routine text edit. A content editor making a small copy change on a standard blog post still uses the CMS's own preview, which is genuinely sufficient for that case. Anything touching the comparison table, a custom pricing calculator, or another non-standard component gets reviewed through the Preview Server instead, catching layout issues before launch rather than after a customer notices. The team tracks which pages fall into which category in a simple shared note, so editors know without guessing which review path a given change needs. After approval, the live site can rebuild on its own, see updating your website automatically after CMS edits.

A practical note on keeping Free-tier usage under control

If you're on the Free plan's 2-hours-a-day, 62-hours-a-month allowance, build a habit of explicitly closing the preview session once a review is done rather than just switching browser tabs and leaving it running in the background. Since the server shuts down automatically after 30 minutes idle anyway, the practical risk isn't usually one person forgetting, it's several people on the team each spinning up their own session for small, separate reviews across the day, which adds up faster than a single sustained review session would. A shared calendar or quick heads-up in your team's chat before someone spins up a session helps avoid two people unknowingly running separate sessions for the same review at the same time, which wastes hours from the shared allowance for no real benefit.

What I'd actually tell you

This is the right tool when your site has enough custom design and components that a generic CMS preview genuinely misleads your editors about what's about to go live, and wrong when your CMS's own preview already does the job. I'd only set this up once you've actually had a real incident, something approved in preview that looked wrong once it went live, rather than preemptively, since the setup needs a developer and the usage limits mean it's not a casual, always-on tool on anything below Pro.

How I'd approach this

When I build a custom site with non-trivial design on top of a CMS, I check early whether the CMS's native preview is going to mislead editors, and if it will, I'd rather set up a proper Preview Server from the start than wait for the first embarrassing live mistake to force the issue. For a smaller team on simpler content, I'd leave this alone entirely and trust the CMS's own preview, since the added setup and the usage caps genuinely aren't worth it below a certain level of design complexity.