Guide
Website launch checklist
Most launch problems aren't big bugs. They're small things nobody owned: a redirect that was never set up, a form that still emails the old address, analytics that never got reconnected. This is the checklist to go through before you flip the switch, grouped so you can split it across the team.
Domain and hosting
- DNS records point to the new host, and the TTL was lowered a day before launch so the change propagates fast.
- SSL certificate is active on the new domain, and HTTP redirects to HTTPS.
wwwand non-wwwboth resolve, with one redirecting to the other.- Staging is no longer indexable (
noindex, or taken down) once the live site is up. - Old URLs that changed have 301 redirects, not 404s. Check your top 20 pages by traffic first.
- Email (MX records) still works after the DNS change, if the domain also sends mail.
SEO and analytics
robots.txtisn't blocking the whole site by mistake (a common staging leftover).sitemap.xmlis live and submitted in Search Console.- Analytics (GA4 or similar) is installed and firing on the real domain, not just staging.
- Search Console and Bing Webmaster Tools have the new domain verified.
- Title tags, meta descriptions and canonical tags are in place on key pages, not placeholder text.
- Structured data (product, article, FAQ) validates, if you use it.
- Old backlinks and social shares still resolve, through the redirects above.
Forms and integrations
- Every form on the site sends to the right inbox, tested with a real submission, not just a preview.
- Autoresponders and confirmation emails use the live domain's sender address.
- Payment or checkout flows are tested end to end in live mode, with a real small transaction if possible.
- Third-party scripts (chat widgets, booking tools, ad pixels) point at the production account, not a sandbox.
- Cookie and consent banners work, and respect what visitors choose.
Performance and security
- Images are compressed and served at the size they're shown, not full resolution scaled down by CSS.
- The homepage and your two or three most important pages load acceptably on a throttled connection.
- Security headers are set (HSTS, a reasonable Content-Security-Policy) if your stack supports them.
- Backups are running against the new, live environment, not just staging.
- A staging password or basic auth, if the old environment had one, is off on the production domain.
Content and legal
- Every page that will be public has been proofread, including footer links and legal pages.
- Privacy policy, terms and cookie policy reflect what the live site actually does.
- Contact details, address and support email are correct and match what's in the footer.
- 404 and error pages exist and link back into the site.
- Broken internal links are checked with a crawler, not just by clicking around.
Launch day
- One person owns go/no-go, so a half-finished item doesn't get waved through by accident.
- Launch happens at a time someone can watch it for the first hour (not a Friday at 6pm).
- A rollback plan exists: how to point DNS back, or restore the old site, if something breaks badly.
- Stakeholders know when it's live, and who to tell if they spot something wrong.
Do it in StiqNote
A launch checklist dies the moment it lives in a spreadsheet nobody opens again. Open the live (or staging) site with StiqNote and pin each item straight onto the page it's about: the redirect note on the old URL, the form check on the contact page, the SEO note on the homepage's title tag. Assign each pin to whoever owns it, set a due date for launch day, and the Inbox and due-date summary chase people instead of you. When everything's resolved, you have a dated record of what was checked, not just a checklist that says it was.
Stop sending screenshots in Slack
Pin the feedback where it belongs. Free to start, with 14 days of Agency for your first team.