The Business Website Launch Checklist: What to Get Right Before Going Live
Most website problems are baked in before launch. A practical checklist covering speed, mobile, forms, tracking, SEO basics and the handover — so the site works from day one.
By Dawki Infotech Team ·
A website is usually judged in the first week after launch, but almost every problem that surfaces then was decided weeks earlier: the images nobody compressed, the form that emails one inbox and nothing else, the tracking that was never wired up. This checklist is what we walk through with a client before we let a site go live. None of it is exotic. All of it gets skipped under deadline pressure.
1. Speed: measure it, do not assume it
Run the finished site through a lab tool such as Lighthouse and against Google's published Core Web Vitals targets: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift below 0.1. Test the slowest important page, not just the homepage, and test on a throttled mobile profile, because that is where most of your visitors are.
- Images in WebP or AVIF, sized to the space they fill, with width and height set so nothing jumps as they load.
- Fonts self-hosted and limited to the weights you actually use.
- Third-party scripts justified one by one — every chat widget, heat-map and tag manager is weight your visitor pays for.
- The hero image, if there is one, loaded eagerly with high priority; everything below the fold lazy.
2. Mobile is the site, not a version of it
Open every page at phone width and scroll all the way down. You are looking for four things: anything that scrolls sideways, text smaller than about 12 pixels, tap targets you cannot hit cleanly with a thumb, and images or tables wider than the screen. Fix them in the shared layout, not page by page, or they will come back with the next page you add.
3. Forms: the database is the record, email is the notification
A contact form that only sends an email is a form that silently loses enquiries the day the mailbox fills, the spam filter changes, or someone leaves the company. Every submission should be stored first — in a database or a CRM — and the email should be a notification of a record that already exists. Add a honeypot field, server-side validation, and a rate limit; capture the page, referrer and campaign parameters with each lead so you know what produced it.
4. Tracking that respects consent
Decide what a conversion is before launch: a form submission, a WhatsApp click, a call. Wire those events, then test each one and confirm it lands in your analytics. If you serve visitors in regions with consent laws, analytics should stay off until they accept, and the cookie banner should say plainly what is collected. A banner that blocks the whole screen on a phone is a bounce, not compliance.
5. SEO basics that are cheap now and expensive later
- One H1 per page, and a unique title and meta description that describe the page rather than the company.
- Clean URLs, a canonical tag on every indexable page, and redirects from every old URL if this replaces an existing site.
- An XML sitemap submitted to Search Console, and a robots.txt that blocks staging but not production — check it twice.
- Structured data only for content that is actually on the page. Never mark up reviews or ratings you do not display.
- Descriptive alt text on images that carry information; empty alt on the purely decorative ones.
6. Security is an acceptance criterion
HTTPS everywhere with HTTP redirecting. Security headers set — a content security policy, frame options, referrer policy. No secrets in client-side code or in the repository. Dependencies audited, with anything left open written down with a reason. If the site has a CMS, its login is not the default password, and it is not indexable.
7. Content that will still be true in a year
Remove every placeholder statistic, every 'lorem ipsum', every testimonial that has not been approved by the person quoted, and every client logo you do not have permission to show. It is better to launch with three honest proof points than twelve invented ones — and it is safer.
8. The handover
Whoever will run the site needs three things: access that belongs to the company rather than to an individual (domain, hosting, analytics, CMS), a short written note of where things live and how to update them, and a way to reach whoever built it when something breaks. Agree what 'support' means before you need it.
A launch is not the end of a build. It is the first time the site is measured by anyone other than the people who made it.
