A website preview gives you somewhere to check a change before customers see it. Ask for a working review link, agree what it includes, and approve a specific version. Then check the published site on your real domain. These are separate decisions: a good preview reduces uncertainty, but does not prove that the launch worked.
This guide is for business owners reviewing a new site or redesign with a designer. The useful question is whether customers can complete their task, and which parts still depend on the live environment.
Know what the preview can prove
A design image can show layout, colour and wording. It cannot prove that navigation, enquiry delivery or a checkout works. A working preview can demonstrate those interactions, provided the designer has connected or safely simulated them. Ask which you are looking at before giving approval.
A staging site is a separate test environment. WordPress.com describes staging as a way to test major changes before applying them to production. The implementation depends on the host; do not assume every temporary link has the same controls or copies the same data.
For a small brochure site, a review copy of the pages may be enough. A shop with changing orders needs a plan for data as well as appearance. Ask the developer to identify what will move at launch, what will stay live, and how recent customer activity will be protected. A whole-site copy is not automatically the right release method.
Agree who can enter and what tests can do
A hard-to-guess link is still a link someone can forward. If the preview contains unpublished material, ask for access restrictions and check it while signed out. Prefer sample enquiries and products for review. Do not copy private customer records merely to make a demonstration feel realistic.
Cloudflare Pages documents preview URLs and access controls. This is one platform example, not a promise that your designer's preview is private. Confirm the actual setup.
Search exclusion and privacy also need separate checks. Google's noindex guidance explains that a crawler must be able to read the rule; blocking crawling can prevent that. A noindex instruction does not require a visitor to log in. Ask the designer how the review site is restricted and how the public site will become eligible for indexing at launch.
Before testing an enquiry or order, agree the destination and mode. Use a clearly marked test message to an agreed inbox only when authorised. Confirm that payments, customer notifications, stock changes and external systems cannot trigger unintended real actions. An unconnected button should be labelled as awaiting integration rather than passed as working.
Review a buyer's route on a phone and computer
Start on the page a customer is likely to enter, not only the homepage. Find a relevant product or service, understand the offer, and reach the intended next step. Do this on your own phone as well as a computer. A resized screenshot cannot show how a menu opens or whether a keyboard covers a form.
Use the same route in each agreed language. Check that the switch opens the corresponding page, the contact details remain correct and downloads use the intended language. For a catalogue, include a long product name, a missing photograph and a product with several variants, if those cases belong to the agreed scope.
| Review item | Evidence worth keeping | Decision |
|---|---|---|
| Customer can find the right offer | Page address and steps followed | Pass, or describe where the route breaks |
| Contact route works in the agreed test mode | Test reference and confirmed destination | Pass only the part actually tested |
| Mobile content remains usable | Device, page and screenshot of any issue | Fix hidden text, blocked controls or sideways page movement |
| Facts and materials are approved | Current wording, prices and image references | Confirm the version the business accepts |
These are review suggestions, not a universal certification. If you find a problem, record the address, what you did, what happened and what you expected. “On this phone, opening the menu hides the contact button” gives the designer something reproducible. “Mobile feels wrong” does not.
Approve a version and list the launch differences
Keep one issue list with an owner and a clear outcome for each item. Separate changes needed for launch from later requests. If wording or images change after approval, review the affected pages again and identify the replacement version.
An illustrative approval note might say: “Approve the review version dated 10 November, subject to resolving issue 4. This covers the listed pages and mobile menu. Contact delivery on the live domain remains to be tested.” Use your actual scope and date. This is a practical record, not a legal template.
Before launch, ask for a short list of differences: domain, access restrictions, search settings, enquiry destination, payment mode, analytics and any redirects. Each applicable difference needs an owner and a check. Agree when content editing pauses and how new orders or enquiries are handled during the change. Also agree who can restore the previous version if a critical route breaks; the backup and restore guide covers that separate preparation.
Check the published domain before calling it finished
Open the real address in a fresh browser session. Repeat the important customer route, check the final contact details and confirm that links no longer lead to the review site. Have the responsible person verify the production settings from the launch-differences list. A successful upload message is evidence of deployment, not proof of every customer-facing outcome.
For a redesign, check important old addresses too; the redesign SEO checklist covers search routes in more detail. For an enquiry form, confirm receipt through the agreed test process, rather than relying only on a success notice. The form delivery guide explains the distinction.
Record what passed and any remaining limitation. If the page is published but enquiry delivery is still untested, say exactly that. Close or restrict the review copy according to the agreed retention plan, and keep the approval record with the release details. Completion should describe what a customer can actually do on the live site.
