The website feedback checklist: what to review before you sign off

Most website reviews fail in one of two ways. Either the reviewer looks at the homepage, says “looks great”, and the problems surface after launch. Or the reviewer sends forty comments about font sizes while nobody checks whether the contact form actually sends email.

A checklist fixes both. It spreads attention across the whole site instead of the first screen, and it separates the things that block launch from the things that are taste.

Below is the checklist we’d hand to anyone reviewing a site — a client, a project manager, a designer doing a final pass. Copy it, cut what doesn’t apply, and work through it page by page.

Before you start: set up the review

A review is only as good as its scope. Agree on three things before anyone opens the site:

Which pages are in scope. List them. “The whole site” on a 60-page build means the homepage gets reviewed five times and the privacy policy never.
What kind of feedback you want this round. Early rounds are about structure and content. Late rounds are about bugs and polish. Asking for “everything” invites a mix that’s hard to act on.
Where feedback goes. One place. Not email plus a spreadsheet plus a chat thread. If your team uses a tool that pins comments to the page, everyone uses it; if it’s a shared document, everyone uses that.

Also note the review environment — the URL (staging or live), and which devices and browsers you’ll check on. Write it down at the top of your notes.

1. Content and copy

Content problems are the most common and the cheapest to fix before launch.

Every page has real content — no lorem ipsum, “TBC”, placeholder images or sample names
Headlines say what the page is about, not just something clever
Spelling and grammar checked on every page, including buttons, menus, footers and error messages
Names, job titles, prices, addresses, phone numbers and opening hours are correct
Dates are current (copyright year, “last updated”, event dates)
Product and brand names are written consistently (capitalisation, spacing, trademarks)
Calls to action are clear and use the same wording for the same action across the site
Legal pages (privacy, terms, cookies) exist and are linked where required

Tip: Read copy on the actual page, not in the source document. Line breaks, truncated cards and orphaned words only show up in the layout.

2. Layout and visual design

This is where reviews tend to drift into personal taste. Anchor your comments to the agreed design.

Pages match the approved designs — spacing, alignment, colours, typography
Headings follow a consistent hierarchy (one main heading per page, sensible sizes below)
Images are sharp, correctly cropped and not stretched
No text sits on top of an image where it becomes hard to read
Icons are consistent in style and size
Repeated components (cards, buttons, form fields) look the same everywhere
Empty states look intentional (a blog with no posts, a search with no results)
The favicon and page titles in the browser tab are correct

If something feels off but you can’t say why, describe what you see and what you expected: “The three cards in this row are different heights, so the buttons don’t line up” is actionable. “This section feels unbalanced” is not.

3. Responsive behaviour

A site that’s perfect at 1440 pixels wide can fall apart on a phone. Check at least three widths: a large desktop, a tablet, and a phone.

Navigation works on every width — the mobile menu opens, closes and links correctly
No horizontal scrolling on phones
Text is readable without zooming; nothing is cut off
Tap targets (buttons, links, form fields) are big enough and not crammed together
Images and videos resize instead of overflowing
Tables either fit, scroll inside their container, or reflow
Sticky headers and pop-ups don’t cover the content on small screens

When you leave a responsive comment, always say which width you were looking at. “The button overlaps the image” is unclear; “At phone width, the button overlaps the image” saves a round trip. Tools with desktop, tablet and phone previews make this easier because the comment is tied to the width it was left on.

Every link in the main menu and footer goes to the right page
No broken internal links (404s)
External links open the intended destination
The logo links to the homepage
Buttons that look clickable are clickable — and things that aren’t buttons don’t look like them
Anchor links (jump-to-section) scroll to the right place
A custom 404 page exists and helps people find their way back
Email and phone links open the mail app or dialler with the right details

5. Forms and interactive elements

Forms are where a site makes or loses money, and they’re often reviewed last, if at all.

Every form can be submitted with valid data, and the submission arrives where it should (inbox, CRM, spreadsheet)
Required fields are marked, and the error messages say how to fix the problem
Validation works: invalid emails, missing fields, overly long input
The confirmation message or page appears after submitting
Auto-reply emails (if any) are correct and branded
Sliders, tabs, accordions and carousels work by mouse, touch and keyboard
Search returns sensible results
Checkout or booking flows work end to end in test mode

Write it down when it works, too. “Submitted the contact form at 2:15pm, no email received” is far more useful than “contact form broken”.

6. Accessibility basics

You don’t need to be an accessibility specialist to catch the most common problems.

You can reach and use every interactive element with the keyboard alone (Tab, Shift+Tab, Enter, Space)
There’s a visible focus outline when tabbing
Images that carry meaning have alternative text; decorative images don’t clutter screen readers
Text has enough contrast against its background, including text on images and buttons
Links make sense out of context (“Download the price list”, not “Click here”)
Form fields have visible labels, not just placeholder text
Videos have captions; nothing auto-plays with sound

7. Performance and technical basics

Some of these are for the development team, but a reviewer can flag the symptoms.

Pages load reasonably fast on a normal connection, including on a phone
Large images are compressed and sized for the web
Every page has a unique, descriptive title and meta description
Social sharing previews (the image and text when a link is pasted into chat) look right
The site works over HTTPS without security warnings
Analytics and cookie consent behave as agreed
Redirects are in place for any old URLs that are changing

How to turn the checklist into useful feedback

A checklist tells you what to look at. How you report what you find decides whether it gets fixed.

Point at the exact thing. The single biggest time-waster in website feedback is ambiguity about location. “The second button” depends on screen width. If you can, pin the comment directly on the element — tools like ClientTweak let reviewers click an element on the live page and comment on it, so the location is never in doubt. If you’re working in a document, include the page URL and a screenshot with the problem circled.

One issue per comment. A comment that says “fix the spacing, change the photo, and the price is wrong” will get one of three things fixed. Split it.

Say what you expected. “The headline is wrong” → “The headline says ‘Summer sale’, but the campaign is called ‘Seasonal sale’.”

Mark what blocks launch. Use priorities. A broken checkout is high priority; a photo you’d like swapped is low. Developers will fix them in a different order — and they should.

Separate preference from problem. “I’d prefer a warmer image here” is valid feedback, but say it’s a preference so it can be weighed against time and budget.

A copyable summary

If you only take one thing from this article, take this short version and paste it into your next review brief:

Area	Ask yourself
Content	Is every word correct, current and final?
Layout	Does it match the approved design on this page?
Responsive	Does it work at desktop, tablet and phone width?
Links	Does every link go where it should?
Forms	Does every form submit, validate and confirm?
Accessibility	Can I use it with a keyboard, and read everything?
Technical	Titles, speed, HTTPS, redirects, analytics

Work through it page by page, leave one clear comment per issue, and flag what blocks launch. You’ll catch the problems while they’re still cheap — and your sign-off will actually mean something.