Website launch checklist: 60 checks before go-live, as a free template
A free website launch and QA checklist for agencies: content, responsive, links, forms, SEO, speed, accessibility, legal, tracking and launch day. Word download or copy it
The HopBack teamOctober 20269 minutes read
Key takeaways
A website launch checklist is the list of things that have to be true before a site goes live, checked by a named person, in an order that catches the expensive mistakes first.
The one below has 60 checks in twelve groups, from content and responsive layout through forms, search, speed, accessibility, legal, tracking and the launch itself, with a short after-launch list for the week that follows.
It is written for an agency launching a client's site, so it separates the agency's technical pass from the client's content pass and ends with a sign-off rather than a vague "looks good".
Launch problems are rarely technical surprises. They are things somebody assumed somebody else had checked: the contact form that posts to a test address, the staging site still blocking search engines, the phone number nobody tapped on an actual phone, the placeholder paragraph on the one page the client never opened. Each is a thirty-second check. Together they are the difference between a launch and a week of apologies.
A checklist works because it removes the assumption. It names the check, and the download names who does it. The agency runs the technical and SEO groups, because the client cannot see them. The client runs the content group, because the agency cannot know whether the pricing is right. Both run the responsive and forms groups, because that is where the two sets of eyes find different things.
Where issues are logged: (one review link, comments pinned to the page; not email)
1. Content
Every page in the sitemap exists and has final copy. No lorem ipsum, no "coming soon", no "TBC".
Names, titles, prices, addresses, opening hours and phone numbers are correct and current. The client checks these, not the agency.
Spelling and grammar checked on every page, including the footer, the 404 page and form confirmation messages.
Images are the final, licensed versions. No stock watermarks, no placeholders, no photos the client has not approved.
Every image has alt text that describes it, and decorative images are marked as such.
Dates are right: the copyright year, any "founded in" or "since" claims, event dates.
Legal and policy pages are the client's own wording, reviewed by them, not the template text.
2. Design and responsive
Every page checked at phone width (375), tablet width (768) and desktop (1280 or wider). Our free responsive checker shows all three side by side.
No horizontal scrolling at any width. Fixed-width images, tables and embeds are the usual cause.
Headlines do not wrap into four lines at phone width. Hero text is readable over the image at every size.
Navigation works at every width: the menu opens, closes and does not cover the content.
Buttons and links are big enough to tap and far enough apart on a phone.
Form fields on phones use at least 16px text so iOS does not zoom in when tapped.
Checked on a real phone and a real tablet, not only in a browser's device mode.
Checked in Chrome, Safari, Firefox and Edge, current versions.
The favicon shows in the tab and the home-screen icon is set.
3. Links and navigation
No broken links, internal or external. Run a crawler; do not click by hand.
Every link goes where its text says. Logo links to the home page.
Links to the old site, staging URLs or localhost addresses are gone.
Links that should open a new tab do, and nothing else does.
Phone numbers and email addresses are clickable, and the phone number dials correctly from a mobile.
The 404 page exists, is branded, and offers a way back.
4. Forms and conversions
Every form submitted on the live domain, with a real entry, by the agency and by the client.
Submissions arrive where the client expects, from a sender address the client will recognize, and not in spam.
Confirmation messages and thank-you pages are correct. Any auto-reply reads as finished copy.
Required fields, validation messages and error states work and are in plain words.
Spam protection is on, and a real person can still get through.
Payment, booking or quote flows tested end to end with the live provider, in live mode, then the test transactions refunded or cancelled.
The main call to action is visible on every key page without scrolling on a phone.
5. SEO and metadata
Search engines are allowed. Remove "noindex" from the live site and from the robots file. The staging site keeps it.
Every page has its own title and meta description, written for people, with the page's subject near the front.
One H1 per page, headings in order, no skipped levels.
Clean URLs, lower case, hyphens, no dates or IDs where a word would do.
Redirects from every old URL to its nearest new page, including the pages that rank today. Tested, 301 not 302.
XML sitemap generated, reachable, and submitted in Search Console. Bing Webmaster Tools set up as well.
Canonical tags point to the live domain, one version: https, with or without www, decided once.
Structured data for the business, products, articles or events, validated with no errors.
Social share image and Open Graph tags set, and a shared link previewed in Slack or a messaging app.
6. Performance and media
Images sized for where they are shown, compressed, and in a modern format. Nothing over a few hundred kilobytes on a page.
Video does not autoplay with sound, and large videos are hosted or streamed rather than served from the page.
Core Web Vitals checked in PageSpeed Insights on the home page and the busiest two pages, on mobile.
Fonts are limited to the weights in use, and text shows before the font loads.
Caching and a CDN are on, if the host offers them.
Unused plugins, scripts and tracking tags from the build are removed.
7. Accessibility
Text contrast meets the minimum on body copy, buttons and links, including text over images.
The whole site can be used with the keyboard alone, with a visible focus state.
Headings, lists and tables are real HTML elements, not styled paragraphs.
Form fields have labels, and errors are announced in words, not only in color.
Video has captions where it carries speech.
The page language is set, and an automated check such as Lighthouse or axe reports no serious issues.
8. Legal and privacy
Privacy policy and terms are live, linked from the footer, and say what the site actually does with data.
Cookie consent is in place if analytics or marketing tags are used, and non-essential tags wait for consent.
Fonts, images, icons and plugins are licensed for commercial use.
Company registration details, address and any regulated-industry disclosures are shown where the law requires.
9. Analytics and tracking
Analytics is installed on the live domain, and a real-time view shows your visit.
Goals or key events are set: form submission, call click, purchase, sign-up.
Search Console is verified on the live domain, and the sitemap is submitted.
Any ad platform tags or pixels are installed and firing, and were tested with the platform's own helper.
The agency's and client's own visits are excluded, or at least known about.
10. Technical and hosting
Domain points at the new host, and DNS has had time to settle before the announcement.
SSL certificate installed, every page loads on https, and http redirects to it.
Backups are on, automatic, and one restore has been tested.
Admin accounts: the client has one, old or agency-only accounts are removed, and passwords are not the ones from the build.
Software, plugins and themes are on current versions, and updates are assigned to someone after launch.
Email for the domain still works after the DNS change. Mail records are separate from web records, and they are the ones that get lost.
Uptime monitoring is on, with an alert that reaches a person.
11. Launch day
The client has approved the staging site, with a name and a date, before anything goes live.
Launch is scheduled for a time when both sides are available for two hours afterwards. Not Friday afternoon.
The live site opened on a phone, a laptop and a different network from the office.
Every form submitted once more on the live domain.
Redirects spot-checked from the old URLs that matter most.
Search engines allowed on the live site and blocked on staging. Check both.
Analytics shows the launch-day visits.
12. The week after
Search Console checked for crawl errors and coverage problems on day two and day seven.
Analytics checked for pages with unusual drop-off, which is often a broken form or a missing image.
Any launch-day fixes raised on a single review link, in one round, and closed with a sign-off.
Old site and staging site taken down or kept private, and old hosting cancelled when the redirects are safe.
The client knows who to contact, how fixes are handled, and what the aftercare period includes.
Sign-off
Technical pass completed by:
Content pass completed by:
Launch approved by (client):
Date:
How to run it
Split the list by who can see the problem. The agency owns groups 3, 5, 6, 7, 9 and 10. The client owns group 1 and the sign-off. Groups 2, 4, 8 and 11 are both, because a developer and a client find different things on the same form.
Run it on staging first, then again on live. Most of the list is checked on the staging link. Group 11 repeats the handful that only mean anything on the live domain.
Log every issue in one place, pinned to the page. A checklist finds the problems; a review link is where they get fixed. Twenty issues in an email thread is how the second launch week happens.
Finish with a name and a date. "Launch approved by" is the last line for a reason. It is the record you will want when a change request arrives in week three.
How HopBack handles this
HopBack is where the issues from this checklist go. Paste the staging link into a review, run the list, and pin each problem to the element it is about, at the width it happens. The client runs their content pass on the same link, with no account, and their comments land beside yours. When the list is clear, the client presses Approve, and the launch sign-off is recorded with their name and the time. After launch, the same link reviews the live site for the week-after group.
How long does a website launch checklist take to run?
Two to four hours for a typical business site of ten to thirty pages, split across the agency's technical pass and the client's content pass. The first time is slower. Running it on staging a few days before launch, rather than on launch day, is what keeps the launch itself short.
Is this a website QA checklist as well?
Yes. Groups 2 to 7 and 10 are the QA checks: responsive layout, links, forms, search, speed, accessibility and hosting. Groups 1, 8, 11 and 12 are the launch checks around them. Most QA checklists stop before the sign-off, which is the part that prevents the argument later.
Who should sign off a website launch?
One named person on the client side, usually the person who signed the proposal. The agency signs the technical pass. Two signatures, two dates, kept with the project.
What should I check first?
The checks that are expensive to fix after launch: search engines allowed, redirects from old URLs, forms going to the right address, and SSL. Everything else can be fixed on day two without anyone noticing.
Can I use this for a redesign or a migration?
Yes. The redirect checks in group 5 and the DNS and email checks in group 10 matter more on a migration than on a new site. Add a check for the pages that rank today, by hand, before the switch.
What is the difference between a launch checklist and a project plan?
The project plan sets the phases, rounds and approvals for the whole project. The launch checklist is the last phase in detail. Our website project plan template covers the plan.