Preview links: review the change before it is live
Every change to your site gets its own private web address before it reaches the live site. What a preview link is, how to open one on a phone and a laptop, what to check, and how to send feedback that turns into a fix in one round. Fully referenced.
There is a moment in every website job where someone says “can I see it?” Our answer is a link. Every change we make to your site gets its own web address before it touches the live site. You open it on your phone and your laptop, you tell us what is wrong, and the fix arrives on the same link. This post explains what that link is, what to look at, and how to write feedback we can act on in one go.
What a preview link is
We host your site on Cloudflare Pages, the same platform that runs this one. Cloudflare’s description of the feature is short: “Preview deployments allow you to preview new versions of your project without deploying it to production”[1]. Production is the version of your site the public sees. A preview is a complete copy of the site with one change in it, on its own address, that the public does not see.
The addresses are generated automatically. “Each new branch you create will receive a new, randomly-generated hash in front of your pages.dev subdomain”[1]. A branch is a named line of work in the code, such as “new pricing page” or “fix the phone number in the footer”. Each one gets its own preview, so two changes never get mixed up on one link. Cloudflare also keeps a readable alias for each branch and “updates it so that the alias always maps to the latest commit of that branch”[1]. In plain terms: the link you were sent on Monday still works on Wednesday, and shows Wednesday’s version.
This comes with the pipeline, not as a special setup for each job. When a Pages project is connected to its code repository, “Cloudflare will automatically deploy your code every time you push a change to a branch”[2], and the connection provides “Preview URLs in pull requests (PRs) to the repository”[2]. A pull request is the container the change lives in. GitHub defines it as a proposal to merge code changes into a project, “letting you discuss and review changes before merging them”[3]. Merging is the step that moves the change from the preview to the live site, and it does not happen until the review is done.
Why the link is private
A half-finished version should never turn up in Google. Cloudflare adds a header to every preview that tells search engines to stay away: each preview deployment carries “the X-Robots-Tag: noindex HTTP response header”[1], and the platform “by default ensures your search rankings are not harmed by these temporary previews”[1].
Where a site needs more, the addresses can be locked. Cloudflare notes that “By default, these deployment URLs are public. Enabling the access policy will restrict viewing project deployments to your Cloudflare account”[1]. We use that for work that must not be seen early, such as a rebrand. For most marketing sites the random address plus the no-index header is enough, and you can forward the link to a colleague without them needing an account.
Where previews sit in the job
Our Build stage runs with staged previews as they land, and two structured feedback rounds[4]. The first round is about design direction: does this look like your business, is the structure right, is anything missing. The second is the final round of changes before launch[4]. Between the rounds you will still see previews, because every change produces one, but the rounds are where we gather everything you have noticed into one list and work through it.
At Launch you sign off on the live site[4]. Because you have already seen every page on a preview, launch day is a check that the live address matches the last preview you approved, not a first look. If something goes wrong after launch, Cloudflare keeps the earlier versions: “Rollbacks allow you to instantly revert your project to a previous production deployment”[5]. The last good version is always one step away.
Open it on a real phone
A preview link is an ordinary web address, so it opens in any browser. Open it on your laptop first, then on your phone. Do the phone one on a real phone, not a laptop window made narrow.
The simulators developers use are approximate by design. Chrome’s device mode is described by Google as a way “to approximate how your page looks and performs on a mobile device”[6]. Its documentation is candid about the limits: “With device mode you don’t actually run your code on a mobile device. You simulate the mobile user experience from your laptop or desktop”[6]. Google’s advice is the same as ours: “When in doubt, your best bet is to actually run your page on a mobile device”[6]. We test on real devices before we send you a link. You testing on yours, with your thumb, on your network, catches what we could not.
What to check
You do not need to know anything about code to do a useful review. The World Wide Web Consortium’s accessibility group publishes a set of quick checks that are “designed for anyone who can use the web. You don’t need much knowledge or skill”[7]. The table folds the ones that matter most for a marketing site in with the ordinary checks of copy, links and forms.
| What to check | How | What to send us |
|---|---|---|
| Copy | Read every page slowly. Names, phone numbers, prices, opening hours, spelling. | The page, the wrong words, the right words. |
| Links | Tap every link and button, including the logo, the footer and the phone menu. | The page, which link, and where it went instead. |
| Forms | Fill in the contact form with a real email address and send it. Then try sending it empty. | Whether the message arrived, and a screenshot of any error. |
| On a phone | Scroll each page. Does text run off the edge, do images crop badly, can you tap the menu? | Phone model and a screenshot. |
| Page titles | Look at the browser tab. Each page should have its own title; it is “the first thing screen readers say”[7]. | The page and the title you saw. |
| Headings | Do the headings describe what follows? Keyboard users “navigate to the headings”[7]. | The page and the heading. |
| Contrast | Is any text hard to read against its background?[7] | The page and a screenshot. |
| Text size | Zoom the browser to 200%. Everything should still read and nothing should overlap[7]. | The page and a screenshot at 200%. |
| Keyboard | On the laptop, press Tab repeatedly. You should see where you are and reach every link and field[7]. | The page and where the highlight vanished. |
| Form labels | Does every field say what it is for, and does an error tell you what to fix?[7] | The field and a screenshot. |
These accessibility checks are deliberately simple. The W3C is clear that “These checks cover just a few accessibility issues and are designed to be quick and easy, rather than definitive”[7]. We do the fuller work on our side. Your pass is a second pair of eyes.
Feedback that becomes a fix in one round
The difference between a fix that takes one round and one that takes three is almost always in how the problem was described. “The menu is broken” could mean six things. Four details remove the guesswork:
- Which page. Paste the address from the preview link, or name the page as it appears in the menu.
- Which device. Phone or laptop, and which phone.
- What you expected. “I expected the Contact button to open the form; it scrolled to the top instead.”
- A screenshot. On a phone it takes two seconds and shows us exactly what you saw, including the screen width.
Send those four in whatever tool you already use. Email is fine. If the problem is a wrong word, send the correct sentence in the same message and we will use it as written.
Each fix arrives on the same preview link, because the branch alias always points to the latest version[1]. Reload, tick the item off, move on. When the list is empty, the pull request is merged and the change becomes the live site. GitHub’s view is that a pull request brings together “the context reviewers need to understand a change”[3] and helps teams “track feedback, and decide when the pull request is ready to merge”[3]. Your review is part of that record.
After launch, the same rule
The preview link does not end on launch day. Once you are Live, you send content changes when you need them, and we run the deployment pipeline[4]. A changed price or a new team page follows the same path: a branch, a preview link, your look, then live. The habit you build during the two feedback rounds is the habit that keeps the site right for years.
If you are planning a site and want to see how a build runs from brief to live, the brief builder takes three minutes and comes back with a fixed price. For what a preview is made of, why we build with React and how we keep JavaScript small explain the parts, and the home page measurements show the result.
Reference list
All sources accessed 21 April 2026.
- Cloudflare (n.d.) Preview deployments. Cloudflare Pages documentation. https://developers.cloudflare.com/pages/configuration/preview-deployments/
- Cloudflare (n.d.) Git integration. Cloudflare Pages documentation. https://developers.cloudflare.com/pages/configuration/git-integration/
- GitHub (n.d.) About pull requests. GitHub Docs. https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests
- Dispatch Web (2026) What you get at each stage. dispatchweb.com.au. https://dispatchweb.com.au/#process
- Cloudflare (n.d.) Rollbacks. Cloudflare Pages documentation. https://developers.cloudflare.com/pages/configuration/rollbacks/
- Google (n.d.) Simulate mobile devices with device mode. Chrome for Developers. https://developer.chrome.com/docs/devtools/device-mode/
- W3C Web Accessibility Initiative (n.d.) Easy Checks – A First Review of Web Accessibility. W3C. https://www.w3.org/WAI/test-evaluate/preliminary/