Getting a client's sign-off on a website before it goes live

Why approvals unravel

The usual story: the client forwards a marked-up screenshot, a colleague replies-all with a different idea, and the designer applies the last thing they heard. Weeks after launch someone asks why the prices moved, and nobody can show who asked for it.

Approval is really an agreement about a specific thing: this version, these pages, this copy, checked by this person, on this date. If any of those is fuzzy, you don't have sign-off, you have a mood. So the practical answer to how to get client approval on a website design is to make each of them concrete before you ask.

Settle the rules before the first link goes out

• One named approver. Other people at the client can comment, but one person gives the final word and resolves disagreements. Put their name in the contract or the kickoff notes.
• A fixed number of rounds. Two is common for a small site: one for direction and content, one for corrections. Say what happens after that (a new round is quoted separately).
• What approval covers. Layout, wording, images, the contact details and the legal pages. Clients often skim the Privacy Policy and Terms; Anticode writes a starting version of each from what the site does, but it isn't legal advice, so the client should read and accept them as part of sign-off.
• A turnaround. Ask for consolidated comments within a set number of working days, so a review doesn't drift for a month.

The sign-off sequence

1. Do your own pass first. Read every page on a phone and a laptop. In Anticode, run the release checklist, which runs every publish check without publishing, so the client never reviews a page that would fail the design gate or a security check.
2. Note the candidate version. Saves are kept as versions in version history (the most recent ones, up to a number set by your plan). Write down the time or version number of what you're sending; that's the thing being approved.
3. Make a client review link. From the project, create a review link to the current preview. The client opens it without an account. It expires after 14 days by default and you can revoke it at any time.
4. Send it in your own email. Say what to look at, what's out of scope for this round, the deadline, and who the approver is. Anticode doesn't send this message for you.
5. Collect comments in one place. On the review page each comment is tied to a section, so "the pricing section" arrives as exactly that rather than "the bit near the bottom". Ask the client to channel colleagues' views through the link, not by separate email.
6. Consolidate before you change anything. Group comments by section, flag the ones that contradict each other, and agree each conflict with the approver. Send back a short list: doing, not doing and why, needs a decision.
7. Apply the changes. Most are a sentence each as a change request ("move the opening hours above the map"); wording fixes are quicker in the visual editor. Check each one in the preview.
8. Send a second link for confirmation and revoke the first, so nobody comments on an old preview.
9. Record the yes, then publish. Ask the approver to reply in writing that the site is approved for launch. Note the version number beside their reply in your project notes, and publish that version.

What the approval email should say

Keep it short and specific so the reply is unambiguous. A good request names the review link, lists what changed since the last round, and asks a closed question: "If you're happy for this version to go live on Thursday, please reply to confirm." A good reply is one line that says yes to that version. If the approval happens on a call, follow it with an email that summarises what was agreed and ask for a one-word confirmation.

What goes wrong, and the fix

How you know it worked

You can answer three questions in under a minute: which version went live, who approved it, and when. Every review comment has been handled or answered, the old links no longer open, and the published site matches the version noted beside the approval. If any of that fails, fix the step before the next project.

What Anticode handles and what stays with you

Anticode provides the review link, comments tied to sections, change requests, version history and the publish checks. Everything contractual is yours: the number of rounds, the approval email, the invoice that follows sign-off. The review page collects comments; it doesn't record a formal approval or signature, so the written yes lives in your email or project tool. For the wider project around this step, see the freelance web design process and how to handle revision rounds.

Questions people ask

Does the client need an Anticode account to review the site?

No. A client review link opens the current preview for anyone who has it, without signing in. Anyone who has the link can comment, so send it only to the client team.

How long does a review link last?

Fourteen days by default, and you can revoke it sooner. Make a fresh link for each round.

Can I go back to the version the client approved?

Yes. Version history lets you preview an earlier save and restore it; the restore is added as a new version, so the later versions stay in the list. Only the most recent versions are kept, up to your plan's number, so restore soon rather than months later. Publish again to put it live.

Is a reply to an email enough as sign-off?

For most small projects, yes, provided the email names the version and the scope. If your contract asks for a signature, collect it with your usual contract tool.