A client website review checklist, from first look to sign-off

A review link and the words “let us know what you think” leave a lot to chance. One person checks spelling. Another redesigns the homepage. Nobody tries the contact form.

A useful review gives people a shared route through the website and a clear way to record what needs attention. Use this checklist for a client review of a staging site, then adapt it to the pages and decisions that matter for your project.

This is a practical content and usability review. It does not replace a full accessibility assessment, security review, performance test or technical release checklist. Agree who owns those checks separately.

Before you open the review

Choose one coordinator to collect decisions and one client representative who can approve the work. Other reviewers contribute within an agreed area: for example, marketing checks copy and brand, while an operations lead checks contact details and enquiry routing.

Write down:

• The exact website URL and version being reviewed.
• The pages included in this round.
• What has already been approved.
• The deadline for comments and the person making final decisions.
• Where all feedback should be recorded.

Ask reviewers to use fictional information in test forms. Confirm which actions are safe on staging before submitting anything: a test enquiry can still send a real notification or create a record in a connected system.

For the complete process, use our guide to running a client website review.

1. Check the content against approved facts

Read the website as a potential customer. Can you understand what the business offers, who it helps and what you should do next?

• Business name, contact details and opening hours are correct.
• Service and product descriptions match the approved scope.
• Prices, dates and availability have an identified owner who confirms them.
• Headings describe the content that follows.
• Placeholder copy and test content have been removed.
• Spelling, punctuation and terminology are consistent.
• Images have permission for their intended use and describe the correct subject.
• Testimonials and other proof have been approved by the responsible person.

2. Follow the navigation as a visitor

• Menu labels make sense without an explanation from the project team.
• The logo and home link return to the expected page.
• Important calls to action go to the intended destination.
• Footer links and links within page content work.
• Visitors can find contact information from the main pages.
• Download links point to the approved file.
• Error and empty states explain what to do next.

Record the journey that failed, rather than just the broken element. “On the services page, the consultation button opens the old booking page” gives the team a useful starting point.

3. Review the mobile experience

Use a real phone when one is available, alongside the team's browser checks. Identify the device and browser in feedback so someone else can reproduce the issue.

• Text remains readable without zooming.
• Content fits the viewport without unexpected horizontal scrolling.
• Navigation opens, closes and permits access to its links.
• Buttons and links are easy to select without hitting neighbours.
• Images preserve important content when cropped.
• Sticky banners do not cover page content or form controls.
• Essential information appears in a sensible order.

4. Check forms and confirmations

Only submit forms after confirming that the test is permitted and knowing where the submission goes.

• Every field has a clear label and required fields are identified.
• Instructions explain any unusual information being requested.
• Errors identify the affected field and explain how to correct it.
• A successful submission displays a useful confirmation.
• The responsible person verifies the permitted test arrived correctly.
• Follow-up expectations are accurate and approved.

Treat payments, bookings and external account changes as separate test activities with explicit instructions. Do not complete a real transaction as part of a casual content review.

5. Flag accessibility issues you can observe

• You can move through links and controls using a keyboard.
• The currently focused control is visible.
• Links describe their destination in context.
• Information is understandable without relying on colour alone.
• Text remains usable when enlarged.
• Meaningful images have appropriate text alternatives.

Record concerns for the accessibility owner. A checked list is not a compliance claim.

Turn findings into a release decision

Separate launch blockers, required corrections and possible improvements. Give every required correction an owner, then check the revised page before closing it. Our website feedback examples show how to turn a vague concern into a request someone can act on.

Copy this note into the review record:

Website and version:
Review scope:
Review coordinator:
Final decision owner:

Launch blockers:
Required corrections and owners:
Accepted limitations:
Follow-up improvements:

Corrections rechecked by:
Separate technical checks confirmed by:
Decision: Approved / Approved with conditions / Further review needed
Conditions or remaining work:
Decision recorded by:
Date:

Sign-off should identify the actual decision, its scope and any conditions. Silence at the end of a review is an unresolved decision; ask the named approver to record the outcome.