Website launch checklist: what to check before, during and after
Most launch problems are small and boring: a form that emails nobody, a search setting left on from the test site, a redirect nobody wrote. This website launch checklist is the routine I run so none of them reach a customer.
Or call or text (502) 387-1142





Websites I have built for Kentucky businesses
The short answer
Before launch, check the content, every form and checkout, phones and browsers, speed, accessibility basics, security and backups. On launch day, point the domain, confirm HTTPS, turn off the setting that hides the test site from search engines, switch on the redirects and submit the sitemap. After launch, watch Search Console, form entries, uptime and backups for the first few weeks, because that is when a missed detail is cheapest to fix.
Use the lists below as your website launch checklist. Skip what does not apply to your site, but never skip the testing.
Two weeks out: content and structure
- Every page has one main heading, a unique title and a meta description written for that page.
- No placeholder text, sample images or test pages left anywhere, including in the footer and the 404 page.
- Phone numbers, addresses, hours and service areas match your Google Business Profile exactly.
- Images are sized for the web and every meaningful image has alt text that describes it.
- A site icon (favicon) and a default image for social media shares are set.
- The 404 page is helpful: a search box or links to your main pages.
- Privacy policy and any terms your business needs are in place and linked in the footer.
- If you are replacing a site, every old address is listed and mapped to its new home. The method is in what happens to your Google rankings in a website redesign.
Forms, checkout and everything that sends email
These are the parts that cost you money when they fail quietly.
- Submit every form yourself, including every branch of any conditional form.
- Confirm each notification lands in the right inbox, not spam, and that the reply-to address is the customer’s.
- Check confirmation messages and thank-you pages.
- Spam protection is on, and real people can still get through without solving puzzles.
- The domain’s SPF, DKIM and DMARC records are set for whatever sends the site’s mail. You can test yours with the SPF, DKIM and DMARC checker, and the fixes are in fix website form emails.
- For a store: place a real order in live mode, check tax, shipping and the order emails, then refund it.
- For bookings: book, change and cancel a test reservation.
- Phone numbers are tap-to-call links, and map links open the right place.
Phones, browsers and accessibility
- Check every page type at phone width, tablet and desktop. Nothing should scroll sideways.
- Buttons and links are big enough to tap, and menus open and close on a phone.
- Test in Chrome, Safari, Firefox and Edge, and on at least one iPhone and one Android phone.
- Every page can be used with a keyboard alone, and focus is visible.
- Text has enough contrast against its background, and headings run in order.
- Run an automated accessibility check on the main templates. It will not catch everything, so treat a clean result as a floor. For a fuller review, see the website accessibility audit.
Speed and Core Web Vitals
Google’s Core Web Vitals measure how a page feels to a real visitor. The good thresholds, measured at the 75th percentile of visits, are set out in Google’s Core Web Vitals guidance:
- Largest Contentful Paint (loading): 2.5 seconds or less.
- Interaction to Next Paint (responsiveness): 200 milliseconds or less.
- Cumulative Layout Shift (visual stability): 0.1 or less.
Before launch, make sure page caching is on, images are compressed and sized for the space they fill, and nothing heavy loads that the page does not use. Test the home page and your main service pages on a phone connection, not only on office Wi-Fi. If the numbers are poor, website speed optimization covers what usually fixes them.
Security and backups
- The HTTPS certificate is valid, and every version of the address (http, https, with and without www) ends up at one secure address.
- Test accounts and old users are removed. Every remaining user has a strong password, and administrators use two-factor sign-in where it is available.
- WordPress, the theme and the plugins are current, and unused plugins and themes are deleted.
- A firewall is in front of the login page and the rest of the site.
- Backups are running, stored somewhere other than the server, and one has been restored to prove it works. See how to test your website backups.
- Outside uptime monitoring is set to alert a real person.
The free WordPress health check looks at several of these from the outside in a few seconds.
Launch day, in order
Order matters on launch day. This is the sequence I follow:
- A day ahead, lower the time-to-live (TTL) on the domain’s DNS records so the switch spreads quickly.
- Stop edits on the old site, and take a final backup of both the old site and the new one.
- Point the domain at the new site and confirm the HTTPS certificate is issued.
- In WordPress, go to Settings, then Reading, and make sure Discourage search engines from indexing this site is unchecked. Remove any staging password and check robots.txt.
- Replace any leftover staging addresses in links and images with the live domain, and check that canonical tags point at the live domain.
- Turn on the redirect map and test the old addresses, starting with the pages that bring the most visitors.
- Clear the site cache and the CDN cache.
- Submit the XML sitemap in Google Search Console and in Bing Webmaster Tools.
- Send changed addresses through IndexNow, which notifies Bing and the other participating search engines. Google is not one of them, so the sitemap is how Google hears about the new pages.
- Submit every form, place a test order and tap every phone link again, this time on the live domain.
- Confirm analytics is recording visits and key events.
Tracking: know what the site is doing
- Google Analytics is installed and records the actions that matter as key events, the name Google now uses for what it used to call conversions: form submissions, phone taps, bookings and purchases.
- Search Console is verified, and you hold owner access in your own name.
- Bing Webmaster Tools is connected. It can import your sites straight from Search Console.
- Your Google Business Profile, social profiles and directory listings point at the right pages.
If you want this measured properly from day one, conversion tracking setup covers it.
The first four weeks after launch
- Search Console, Pages report: new not-found errors mean an old address was missed. Add the redirect.
- Search Console, Performance report: compare the weeks after launch with the weeks before, page by page.
- A crawl of the whole site for broken links and missing titles.
- Form entries and order emails: confirm real ones are arriving, not just your tests.
- Uptime alerts and backups: confirm both are running on the new site.
- Listings: update any that still point at old addresses.
After a month of quiet reports, the launch is finished and the site moves into ordinary care.
How this checklist looks on real launches
The Allied Plumbing launch in Bardstown went out with Search Console, the sitemap and IndexNow set up on day one, plus events for phone clicks and form submissions, and every page checked at a 390-pixel phone width. Arrow Aerial’s fifteen pages were all checked at phone and desktop widths before launch, with no sideways scrolling.
The biggest was Lucas Play. Before that store opened, every address in its sitemap answered, 1,307 internal links were checked with none broken, 16 key pages showed no accessibility violations, and 23 page types were checked at three widths for sideways scrolling. Nothing about it is glamorous. It is just the list, done every time.
Frequently asked questions
How long before launch should I start the checklist?
Start the content and structure checks about two weeks out, and leave the last few days for testing forms, checkout, phones and speed. Launch day itself should be routine.
What day of the week should a website launch?
Pick a day when someone can watch the site for the next few days. Early in the week is easier than a Friday afternoon.
Will my site go down during the launch?
Not if the new site is built separately and the domain is switched over. Keep the old hosting in place until the new site has proven itself.
Do I need to submit my new website to Google?
Google can find a site on its own, but submitting the sitemap in Search Console speeds things up and lets you watch which pages get indexed.
What is the most common website launch mistake?
Leaving the staging setting that tells search engines to stay away switched on. A close second is a contact form that sends its notifications to nobody.
Lucas Play: 1,486 addresses answered on launch day.
Lucas Play moved 1,374 products and 1,763 photos from an old store to a new one. Before the doors opened, all 1,486 addresses in the new sitemap were crawled, and every one answered.
That is the point of a launch checklist: the customer who arrives first should never be the one who finds the problem.
Want a second pair of eyes before you launch?
Send me the staging link or the live address. I will run it against this list and tell you what I find, whoever built the site.





