Launch day is when small oversights become visible to everyone at once. The contact form that sends to a test inbox. The staging site that search engines indexed. The old "/services" URL that now returns a 404 to every visitor arriving from a three-year-old blog post. None of these are hard to fix; they are just easy to forget when the client is excited and you are tired.
A website launch checklist turns launch from a nervous afternoon into a routine. This one is organized by phase, from a week out to a week after, so the right checks happen in the right order.
TL;DR
The website launch checklist runs in four phases: a week before (content, links, forms, mobile, accessibility, SEO metadata), the day before (redirect map, backups, DNS plan, analytics), launch day (DNS cutover, SSL, live form tests, indexing settings) and the week after (crawl, search console, speed, client sign-off). Use it for every new site and redesign. Avoid launching on a Friday; leave time to fix what launch day reveals.
What's inside
- Content and links — proofread, placeholder text removed, links tested, legal pages present.
- Functionality — forms, email delivery, checkout, search, integrations.
- Design and devices — mobile, tablet, desktop, main browsers.
- Performance — image sizes, caching, a speed check on key pages.
- Accessibility basics — headings, alt text, contrast, keyboard navigation, form labels.
- SEO basics — titles, descriptions, sitemap, robots settings, redirects from old URLs.
- Analytics and tracking — installed, consent handled, test events recorded.
- Launch-day technical steps — backups, DNS cutover, SSL, indexing switched on.
- Post-launch — crawl, monitoring, client sign-off.
When to use it
Use it for brochure sites, e-commerce stores, landing pages, redesigns and platform migrations. For a single landing page, the content, forms, analytics and launch-day sections are usually enough.
Once the site is live and accepted, move to the project handoff checklist to transfer accounts and documentation. If you will maintain the site afterward, scope that work in a website maintenance SOW.
Checks most often missed on launch day
Indexing settings. Staging sites are usually set to discourage search engines. If that setting carries over to production, the new site can disappear from search. Check the robots settings on the live domain.
Form destinations. Forms built on staging often send to your own address or a test inbox. Submit every form on the live domain and confirm the client received it, including any autoresponder.
Redirects. On a redesign, export the old site's URLs before you switch, map each to its new equivalent, and set permanent redirects. Pay attention to pages that get traffic or have links from other sites.
Email and DNS records. Changing DNS for the website can affect email if records are moved carelessly. Copy existing mail records before you change anything, and confirm email still works after cutover.
Analytics. Confirm the tracking code is on the live site, real visits appear, and any consent banner behaves as the client expects.
Timing the launch
Plan the cutover for a time when you and the client can both respond, commonly a weekday morning early in the week. DNS changes can take time to propagate, so lowering the record's time-to-live a day ahead helps. Keep the old site available, or a full backup, until the new one has run cleanly for a few days.
Customize it in your COLO workspace
In COLO you can add the launch checklist as tasks in the project, with statuses, priorities, members and comments, and copy the project or task list for the next site you launch. Tasks can be made visible to the client per project, so they can tick off their items, like approving final copy, in the client portal. See Task Management.
Once the site is accepted, the final invoice can be sent from the same project through Invoicing and Payments.
Common mistakes
- Launching with indexing blocked. The site goes live but cannot be found.
- Testing forms only on staging. Live forms send to the wrong inbox.
- No redirect map. Old links and search traffic hit 404 pages.
- Breaking email during DNS changes. Copy mail records first.
- No backup before cutover. Always have a way back.
FAQ
Q: What should I check before launching a website?
Content and links, forms and email delivery, mobile and browser rendering, page speed, accessibility basics, SEO metadata, redirects from old URLs, analytics, SSL, backups and the DNS plan.
Q: How long before launch should I start the checklist?
Start the content and functional checks about a week before launch, and do the technical cutover steps on launch day. Leave a buffer day for fixes.
Q: What day should I launch a website?
Many web designers avoid Fridays and the day before holidays, so problems can be fixed with everyone available. Early in the week, in the morning, is a common choice.
Q: Do I need redirects when redesigning a site?
Yes, if any URLs change. Map old URLs to their new equivalents with permanent redirects so visitors and search engines land on the right pages.
Q: What should I check after launch?
Test forms again on the live domain, check analytics is recording, crawl for broken links and redirect errors, confirm SSL, and check search console for crawl issues over the following days.
Related
More for site builders on the web designers page.