Two deployments, two different facts
A preview proves the change builds and renders on a real host. Production proves the change is live for visitors.
Neither proves the change was a good idea. That is what the measurement window is for.
A filled check
Ridgeline Roofing, one pull request that rewrote three titles.
pull request: #412, branch sitearc/title-rewrite-service-pages
preview url: https://ridgeline-git-title-rewrite.example.vercel.app
checked: 2026-09-12, 16:20 America/New_York
build
1. build resolved, no error, 41 pages generated
2. the three changed pages load on the preview host
content
3. each changed page has one h1 and a written title
4. the titles name the service, not the company
5. the canonical on each page points at https://ridgelineroofing.example
indexing
6. the preview host serves no sitemap
7. robots.txt on the preview host disallows everything
8. the change touches three files, and the diff names only those
decision: merge. The preview proves the change renders and stays
out of the index. It says nothing about the result.
after merge: read 28 days from the merge commit
Match the preview to the pull request
The repository connection answers which preview belongs to which pull request. Without it, a preview URL is a link somebody pasted into a comment.
Acceptance: the preview is usable evidence when
- the build resolved from the commit under review
- each changed page renders on the preview host
- the canonical still points at production
- the preview host is excluded from the index, by robots or by rule
- the diff names only the files the change claimed
- the check has a date and a person
Troubleshooting
| Symptom | Likely cause | What to do |
|---|---|---|
| The preview serves a sitemap | The build does not exclude the host | Add the rule before sharing the link |
| The preview 404s on a changed page | The route was renamed | Check the diff, then the route |
| Canonical points at the preview host | The origin came from the environment | Set the production origin in the build |
| Two previews, one pull request | A push after the first build | Use the newest, and note the commit |
| Everything looks fine and production breaks | The preview used different data | Compare environment names, then test on staging |
Limits
This page describes the evidence, not a hosting provider’s features. Deployment settings belong to your own project.
An audit of a preview reads your own site and spends no credits. A crawl that renders JavaScript does spend credits, and it is priced before it runs.