7 steps
From criteria to sign-off — the same process every project.
42 points
The checklist across 6 areas, free to copy and adapt.
4 roles
Builder, peer, content owner, decision-maker — nobody reviews alone.
What a website review is — and what it isn’t
Three activities get mixed up constantly. Separating them is half the discipline.
A website review is the structured check of a web project against defined criteria before it goes live or gets approved. It covers content, design, function, responsiveness, performance basics and legal requirements — and it ends with a decision: approved, or fix list.
It is not QA testing (verifying against technical specs, usually by testers) and not feedback collection (gathering open reactions from clients or users). A good review process contains a slice of both, but its job is different: reach a defensible “this can go live” with evidence.
How it usually happens
“Have a quick look before we launch”
- No criteria — everyone checks whatever catches their eye
- Findings scattered across email, chat and calls
- Nobody re-checks the fixes
- Launch happens because the deadline arrived, not because the review ended
A structured review
Criteria, rounds, record
- A checklist defines what “done” means
- All findings in one place, pinned to the element
- Every fix verified by the reporter
- A documented sign-off ends the review
The 7-step website review
Order matters: every internal step removes findings from the client round — and the client round is the expensive one.
- 1
Define scope and criteria
Decide what this review covers (which pages, which devices, which states) and what “done” means. A review without criteria produces opinions, not results.
- 2
Self-review by the builder
Whoever built the page walks through it once with the checklist before anyone else sees it. Cheap to fix now, embarrassing to fix in the client round.
- 3
Internal peer review
A second pair of eyes from the team — designer checks build fidelity, developer checks function. Internal findings never reach the client’s list.
- 4
Content and data pass
Every headline, price, phone number and legal page against the source material. Content errors destroy more trust with clients than any layout bug.
- 5
Client review round
One link, one deadline, comments pinned to the exact element. The client reviews the real page on desktop and mobile — not a PDF of it.
- 6
Fix and verify
Work the list, mark each point resolved, and have the reporter verify it. A fix nobody re-checks is a bug with a delay.
- 7
Sign off with a record
The review ends with a documented approval: who approved which version, when, with which open points. That record is what ends projects cleanly.
The most common process mistake
42 points across 6 areas
Copy it, adapt it, make it yours. The point is not this exact list — it’s that your review has one.
1 · Content & copy
- All texts final — no lorem ipsum, no “TBD”
- Names, prices, dates, phone numbers against the source
- Spelling and grammar pass (read aloud helps)
- Tone consistent with the brand voice
- All images licensed and credited where required
- Legal pages present: imprint, privacy, terms
- 404 page exists and helps
2 · Design & consistency
- Spacing rhythm consistent across sections
- Fonts, sizes and weights match the design system
- Hover, focus and active states on all interactive elements
- Images sharp on retina displays
- Favicon and social preview image set
- Empty and loading states designed
- Print view not broken (if relevant)
3 · Function
- Every form: submit, validation, error and success states
- Form submissions actually arrive (test the inbox)
- All internal links work, no orphaned pages
- External links open correctly (and are intended)
- Search, filters and interactive elements work
- Third-party integrations run (maps, booking, chat)
- Cookie consent works — and blocks what it claims to block
4 · Responsive & devices
- Real device check: one iPhone, one Android, one tablet
- No horizontal scrolling at any width
- Touch targets big enough (44px+)
- Menus usable on mobile — including submenus
- Images and tables adapt, not overflow
- Landscape orientation not broken
- Text readable without zooming
5 · Performance & SEO basics
- Load time acceptable on 4G, not just office wifi
- Images compressed and modern formats used
- Every page has a unique title and description
- Headings structured (one h1, logical order)
- Redirects from old URLs set (relaunch)
- Sitemap and robots.txt correct, indexing allowed
- Analytics/tracking fires — consent-gated
6 · Legal & privacy
- HTTPS everywhere, no mixed content
- Consent banner before any tracking loads
- Privacy policy matches the tools actually used
- Forms: only necessary fields, clear purpose
- Fonts and embeds GDPR-compliant (no unconsented CDN calls)
- Copyright and image credits where required
- Accessibility basics: contrast, alt texts, keyboard navigation
Who reviews what
Four perspectives, four different findings. The builder finds the compromises, the peer finds the blind spots, the content owner finds the facts, the decision-maker decides.
The builder
Runs the self-review. Knows where the compromises are buried — and checks exactly those spots first.
The peer
Designer or developer who didn’t build it. Finds what the builder has gone blind to after two weeks in the file.
The content owner
Checks facts, tone and completeness against the brief — usually on the client side, before the decision-maker looks.
The decision-maker
Reviews last, decides on the open points, and gives the sign-off. One person — a committee never signs anything.
The step where reviews usually fall apart
Internal passes are disciplined because you control them. The client round needs structure imposed on it — gently.
Three rules keep the client round short. One link: the client reviews the real page in the browser — desktop and mobile — and leaves comments pinned to the element, not described in an email. One deadline: an open review is an open project; 3–5 business days with a named end date works. One list: every finding lands in the same place, gets a status, and is verified by the person who reported it once fixed.
The quality of the round depends on the quality of the comments. “Something feels off on the About page” is not reviewable — which element, on which device, compared to what? This is exactly where guided feedback pays for itself: when vague comments get a clarifying follow-up question the moment they’re written, the fix list arrives buildable instead of interpretable.
Run the whole review on the live page
With bepeq, your client reviews the real site — desktop, tablet, mobile — and pins comments to the exact element, no login. The Pilot asks follow-ups on vague notes, rounds have deadlines, and the sign-off generates its own record.
Start bepeq for freeSign-off record generated automatically
Version: staging.clientsite.com
Jul 8, 2026 · 2:32 PM · IP recorded
2 open points (category B) with a deadline
Related guides and templates
Website Feedback
How to collect client feedback that you can actually build.
Website review tool
The software side: run a multi-stakeholder review to a documented approval.
Website QA testing
The testing engine inside the review: 6 test types, device matrix, bug reports.
Website redesign checklist
40 points across 5 phases for relaunch projects specifically.
Online proofing
Approvals in rounds instead of email threads.
Common questions about website reviews
What is a website review?
A website review is the structured check of a web project before it goes live or gets approved: content, design, function, responsiveness, performance and legal basics are verified against defined criteria, findings are collected in one place, fixed, re-checked — and the review ends with a documented sign-off.
How is a review different from QA testing?
QA testing verifies against technical specifications — does the form validate, does the API respond, does it work in every browser. A website review is broader and involves non-technical reviewers: it also judges content, consistency and fitness for purpose, and it ends with a business decision (the approval), not a test report.
Who should review a website before launch?
At minimum four perspectives: the person who built it (self-review), a colleague who didn’t (peer review), whoever owns the content (fact check), and the decision-maker who signs off. On small projects one person may hold two of those roles — but never all four.
How long does a website review take?
For a typical 5–10 page site: the internal passes take half a day, the client round needs a deadline of 3–5 business days, and fixing plus verification another 1–2 days. The biggest time sink isn’t the checking — it’s chasing vague feedback. Pinned, structured comments cut the total roughly in half.
What belongs in a website review checklist?
Six areas: content and copy (facts, spelling, legal pages), design consistency (spacing, fonts, states), function (forms, links, integrations), responsive behavior (real devices, both orientations), performance and SEO basics (speed, titles, indexability), and privacy/legal (consent, imprint, encryption). The 42 points on this page cover all six.