Key Takeaways
- Agree acceptance criteria before the final review so everyone knows what the website must do.
- Test realistic customer and staff tasks on the actual release candidate, not only a prototype or isolated page.
- Record expected results, observed results and evidence, with a named owner for each issue.
- Distinguish launch blockers from lower-risk follow-up work and make any accepted limitations explicit.
- Design approval, content approval, technical verification and permission to launch are separate decisions.
A website redesign sign-off should confirm that the agreed work has been checked and is ready for the intended release. It should not depend on a business owner spotting every possible technical problem during a quick tour of the homepage.
The project team needs a shared checklist, clear responsibilities and evidence from realistic tasks. The business owner then makes an informed acceptance decision about the exact version tested.
If the scope is still being agreed, our website redesign proposal checklist covers what belongs in the brief. This article deals with the final review and the practical questions to ask before launch.
Define What You Are Signing Off
Separate the decisions. You may approve the visual design while copy is still being reviewed. You may approve content while a form integration remains unfinished. Neither necessarily means the website is ready to go live.
Write down the scope of the final acceptance: pages, features, content, integrations and any work deliberately excluded. Identify the preview URL or release version being reviewed.
If the candidate changes after testing, record the change and decide which tests need repeating. Approval of yesterday's version should not silently become approval of a different build.
A website audit and consultation can help define the evidence required, but the project should have a named release decision-maker rather than an assumption that somebody else has approved it.
Turn Requirements into Customer Tasks
Use tasks a real visitor would recognise. “Find out whether this service covers my situation and send an enquiry” is better than “click the blue button”.
Include the main paths that matter to the business: choosing a service, checking relevant proof, contacting the team, booking where applicable and finding essential practical information.
GOV.UK's moderated usability-testing guidance describes observing people completing tasks and using neutral instructions. The principle applies well to a business website: test the service, not the participant's ability to follow hints.
Do not turn a small acceptance session into a claim that the site has been comprehensively tested with every audience. Record who tested it, which tasks were covered and what remains outside that review.
Use a Simple Evidence Table
Keep the checklist readable enough for the business and development team to share. Each item should have an expected outcome, observed result and status.
| Test | Expected result | Evidence to retain |
|---|---|---|
| Submit a valid enquiry | Correct confirmation and delivery | Test reference and destination check |
| Submit an invalid form | Clear, usable correction message | Screenshot and browser details |
| Edit a service paragraph | Correct preview and public update | Before-and-after record |
| Open a protected page without access | Access is refused | Controlled access test |
| Follow an important old URL | Correct relevant destination | Response and destination record |
Avoid a column containing only ticks with no explanation of what was tested. A short note is often enough, but it should make a failed result reproducible.
Keep personal information out of general project screenshots and use labelled test data where appropriate. Evidence should help verification without creating an unnecessary privacy problem.
Check Content as a Business Responsibility
Review names, services, prices where shown, contact details, opening information and claims. The developer may be able to confirm that text renders correctly without knowing whether it is commercially accurate.
Check images and captions together. Confirm permissions for client work and testimonials, and ensure an illustrative image is not presented as documentary proof of a real project.
Read the important pages on a phone. Awkward headings, repeated introductions and unclear calls to action can be easier to spot in the actual layout than in a content document.
Assign a business owner for content approval. Do not leave factual sign-off hidden inside a technical testing ticket.
Verify the Whole Enquiry Journey
Submit a controlled test from each important form or booking route. Check required fields, validation, confirmation, delivery and assignment to the correct team.
A success message proves only that the interface displayed a message. Confirm that the enquiry is present in the intended inbox or CRM and that any notification or task behaves as agreed.
Test failure behaviour too. If a connected service is unavailable, does the site preserve the request safely or explain the problem honestly? The visitor should not be told an appointment is confirmed when only an enquiry has been sent.
After launch, repeat the critical checks in the production environment under an agreed test procedure. Preview success does not prove that production credentials, domains and integrations are correct.
Include Accessibility Checks Without Overclaiming
Check keyboard use, visible focus, headings, form labels, text alternatives, contrast and zoom behaviour as part of the review. Include assistive-technology testing where the scope and expertise support it.
The W3C's Easy Checks resource is a useful first review, but it explicitly does not provide a complete accessibility evaluation. An automated score is not proof that every user can complete the site's tasks.
Our website accessibility audit guide explains the broader assessment. Be clear about whether the project included a specialist audit, a limited review or only basic checks.
Record known barriers and their impact. A missing focus state on a critical control is not merely a cosmetic preference for someone relying on keyboard navigation.
Test Representative Devices and Content
Use the agreed browser and device coverage, including mobile. Check the common page templates and the content most likely to stress them: long headings, missing optional images, tables and forms with errors.
Review menus, sticky elements, overlays and external embeds. A calendar or chat widget can behave differently after navigation than on the first page load.
Check both direct visits and navigation between pages. Some issues appear only when a component mounts again or retains state from the previous page.
Keep the test scope proportionate, but explicit. “Tested on mobile” should identify what was tested rather than implying every device and browser combination.
Check Staff Editing and Ownership
Ask the actual content team to carry out routine changes using their normal accounts. They should be able to find content, understand fields, preview changes and follow the agreed publishing process.
Check permissions and recovery. Can a writer accidentally change global settings? Can an editor restore a mistaken change? Who manages access when a staff member leaves?
Confirm ownership of the domain, hosting, code, content system and relevant integrations. The business needs an understandable handover, not a collection of accounts controlled only by an individual supplier.
Our website redesign service treats editing and handover as part of delivery. A website that looks complete but cannot be maintained is not a complete operational handover.
Include Technical Release Evidence
Ask the technical team for the checks relevant to the project: build and type checks where applicable, important routes, redirects, metadata, sitemap behaviour and monitoring.
For private content, verify access control directly. A noindex instruction is not a password gate. Test unauthorised access as well as a successful authorised visit.
Keep SEO migration checks in their own detailed workstream rather than trying to squeeze them into a visual review. Our professional website audit checklist helps distinguish the areas that need evidence.
The business owner does not need to personally run every technical test. They do need a clear report of what passed, what failed and who verified it.
Classify Issues by Impact
Agree a simple severity system. A launch blocker prevents a critical task, exposes information or creates a serious incorrect commitment. A significant issue may affect an important group or journey. A minor issue may be suitable for an agreed follow-up.
Do not use severity to hide disagreements. Describe the observed behaviour and business impact first, then decide the priority together.
For each accepted limitation, record the owner, planned resolution and reason it is acceptable for this release. “We will fix it later” without a date or owner is not a useful acceptance record.
Retest fixes on the integrated candidate. A developer saying an issue is fixed is a prompt to verify the result, not the final evidence by itself.
Keep Launch Approval Explicit
The final record should identify the release version, completed checks, outstanding items and the person authorising launch. It should also state the release window, monitoring responsibilities and recovery plan.
Do not assume that a comment approving the latest design also authorises a production deployment. Keep those decisions distinct so neither the business nor the supplier has to infer permission.
Arrange a post-launch check of the critical journeys and an agreed support period. Website maintenance and support should make it clear where an issue is reported and who responds.
Before signing off, ask one final question: can another person read the record and understand exactly what was accepted? If the answer is yes, the approval is much stronger than a message saying the site looks great.
Frequently Asked Questions
Is approving the design the same as approving launch?
No. Design, content, technical verification and production release are separate decisions. Make the scope and authority of each approval explicit.
What should a business owner test personally?
Focus on real customer tasks, factual content and the staff editing workflow. Ask the technical team to provide evidence for checks requiring specialist tools or expertise.
Should every minor issue delay the website launch?
Not necessarily. Classify issues by impact and record any accepted limitations with an owner and resolution plan. Critical task failures, serious incorrect commitments and access-control problems need particular attention.
Does a good automated accessibility score prove the site is accessible?
No. Automated checks cover only part of the picture. Combine appropriate manual and user testing, and state clearly whether a specialist accessibility assessment was included.
What belongs in the final sign-off record?
Identify the exact release candidate, tests and evidence, unresolved items, release authorisation, monitoring owner and recovery plan. Repeat critical checks after deployment in the production environment.
