See how Vercel preview deployments and Netlify deploy previews give stakeholders a shareable URL to review an AI-drafted blog post before you merge.
A pull request review works for the person who reads Markdown diffs for a living. It does not work for the founder, marketer, or exec who needs to know one thing: does the new post look right. A preview deployment answers that question directly. Instead of asking a non-engineer to parse a diff, you hand them a live URL, and they see the actual rendered page, headings, images, and links included, exactly as it will look after you merge.
This matters most for a Git-based AI blog writer workflow, where an AI drafts the post as a Markdown file and opens a PR for you to review. The PR proves what changed. A preview deployment proves what it looks like. Vercel and Netlify both build one automatically, and the two implementations differ enough that which platform you're on changes how you'd wire this up.
Here's a concrete version of that gap. This post moved through the exact workflow it describes: Lyra drafted it on a branch named lyra/blog-preview-deployments-for-ai-blog-content, the naming convention every Lyra-authored pull request uses, then opened a PR adding one new file, content/blog/preview-deployments-for-ai-blog-content.md. On a repo wired to Vercel or Netlify's Git integration, a PR shaped exactly like that is what triggers the preview build the next section walks through, before anyone on the team has read a line of the diff.
A preview deployment is a full build of your site, generated from a branch or a pull request, served at its own throwaway URL that never touches production. Anyone with the link opens it in a browser and reviews the same rendered page a reader would see after merge.
A Markdown diff shows exactly what text changed, line by line. What it doesn't show is whether the finished page renders correctly: whether the hero image loaded, whether a heading broke the layout, whether an internal link actually resolves to the post it's supposed to. Those are rendering questions, and a diff viewer answers none of them.
That gap is exactly why Slack screenshots became the workaround at a lot of teams before preview deployments were standard, and why we've argued a scoped GitHub pull request beats a Slack thread for keeping a durable, enforced review record. A preview URL is the missing piece that makes the PR itself sufficient: the reviewer still approves in GitHub, but they form their opinion by clicking a link and looking at the actual page, not by mentally rendering Markdown in their head.
On both platforms, a preview URL points at a complete, independently-hosted build, not a sandboxed diff view or a screenshot. It runs the same framework code, the same styling, the same images that production would serve. The only difference from the live site is the domain and the fact that merging is still required before the change reaches your actual readers.
Getting from "the AI opened a pull request" to "a stakeholder has a URL to click" takes zero configuration on the default path, and a bit more if you want the preview reading from a separate content environment.
If your blog already deploys through Vercel or Netlify's native Git integration, this step requires nothing new. The moment an AI writer, or any contributor, opens a pull request with a new .md file in content/blog/, the platform's existing Git hook fires, builds the branch, and posts the preview link back to the PR automatically. This is also why a properly scoped AI writer needs no deploy-platform permissions of its own: a GitHub App scoped to Contents and Pull requests is enough to open the PR, because Vercel or Netlify's separate Git integration is what actually triggers the build, not the writer's app.
Vercel creates a preview deployment by default whenever you push a commit to a branch that isn't your production branch, open a pull request on GitHub, GitLab, or Bitbucket, or run vercel from the CLI without --prod (Vercel). Two separate URLs come out of that: a branch-specific URL that always points at the latest commit on the branch, useful for a reviewer who wants to keep refreshing the same link as you push fixes, and a commit-specific URL locked to one exact deployment, useful when you want to link a reviewer to precisely the version they approved.
If your team eventually wants a longer-lived staging tier that isn't tied to any single PR, Vercel's Pro plan includes one Custom Environment per project beyond Preview and Production, and Enterprise gets twelve (Vercel). Most teams reviewing individual blog posts don't need that; the per-PR preview already does the job.
Draft Mode is a different tool solving a different problem, and it's worth being precise about the difference. It was called Preview Mode before Next.js 13.4, and Vercel renamed it specifically to stop teams confusing it with preview deployments (Vercel). Draft Mode exists for a site that pulls content from a headless CMS through Incremental Static Regeneration (ISR): it lets you bypass the ISR cache and see an unpublished CMS entry rendered with your site's real styling, without waiting for a revalidation window to expire.
Under the hood it checks a __prerender_bypass cookie against a cryptographically-secure bypassToken generated at build time, and access is locked down by design. "Only team members will be able to view pages in Draft Mode," Vercel's documentation states plainly, and a viewer outside your Vercel team can't enable it or see draft content even with a draft URL carrying the ?__vercel_draft=1 query parameter (Vercel). Team members toggle it from the eye icon in the Vercel Toolbar, which turns purple once Draft Mode is active.
For a Git-based blog where a post is a Markdown file in the repo, not a row in a headless CMS, you usually don't need Draft Mode at all. The post already gets its own full preview deployment the moment the PR opens, no ISR route or bypass cookie required. Draft Mode earns its place if your blog's content genuinely lives in a separate CMS and only the layout comes from the repo.
Netlify Deploy Previews are automatically created when a pull or merge request is opened on a connected GitHub, GitLab, Bitbucket, or Azure DevOps repo, provided the base branch is a production branch or has branch deploys enabled (Netlify). The URL follows a predictable pattern, deploy-preview-{PR_NUMBER}--{site-name}.netlify.app, so a reviewer can guess a colleague's preview link from the PR number alone. Every deploy also gets a permanent, immutable deploy-ID URL whose contents never change after that build, useful for pointing back at exactly what was approved even after newer commits land on the same PR.
If you have deploy notifications enabled, Netlify also posts a comment with the preview link directly on the pull or merge request once the build finishes, and reflects build status on the PR the same way a CI check would (Netlify). As Netlify's own docs put it: "Deploy Previews allow you and your team to preview, review, and experience changes to any part of your site without having to publish them to production."
If your blog's build reads content, images, or config from an external source rather than purely from the repo, both platforms let you swap that source for preview builds specifically. Netlify supports environment variables scoped to the Deploy Previews context through its UI, CLI, API, or the netlify.toml file, so a preview build can point at a staging CMS or API while production keeps reading from the live one (Netlify). Vercel's Custom Environments give you the equivalent capability for a longer-running staging tier, each with its own environment variables, on Pro and Enterprise plans (Vercel).
For a purely Git-based blog, where the post is a Markdown file committed straight into the PR, this step is usually unnecessary. There's no separate content source to point at; the preview build already reads the exact file the PR added.
A preview URL turns review into a five-minute pass over the actual page instead of a mental simulation of one. The checklist is short precisely because a preview answers most of it visually.
Open the preview URL and read the post the way a visitor would: does the hero image load, do headings break at sensible points, does the body copy match the voice of the rest of the blog. Then click through every internal link the post added; a broken or misrouted link is invisible in a Markdown diff but obvious on a live page. This is a lighter, human version of the same check a GitHub Actions link-checking job would run automatically before merge, and the two are complementary rather than redundant, one gate for CI, one for a human's eyes.
Both platforms let a reviewer leave feedback directly on the rendered page instead of switching back to the PR to describe where something looks wrong. Vercel Comments are enabled by default on all preview deployments, for all account plans, letting anyone on the team comment directly on copy, components, or interactions, opening discussion threads that notify the PR owner and every participant by email as the conversation continues (Vercel). Netlify's equivalent is the Drawer built into every Deploy Preview, opened with Cmd+\ on Mac or Ctrl+\ on Windows and Linux with no plugin to install, where a reviewer can leave comments, screenshots, and even video feedback, and check how the post looks at different screen sizes.
Netlify also supports a custom entry path for a preview, set through the Drawer or by adding an @netlify /path directive to the PR description, which is a small but real convenience: a reviewer lands directly on the new post instead of the homepage every time they open the link.
Access control looks different on each platform, and it's worth knowing which model you're actually running. Vercel preview deployments and Draft Mode are restricted to members of your Vercel team by default; there's no separate password to distribute. Netlify Deploy Previews support optional password protection instead, which is the right call if you need to share a preview link with someone who has no account on either your Netlify team or your Git provider, an outside stakeholder or a client, for instance. Basic password protection for an entire site is available on Netlify's Pro plan and above, but protecting only the non-production deploys, keeping production public while the preview stays gated, is an Enterprise-only setting (Netlify). A Pro team that turns on password protection is locking the whole site, not just the preview, so check which scope you actually need before you flip the switch.
A preview URL makes review easier. It doesn't replace the merge as the actual publish gate. Nothing a stakeholder does on a preview deployment, clicking through the post, leaving a comment, giving a verbal thumbs-up, changes the state of the pull request itself. The post only goes live when someone with merge rights approves the PR and clicks merge, the same rule that applies whether an AI or a person wrote the file. That distinction is worth restating because it's also, in Google's words, the whole point of keeping a human gate in the pipeline in the first place: its scaled content abuse policy targets pages produced mainly to rank rather than help users "no matter how it's created" (Google), a standard our post on Git-based AI writers covers in more depth. A preview link that never gets a merge is just a page nobody approved yet, and that's exactly how it should work.
A preview deployment is the fastest way to get a non-engineer's honest reaction to an AI-drafted post before it ships, and Lyra's pull requests work with whichever platform builds yours.
FAQ
A full build of your site that Vercel creates automatically when you push a commit to a non-production branch, open a pull request on GitHub, GitLab, or Bitbucket, or run `vercel` without the `--prod` flag. Every preview gets a branch-specific URL that always points at the latest commit on that branch, plus a commit-specific URL for one exact deployment, so a reviewer can open a real, rendered page without touching production.
A build Netlify creates automatically for every pull or merge request on a connected GitHub, GitLab, Bitbucket, or Azure DevOps repo, as long as the base branch is a production branch or has branch deploys enabled. The URL follows the pattern deploy-preview-{PR_NUMBER}--{site-name}.netlify.app, and if you have deploy notifications enabled, Netlify posts that link back to the PR as a comment once the build finishes.
No. Draft Mode is scoped to your Vercel team by design. Vercel's own documentation is direct about it: 'Only team members will be able to view pages in Draft Mode,' and a viewer outside the team cannot enable it or see draft content even with a draft URL carrying the `?__vercel_draft=1` query parameter.
Usually not, for a Git-based blog. Draft Mode solves a different problem: viewing unpublished content from a headless CMS on an already-live, ISR-cached page without waiting for the cache to clear. A Markdown post that lands as a new file in a pull request already gets its own full preview deployment the moment the PR opens, no ISR or bypass cookie required.
Set environment variables scoped specifically to the Deploy Previews context, through the Netlify UI, CLI, API, or the netlify.toml configuration file. That context-specific value overrides the production one only for preview builds, so a preview can read from a staging CMS or API without any code branching.
Built by the tool you're reading about
Lyra finds the topics worth ranking for, writes them in your repo's voice, fact-checks every claim, and opens a pull request scored and ready to merge. You review and hit merge. Want to see what she'd write for you? Start free with three posts, no card.
Keep reading
XML sitemap AI crawlers explained: GPTBot and ClaudeBot only started requesting sitemap.xml in March 2026, what it means for getting new posts found.
AI crawler log analysis reveals GPTBot and ClaudeBot hits your JS analytics miss. Read server logs, verify bot IPs, and spot a crawl-but-no-citation gap.
AI content pipeline security means guarding against prompt injection: hostile source data hijacking an AI writer to leak keys or publish false claims.