In this article
Title
Why most pre-launch reviews miss things
The average pre-launch review happens in one of two ways. Either the client gets a link, pokes around for twenty minutes, and sends a few Slack messages. Or you schedule a call, share your screen, and work through the site together while taking notes in a separate doc.
Both approaches have the same problem: no structure. Without a checklist, reviews default to whatever catches the eye first. The hero looks great so nobody checks the footer. The homepage gets reviewed three times and the contact form never gets submitted once. The mobile layout on the team page gets missed entirely because nobody thought to switch devices.
A structured checklist forces the review to cover every area, not just the obvious ones. It also gives the client a framework for the kind of feedback that's useful at each stage. "The copy on the services page feels a bit formal" is actionable. "Something feels off" is not.
Run this checklist before every launch, either as a self-review before the client sees the site, or as a structured client review using a tool like Annot where feedback gets pinned directly to the relevant element on the live site.
The checklist
1. Copy and content
Copy problems are the most common and the most embarrassing to fix after launch. Read every word on every page before signing off.
Pages and headings
Every page has a clear heading that describes what the page is about
Page titles are unique and descriptive, not generic ("Home," "Page 1")
Heading hierarchy makes sense (H1 followed by H2, not H1 jumping to H4)
No placeholder text remains anywhere on the site ("Lorem ipsum," "Your text here," "Coming soon")
Body copy
All body copy has been proofread for spelling and grammar
Tone is consistent across all pages
Technical jargon has been explained or simplified for the intended audience
No copy refers to outdated information (old pricing, discontinued products, past events)
Legal disclaimers, privacy policy, and terms of service are present and accurate
Contact and team details
Business name, address, phone, and email are correct on every page they appear
Team member names, titles, and bios are approved by the relevant people
Social media handles are correct and the linked accounts are the right ones
2. Images and media
Images
All images are high resolution and not pixelated on retina displays
No stock photo watermarks remain
Images are compressed for web without visible quality loss
Image alt text is present on all meaningful images (both for accessibility and SEO)
Decorative images have empty alt attributes so screen readers skip them
Video and audio
Embedded videos play correctly and are not set to autoplay with sound
Video captions are present where required
Video thumbnails are set and look correct
Favicons and brand assets
Favicon is set and displays correctly in the browser tab
Open Graph images are set for social sharing previews
Logo appears correctly on all pages and links back to the homepage
3. Navigation and links
Navigation
All navigation links go to the correct pages
The active page state is visible in the navigation
Mobile navigation opens, closes, and links correctly
Dropdown menus work on both hover and touch
Skip navigation link is present for keyboard and screen reader users
Internal links
Every internal link on the site has been clicked and goes to the right destination
No internal links go to a 404 page or redirect to an unexpected location
Anchor links (scrolling to a section on the same page) work correctly
External links
External links open in a new tab where appropriate
All external links resolve to the correct destination
No broken external links
Buttons and CTAs
Every button on the site does something
CTA buttons go to the correct destination or trigger the correct action
Button states (hover, active, disabled) are visible and consistent
4. Forms
Forms are the most commonly skipped part of a pre-launch review and the most likely to cause problems after launch. Submit every form on the site before signing off.
Submission and confirmation
Every form has been submitted with valid data and the submission was received correctly
Confirmation messages appear after successful submission
Confirmation emails arrive in the submitter's inbox (check spam too)
Form submissions arrive at the correct email address or CRM
Validation
Required fields show an error message when left empty
Email fields reject invalid email formats
Phone fields handle different formats without breaking
Error messages are clear and tell the user what to fix, not just that something is wrong
Edge cases
Forms have been tested with very long inputs (long names, long messages)
Forms have been tested with special characters in text fields
Multi-step forms save progress correctly if the user navigates back
5. Responsiveness and mobile
This section is where most agencies spend the least time and where clients notice the most problems after launch. Test on real devices where possible, not just browser dev tools.
Breakpoints
The site has been reviewed at desktop (1440px+), laptop (1024px), tablet (768px), and mobile (375px) widths
No content overflows its container at any breakpoint
No text is too small to read on mobile without zooming
No buttons or tap targets are too small to tap comfortably on a touchscreen (minimum 44x44px)
Layout
Columns stack correctly on smaller screens
Images scale proportionally and do not stretch or crop unexpectedly
Padding and spacing remain readable at all breakpoints
The navigation collapses into a usable mobile menu
Content parity
No content is hidden on mobile that is visible on desktop without good reason
Content that is hidden on mobile has been intentionally removed, not accidentally broken
6. Interactions and animations
Animation-heavy sites built in Webflow, Framer, or with custom JavaScript need a dedicated pass for interactions. These are the elements most likely to break in a standard screenshot-based review because they only exist in motion.
Scroll and trigger-based animations
Scroll-triggered animations fire at the correct scroll position
Animations play once rather than looping unexpectedly
Animations do not cause layout shifts that push content around while the page loads
Hover states
All hover states on buttons, links, cards, and interactive elements are visible and intentional
Hover states work correctly on touch devices (they should not get stuck)
Custom interactions
Sliders, carousels, and tabs work correctly and all panels are accessible
Custom cursors or pointer effects work as intended and do not cause lag
Any WebGL or canvas-based elements render correctly at different screen sizes and device pixel ratios
Reduced motion
Animations respect the
prefers-reduced-motionmedia query for users who have requested reduced motion in their system settings
7. Performance
A slow website is not a finished website. Check load times before presenting a site as ready for launch.
Page speed
Core Web Vitals have been checked using Google PageSpeed Insights or equivalent
Largest Contentful Paint (LCP) is under 2.5 seconds on a simulated mobile connection
Cumulative Layout Shift (CLS) score is below 0.1 (no elements jumping around as the page loads)
Images are served in modern formats (WebP or AVIF where supported) rather than uncompressed JPEGs and PNGs
Scripts and fonts
Third-party scripts (analytics, chat widgets, tracking pixels) are loading without errors
Web fonts are loading correctly and fallback fonts are set
No unnecessary scripts are loading on pages that do not use them
8. SEO basics
This is not a full SEO audit, but these are the basics that should be in place before launch.
Meta and structure
Every page has a unique, descriptive meta title
Every page has a meta description
H1 tags are present and there is only one H1 per page
The canonical URL is set correctly
Technical
The sitemap is generated and submitted to Google Search Console
The robots.txt file is configured correctly and not blocking search engines accidentally
SSL certificate is active and the site loads over HTTPS
Redirects from the old site are set up if this is a redesign
9. Accessibility
Accessibility is not optional. These are the most common issues that appear on web builds and the easiest to check before launch.
Colour contrast
All text passes WCAG AA contrast ratio requirements (4.5:1 for normal text, 3:1 for large text)
Interactive elements like buttons and form fields are distinguishable from the background
Keyboard navigation
The entire site can be navigated using a keyboard alone
Focus states are visible on all interactive elements
No keyboard traps (elements that capture keyboard focus and do not allow the user to leave)
Screen readers
Images have appropriate alt text
Form fields have associated labels (not just placeholder text)
ARIA roles and landmarks are used correctly where semantic HTML is not sufficient
10. Browser and device testing
Browsers
The site has been tested in Chrome, Firefox, Safari, and Edge
The site has been tested in Safari on iOS, which has the largest mobile market share in most Western markets
Devices
The site has been tested on at least one Android device and one iPhone
If the site targets older browsers or devices, those have been tested explicitly
11. Final checks before going live
Accounts and access
The client has been given admin access to the CMS, hosting, and domain
All developer or agency accounts have been removed or set to the appropriate permission level
Domain is pointing to the correct hosting environment
Analytics and tracking
Google Analytics or equivalent is installed and verified to be receiving data
Conversion tracking (form submissions, purchases, clicks) has been tested and is firing correctly
Cookie consent banner is in place and compliant with GDPR or applicable regulations
Backups
A backup of the site exists before going live
The client knows how to access backups if something goes wrong after launch
How to run this checklist with your client
The most effective way to use this checklist is to split it into two passes.
The first pass is your internal review, done before the client sees anything. You work through every item yourself, fix what you find, and only send the site for client review once it passes. This saves everyone time and avoids the awkward situation of a client finding a broken form that you should have caught first.
The second pass is the client review. Rather than emailing this checklist to the client and asking them to mark things off, give them a structured way to leave feedback on the live site. Share an Annot review link and ask them to focus on the copy and content sections specifically, since those are the areas where client knowledge is irreplaceable. Design, layout, and technical items are yours to own.
Scope the client review clearly. Ask for feedback on copy and overall direction in round one. Save responsiveness and interaction checks for a separate pass if needed. Focused rounds produce better feedback than open-ended "let me know what you think" reviews.
When the client leaves feedback, it gets pinned to the exact element on the live site rather than arriving as a vague email. That means less back-and-forth clarifying which button, which page, which section.
Common questions
Should the client work through this whole checklist themselves?
No. Most of this checklist is for you, not your client. The sections on performance, accessibility, SEO, and technical checks are internal quality gates you should own. Share the copy and content section with clients and ask them to review the site using a structured feedback tool. Asking a non-technical client to run a Lighthouse audit wastes their time and yours.
When in the project timeline should this be done?
Two passes. One internal review at least a week before the planned launch date, so there is time to fix anything significant. One client review after that, with a clear deadline for feedback. Launching without both passes is how post-launch emergencies happen.
What if the client keeps finding new things after the review is signed off?
Scope it clearly in your contract. Define what counts as a revision (changes to agreed scope) versus a new request (changes to things that were reviewed and approved). A signed review checklist is useful evidence if a scope conversation comes up later.
Do I need a separate tool to run this checklist, or can I use a spreadsheet?
A spreadsheet works for the internal pass. For the client review portion, a visual feedback tool like Annot is more effective because it keeps feedback attached to the specific element rather than living in a separate document. When a client marks something as done in Annot, the context of what they were pointing at is preserved alongside their comment.
What about e-commerce sites?
Add a dedicated checkout and payment testing section. Every step of the purchase flow should be completed with a test transaction: add to cart, enter shipping details, apply a discount code, complete payment, receive confirmation email. Payment failures and checkout bugs are among the most damaging post-launch issues and the easiest to find in a pre-launch review.
The short version
Most post-launch fixes were visible during review. A structured checklist run in two passes (internal first, then client) catches the things that get missed when review is unstructured. Own the technical sections yourself. Give clients a focused, scoped review of the areas where their knowledge matters. Pin feedback to the live site so nothing gets lost in translation.
Related reading: How to run a client website review without a single email and how to use Annot MCP with Claude to apply feedback automatically.