Website Launch Checklist: 40 Checks Before You Go Live
By Nemanja Vukmirović, Lizzard Solutions. Last updated 11 November 2026.
A new website usually looks finished a week before it really is. The design is approved, the pages are full, and then launch day reveals a contact form that sends to nobody, a staging site Google can index, or a blank page on older phones.
This website launch checklist is the list we run before any site or web app goes live. It covers content, SEO, speed, security, forms, legal pages and the first week after launch, with a clear owner for each check, so you go live once and don’t spend the next month fixing it in public.
TL;DR
- A website launch checklist is a pre-go-live review that proves the site works, can be found, is secure and can be restored if launch goes wrong.
- The checks that hurt most when skipped are boring ones: forms deliver, redirects from the old site exist, backups restore and the staging site is hidden.
- Launch is not the finish line. Monitor uptime, errors, forms and Search Console for the first seven days.
What Is a Website Launch Checklist?
A website launch checklist is a list of checks you complete before a new or redesigned website goes live: content, links, SEO and AI visibility, speed, mobile, accessibility, security, backups, forms, email, analytics and legal pages. Each item is either done, not applicable with a reason, or a blocker. Nothing launches on “probably fine”.
It is not the same as an audit or maintenance. A website audit checklist reviews a site that is already live. A website maintenance checklist keeps it healthy afterwards. The launch list is the gate between the two.
| Checklist | When you use it | Main question |
|---|---|---|
| Launch checklist | Before go-live | Is it safe to switch on? |
| Audit checklist | Any time on a live site | What is wrong right now? |
| Maintenance checklist | Weekly to yearly | Is it still working? |
Key takeaway
Mark every check as done, not applicable or blocker. A blocker means the launch date moves, not the standard.
Action for today: copy this list into a shared document and add a column for the owner and the date each item was checked.
1. Content and Design: Does Every Page Work?
Start with what visitors see. These are the errors customers notice first and forgive least.
- ☐ No placeholder text. Search every page for lorem ipsum, “TBD” and test prices.
- ☐ Contact details match everywhere. Phone, email, address and company name are identical in the header, footer, contact page and Google Business Profile.
- ☐ Every link works. Run a link checker. Menu, footer, buttons and PDFs included.
- ☐ Real error pages. A branded 404 page with links back to key pages, plus sensible empty and loading states in any app.
- ☐ Favicon and share images. Each key page shows a proper preview when shared on LinkedIn or WhatsApp.
- ☐ Images are optimized. Modern formats like WebP, correct dimensions, and descriptive alt text.
Action for today: open the site on your phone and tap every button on the homepage and your main service page.
2. SEO and AI Visibility: Can Google and ChatGPT Find It?
Most launch disasters in search come from one setting copied over from staging. Check these before the new domain goes live, especially on a redesign that replaces an old site.
- ☐ Indexing is switched on. Remove any “noindex” tag or “discourage search engines” setting left from development.
- ☐ Staging is hidden. The staging site is password-protected or noindexed, so it never competes with the real one.
- ☐ XML sitemap and robots.txt. The sitemap lists only live, canonical URLs, and robots.txt points to it. Google’s sitemap documentation explains the format.
- ☐ 301 redirects from old URLs. On a redesign, map every old URL that has traffic or links to its new equivalent.
- ☐ Unique titles and meta descriptions. One clear title per page, with the main keyword near the start.
- ☐ Structured data validates. Organization or LocalBusiness JSON-LD passes Google’s Rich Results Test. Our local business schema markup guide has a template.
- ☐ AI crawlers are allowed if you want to be cited in AI answers. See AI crawlers and robots.txt.
- ☐ Search Console is verified and the sitemap submitted on launch day.
Example
A company relaunches its site with new URLs and no redirects. Every link other sites gave the old pages now hits a 404, and the authority those links carried stops reaching the new pages. A redirect map takes an afternoon. Rebuilding lost links takes far longer.
For the full method, read our technical SEO guide for small business.
Action for today: export a list of your old site’s URLs before anyone switches the domain.
3. Speed, Mobile and Accessibility
A site that is slow or awkward on a phone loses visitors before they read a word. Test it the way your customers will use it, not on the developer’s laptop.
- ☐ Core Web Vitals pass on the homepage and top landing page. Our Core Web Vitals guide explains LCP, INP and CLS.
- ☐ Tested on real devices. At least one iPhone, one Android phone, a tablet and two desktop browsers.
- ☐ Tested on a slow network. Use browser throttling or mobile data outside the office.
- ☐ Caching and compression are on. Static files are cached and served compressed, ideally through a CDN.
- ☐ Basic accessibility. Readable contrast, keyboard navigation, labelled form fields and alt text, following W3C’s WCAG overview. Our website accessibility guide for small businesses includes a 15-minute self-test.
Action for today: run the free website speed check on your staging URL and fix anything marked red.
4. Security and Backups: Can It Survive a Bad Day?
New sites are attacked by the same automated scanners as old ones, from the first day. The OWASP Top 10 is a good reference for what those attacks target.
- ☐ HTTPS everywhere. Valid SSL on the root domain and www, with HTTP redirecting to HTTPS.
- ☐ Security headers are set. Use our security headers checklist.
- ☐ Auth on every endpoint. Admin pages, APIs and file uploads require login and correct permissions.
- ☐ No secrets in the code. API keys live in environment variables, not in the repository. Rotate any key that was ever committed.
- ☐ Dependencies audited. Plugins and packages are up to date with no known critical vulnerabilities.
- ☐ Rate limiting and spam protection on login and contact forms. See our contact form spam protection guide.
- ☐ Default and test accounts removed. Every admin uses their own account and MFA.
- ☐ Backups run and a restore was tested. A backup you never restored is not a plan. Our 3-2-1 backup guide covers the setup.
Key takeaway
The single most useful launch rule: know how to roll back. Write down how you return to the old site or previous release in under an hour.
Action for today: ask your developer one question: “If launch breaks something, how exactly do we roll back?”
5. Forms, Email and Analytics: Will Leads Reach You?
A site that looks perfect but loses enquiries is a failed launch. These checks protect the reason the site exists.
- ☐ Every form tested end to end. Submit each one and confirm the message arrives in the right inbox, with an auto-reply if you use one.
- ☐ Email authentication is set. SPF, DKIM and DMARC records exist for your domain, so site emails don’t land in spam. Google’s email sender guidelines describe the requirements.
- ☐ Analytics records visits and leads. Form submissions and calls are tracked as conversions, and consent rules are respected.
- ☐ Error tracking and uptime monitoring. You get an alert when the site goes down or throws errors, before a customer tells you.
Action for today: send one test enquiry from your phone and one from a Gmail address, and check both arrive.
6. Legal Pages and Accounts
Legal pages are easy to forget and awkward to add after a complaint. For Serbian businesses, our ZZPL website guide explains what the local law expects.
- ☐ Privacy policy and terms that describe the tools you actually use, including analytics and chat widgets.
- ☐ Cookie consent that blocks non-essential cookies until the visitor agrees.
- ☐ Account flows work if users can sign up: email verification, password reset and deleting the account and its data.
- ☐ Domain, hosting and DNS are in the company’s name, with a shared company email as the contact, not one person’s inbox.
- ☐ Spend caps and billing alerts are set on cloud and API accounts.
Action for today: log in to your domain registrar and confirm whose name and email the domain is registered to.
7. Launch Day and the First Seven Days
Plan the switch for a quiet weekday morning, not a Friday evening. Someone who can fix problems should be available for the rest of that day.
- ☐ Final backup of the old site and the new one, taken just before the switch.
- ☐ Smoke test after the DNS change: homepage, one service page, a form, checkout or booking if you have them, all over HTTPS.
- ☐ Watch the first week: uptime alerts, error logs, form submissions and Search Console coverage every day.
- ☐ Write a short README: where the site is hosted, how to deploy, where backups live and who to call.
A week after launch, run the free website audit to confirm nothing slipped through. Our free website audit guide explains what the report checks.
Action for today: pick a launch day and name the person on call for it.
Who Owns Which Check?
This split works for most small business sites. Adjust the names, but keep one owner per row.
| Area | Business owner | Developer or IT partner |
|---|---|---|
| Content, contact details, legal text | Owns it | Uploads and formats |
| SEO settings, redirects, sitemap | Approves key pages | Owns it |
| Speed, devices, accessibility | Tests on own phone | Owns it |
| Security, backups, rollback | Asks for proof | Owns it |
| Forms, email, analytics | Confirms leads arrive | Sets it up |
| Domain, billing, accounts | Owns it | Advises |
Action for today: fill in a name for every row before you set a launch date.
Website Launch Checklist: FAQ
What should I check before launching a website?
Check that content is final and links work, indexing is on and staging is hidden, redirects from old URLs exist, the site is fast and works on phones, HTTPS and security headers are set, backups restore, every form delivers, email authentication is configured, and privacy and cookie pages are live.
How long before launch should I start the checklist?
Start at least one to two weeks before the planned date for a small business site. That leaves time to fix blockers such as missing redirects, slow pages or broken forms without moving the launch. Larger sites and web apps with logins or payments need more time for testing.
What is the most common website launch mistake?
Leaving a development setting live is one of the most damaging: a noindex tag that hides the new site from Google, or a staging copy that gets indexed instead. Missing redirects on a redesign and contact forms that send nowhere are close behind, because nobody notices until traffic or leads drop.
Do I need to test a website after launch?
Yes. Run a smoke test right after the switch, then monitor uptime, errors, form submissions and Search Console daily for the first week. Problems with DNS, caching, email delivery and indexing often appear only on the live domain, not on staging.
Launching a new website soon?
We can run this launch checklist on your site, fix the blockers and stay on call for launch day.
Book a free consultation