THE SHORT ANSWER
Start with the customer tasks agreed in the scope. Check the actual words and interactions, keep a clear issue list and say exactly what you are approving. Save the final launch decision for the checks that require the real domain.
Establish what is ready to test
Ask whether you are reviewing a picture, a clickable demonstration or a functioning version of the proposed site. Find out which parts are complete and which are still placeholders. That prevents a visual signoff from being mistaken for a test of unfinished functionality.
Keep the original scope beside the preview. It should help you distinguish a missing agreed feature from a new idea. Both can be worth discussing, but they have different implications for the work still to do.
Ask how test forms, bookings and other actions are handled in this environment. Do not assume a preview cannot send a real message or create a live appointment. Use a supported test process and coordinate with anyone who may receive the result.
Try the tasks before judging the decoration
Start where a visitor is expected to arrive. Find a relevant service and work toward the next step. If the intended action is a quote request, follow that route instead of only clicking the navigation across the top.
Use a phone as well as a larger screen. Read the text without zooming to compensate for a poor layout. Check whether a banner covers the contact button or whether the page moves as you try to select something.
Ask somebody unfamiliar with the business to try a suitable task without coaching them through it. Note where the explanation fails them. You know the service names and where everything was placed; a new visitor does not.
For a preliminary keyboard check, see whether you can reach the relevant controls and follow visible focus. W3C's Easy Checks guide explains this kind of first review and its limits. Passing it is not proof of complete accessibility.
Approve the facts separately
Read service descriptions, hours, locations and any response promises against the business's actual operation. Assign the factual check to someone who can confirm the answer. A designer should not decide your service area from a map of nearby towns.
Check images and captions together. A photograph should show what its caption claims. A demonstration concept should be labeled as one. Our VEYRA and Milehouse Garage pages are independent fictional concepts, not evidence of client endorsements or business results.
Look for leftover example copy and links that go nowhere. A generic phone number can be easy to miss once it sits inside a polished design. Make unresolved facts a launch issue rather than something everyone assumes another person has checked.
Write feedback somebody can act on
Keep the page address and describe what you did, what happened and what you expected. For example: after selecting the contact link on a phone, the form is hidden beneath the banner. That is a useful example of a report, not a finding about your current site.
Separate errors from preferences and additional requests. A wrong address needs correction. A different photograph may be a preference. Adding a customer account area is a scope conversation. Putting all of them in one undifferentiated list makes the next step harder to agree.
Combine feedback from the people who need to review the site. Have one person return a clear list with any internal disagreements resolved or identified. Contradictory instructions about the same button are not a productive revision plan.
After an update, reopen the affected page and repeat the relevant task. Ask the developer to show what changed when the result is not obvious. Checking the repair matters more than marking the original message answered.
Say what this approval covers
Before signing off, ask for the remaining launch checks. Some things need to be checked again on the public domain, including the actual contact route and any links carried over from the old site. Agree who performs those checks and handles a failure.
W3C recommends clear feedback about form submissions, including whether they succeeded or need correction. During your review, read the exact message and ask whether it describes what happened. A request received is not the same as an appointment confirmed.
A design approval, acceptance of finished functionality and permission to change the live site need not be treated as the same decision. Use wording that matches the project's actual process. Record what is complete and what still has to be demonstrated.
Your Page's working-preview process is intended to give that discussion something concrete to refer to. Bring the agreed scope and the issue list. The preview should let you respond to a real page, not guess what a pile of design terms will eventually look like.