Client sign-off before a website launch: a guide for agencies
Updated 6 min readBy the DNSPeek team
Get client sign-off by showing the client the finished site on the real server, collecting their feedback in one place, and recording an explicit approval with a name and date before you switch DNS. Agree up front what “approved” covers and who can give it. Back the request with evidence that the site is ready, such as a QA crawl and a visual comparison with the old site.
Why sign-off goes wrong
Launch disputes rarely come from bad work. They come from ambiguity: the client reviewed a staging URL that differed from production, feedback arrived in five email threads and a call, someone senior saw the site for the first time after launch, or “looks good” in a chat message was taken as approval. A sign-off process removes that ambiguity.
- One version: the client reviews the site on the server it will launch from, not a staging copy.
- One place for feedback: comments tied to the exact page and element they are about.
- One approver, named in advance, with authority to say yes.
- One record: who approved, when, and what state the site was in.
Agree what sign-off covers
Write down, before review starts, what approval means. A short list in the project brief or statement of work is enough:
| Area | Client confirms | Agency confirms |
|---|---|---|
| Content | Text, images and legal pages are final | Content placed as supplied |
| Design | Layout on desktop and mobile is as agreed | Matches approved designs |
| Functionality | Forms, checkout and sign-in behave as expected | Tested with test data |
| Technical readiness | Accepts the launch date and the risks listed | QA report clean, redirects mapped, backups in place |
Name the approver and a deputy. Agree how many review rounds are included and that changes after approval are a new request. This protects both sides.
The sign-off process
Step 1: Agree scope and approver
Write down what approval covers, how many review rounds are included, and who approves.
Step 2: Deploy to the production server
Put the final build on the server it will launch from, with DNS still pointing at the old site.
Step 3: Share a password-protected preview
Create a preview link for the domain and the new server IP, set a password, and send it to the client.
Step 4: Collect pinned feedback
Turn on client comments so the client pins feedback to the page and element; resolve each comment as you fix it.
Step 5: Run the checks
Run a QA report and a visual compare, fix what they find, and share the results or a launch readiness report.
Step 6: Ask for explicit approval
Ask the named approver to click Approve launch, or to confirm in writing against the exact preview link.
Step 7: Freeze and launch
Freeze changes after approval, switch DNS, and keep post-launch requests on a separate list.
Collect feedback in one place
On the Agency and Provider plans, turn on client comments for the preview link. A Comments button appears on every page of the preview. The client clicks a spot, writes a comment, and it is pinned to that element as a numbered marker; general notes can apply to the whole page. They do not need an account. You get an email when comments arrive, at most one every ten minutes per link, and you resolve each one in the dashboard when it is done. Details: Client comments and launch approval.
Anyone with the link can comment
Comments are open to everyone who can open the preview. Use a password so feedback stays between you and the client.
Show evidence that the site is ready
Clients approve faster when they can see the checks were done. Free tools cover the basics, such as the certificate with the SSL checker and redirects with the redirect checker. Three things help most:
- A QA report: a crawl of the new server for broken pages, missing files, redirect problems, mixed content and email DNS gaps, with a score. On the Agency and Provider plans the shared report carries your branding. See QA report.
- A visual compare: screenshots of key pages on the old and new site, desktop and mobile, with the differences highlighted (paid plans). See Visual compare.
- A launch readiness report: one page with a verdict (not ready, ready with warnings, ready to launch) built from the latest QA report, visual compare, open comments, the client’s approval and a certificate check. It is a snapshot the client opens without an account. See Launch readiness.
Record the approval
With client comments on, the client clicks Approve launch and enters a name, optionally with an email and a note. You get an email, the link settings show who approved and when, and the launch readiness report names the approver under the verdict. If you work without the comments feature, ask for approval by email in reply to a message that links the exact preview and lists the scope, and keep that thread with the project.
After approval, freeze changes. Anything the client asks for next goes into a post-launch list unless it blocks the launch. Then switch DNS following the website migration checklist.
Sign-off checklist
Before you ask for sign-off
- Sign-off scope written in the brief or statement of work
- Approver and deputy named
- Final build on the production server
- Preview link password-protected and sent
- Client reviewed on desktop and on a phone
- All client comments resolved or moved to post-launch
- QA report run, critical findings fixed
- Visual compare reviewed for unexpected differences
- Launch readiness verdict shared
- Explicit approval recorded with name and date
- Change freeze agreed until the launch
Frequently asked questions
What is website sign-off?
Website sign-off is the client’s explicit confirmation that the site is ready to launch as reviewed. It records who approved, when, and what was approved, so both sides agree on the state of the project at launch.
Should clients review on staging or on the production server?
On the production server when you can. Staging copies drift from production, so approving staging does not prove the live site will look the same. A preview link lets the client see the production server before DNS points at it.
Does my client need an account to comment or approve?
Not with DNSPeek client comments. The client opens the preview link, pins comments and approves the launch with a name and an optional email. Protect the link with a password so only the client can comment.
What if the client keeps asking for changes after approval?
Treat changes after approval as new requests, as agreed in the scope. Fix anything that blocks the launch, and put the rest on a post-launch list with its own estimate.
Can the sign-off page carry my agency’s branding?
On the DNSPeek Agency and Provider plans, QA reports and launch readiness reports show your logo, colour, footer and contacts. Set them up once in the branding settings.