A website launch checklist for a small business.

What goes wrong on launch day

Most launch problems are quiet. Nobody gets an error message. These are the four that cost small businesses the most, and the rest of this checklist is built around them:

• Old addresses that now lead nowhere, so visitors from Google, from other sites and from your own Business Profile land on an error page.
• Forms that stopped sending, or send into a spam folder, so enquiries stop.
• Email that stops working because the domain moved to a new DNS host and the mail records did not come with it.
• The setting that kept the preview out of search, left switched on, so Google is told not to list the new site.

Work in three stages: the week before, launch day itself and the weeks after. If a studio builds the site, this is still worth checking yourself, because you know which pages your customers use. When we launch a site, old addresses are redirected to their new pages, the domain moves to the new site, every form gets one more test from a phone and the sitemap goes to Google Search Console in your account. This checklist covers those steps and the ones around them, written for owners.

Before anything: who holds the keys

Collect the logins you will need on the day, and check that each one is in the business's name:

• The domain registrar, where the domain is renewed.
• The DNS host, if your DNS lives somewhere other than the registrar.
• The old hosting and the new hosting or website platform.
• Your email provider, such as Google Workspace or Microsoft 365.
• Google Search Console, Google Analytics and your Business Profile.
• The booking tool, any form tool and any ad accounts.

Check the domain's renewal date too. Launching a week before it expires, with reminders going to someone who left, is how sites vanish a month after launch.

If a past supplier still holds any of these, sort that out first, before you set a date: see how to get your website back from a web designer.

Check every page as a customer would

Go through the whole site on your own phone, then on a laptop. If you can, try one iPhone and one Android phone. Read every page against how things are today:

• Prices, opening hours, holiday hours, the address and the phone number.
• Team names, roles and photos.
• No placeholder text, sample photos or "coming soon" pages left from the build.
• The business name spelt the same way everywhere, and the same as on your Business Profile.
• Every button and link goes where it says. The phone number starts a call when tapped, the email address opens a new message and the address opens a maps app.
• The booking button opens the right service in your booking tool.
• A privacy notice that matches what your forms and any tracking really do. Some countries, such as Germany, also require the business's legal details to be easy to find on the site, usually on a page of their own.

Then give the phone to someone who has never seen the site and ask them to book or send an enquiry without help. Where they hesitate is what to fix before launch.

Map every old address to its new page

If you are replacing an old site, its page addresses are how Google, other websites and your returning customers find you. When an address changes and nothing points it to the new page, all of that stops at an error page. A website redesign lives or dies on this step.

Make a list of every old address. The old site's sitemap, the pages report in Search Console and your analytics between them catch nearly all of them. Mark the ones that bring visitors from search. Then, for each old address, write the new page that replaces it:

• Use permanent server redirects, the kind called 301. Google recommends permanent redirects and says to keep them for as long as possible, generally at least a year.
• Point each old page at its true replacement. Google warns against sending many old addresses to one unrelated page such as the home page.
• Redirect in one step, not through a chain of redirects.
• Include old PDFs and images other sites link to, such as a price list or a menu.
• Pick one version of the domain, with or without www and always over https, and redirect the others to it.

A dental clinic whose old page for teeth whitening ended in .html and whose new one sits under a treatments section needs a redirect from the first to the second, or the searches that page earned for years start again from nothing. If the domain itself changes, Google's Change of Address tool in Search Console is for that case only.

Make missing pages return a real 404

Some addresses will always be wrong: a mistyped link, an old flyer, a page you removed on purpose. The site needs a page for them that says plainly that this page is not here, then offers the main services, the contact page and the phone number.

That page must send the 404 status code that tells browsers and Google the page does not exist. A page that says "not found" but sends a success code is what Google calls a soft 404, and Search Console lists it as an error. Do not send every missing address to the home page either: the visitor lands somewhere they did not ask for, and nothing tells them why.

To check, type a made-up address on your domain, such as /this-page-does-not-exist/. You should see your 404 page. Then check its status code with the URL Inspection tool in Search Console after launch, or with any free online header checker.

Let search engines in

A site being built is usually kept out of Google with a noindex tag or a robots.txt rule that blocks everything. That is right for the preview and a disaster after launch. Google's own site move guidance reminds owners to remove these blocks once the move is done. Then check:

• No page you want found carries a noindex tag, and robots.txt does not block the site.
• Every page has its own title and description, and one main heading.
• Links, canonical tags and the sitemap use the live domain, not the preview address. A sitemap still listing the preview is a common slip.
• The structured data with your business name, address, phone number and opening hours passes Google's test for structured data.
• The sitemap lists only live pages you want found, and robots.txt points to it.

Submit the sitemap in Search Console on launch day, from an account the business owns. Google says crawling can take from a few days to a few weeks, and asking again does not make it faster. If pages still do not appear after that, see why your website is not on Google.

Test every form from end to end

A form can look perfect and send nothing. Test each one, including the quote form, the booking request and the newsletter signup, from a phone on mobile data, the way a customer would:

• After sending, the page says what happens next and when.
• The notification reaches the right inbox, not the spam folder, with every field filled in and readable.
• Pressing reply on the notification answers the customer, not the website.
• The customer's confirmation email reaches their inbox. Send one test from a Gmail address.
• A copy lands in your booking tool, CRM or spreadsheet, if the form is meant to send one.
• Error messages say which field is wrong, and the form keeps what was typed.
• Uploads work, if the form takes photos or documents.
• The spam check does not block you or anyone else with a normal name and address.

For a booking tool, make a real test booking and cancel it. For a store, place an order with the payment provider's test mode or a real card, then refund it. Delete the test records afterwards so they do not end up in your figures. If spam is a worry, set up the protection before launch, not after: see how to stop contact form spam.

Move the domain without breaking email

Your domain's DNS settings hold more than the website's address. They hold the records that deliver your email, prove your email is genuine, and verify your accounts with Google, Microsoft and other services. Launching often means changing these settings, and this is where email gets broken.

Before you change anything in DNS, export or photograph every record. Moving the domain to a new DNS host without its MX records stops all email on the domain, and nobody notices until customers say their messages bounced.

• Copy every record to the new DNS host before you switch: MX, SPF, DKIM, DMARC, verification records and any CNAME records your tools use.
• If you only change where the website points, change those records and nothing else.
• If the new site sends form emails through a new service, add that service to your SPF record or set up DKIM for it.
• After the switch, send an email to the business from outside, and send one from the business to a Gmail address.

How those email records work, and how to check them, is in why your business emails go to spam.

Analytics, ad links and consent

Check that analytics runs on the live domain and records your own test visit. If it was set up on the preview address, it may record nothing after launch.

If you run ads, update each ad's final address to the new page before the switch, so paid clicks do not land on a redirect or an error, and check that a test enquiry still arrives with its campaign attached. The landing page itself is covered in before you run ads.

If the site uses cookies or tracking that need consent, such as an advertising pixel for visitors in Europe, check the banner on a phone. Nothing that tracks should load before the visitor answers, and saying no should be as easy as saying yes. If the site does no tracking, it needs no banner at all.

Update every link that points to the site

Search is one way in. The others are links you control, and each one needs the new address:

• Your Google Business Profile: the website link, and the booking or menu link if your category has one.
• Your bio links on Instagram, Facebook and any other profile.
• Directories and trade bodies that list you.
• Email signatures, and the website link in your booking tool and invoices.
• Review requests and automated messages that link to a page on the site.
• QR codes on flyers, menus and vans. If you cannot reprint them, make sure their old address redirects to the right new page.

The Business Profile matters most, because some customers decide from it without opening your site. Check its website link from the profile itself on a phone after launch.

On launch day

Pick a quiet day early in the week, with the person who can fix problems available all day. Not a Friday, and not the day before a holiday or your busiest season. Then work in this order:

• Take a full backup of the old site, files and database, and keep it.
• Copy every DNS record, then switch the domain to the new site.
• Check the site loads on the domain with and without www, over https, with no certificate warning.
• Turn on the redirects and try a dozen old addresses, starting with the ones that bring the most visitors.
• Remove the noindex tag or robots.txt block, and submit the sitemap.
• Send a test through every form, and send and receive an email.
• Update the Business Profile link and your social media links.
• Keep the old hosting running for now, in case something needs to be fetched from it.

The weeks after launch

For the first week, look every day, then every few days for the rest of the month:

• Enquiries and bookings: are they arriving at the usual rate, and complete? A sudden drop often means a form or an email record.
• Search Console: the pages report for addresses Google could not find or was told not to index, and the sitemap report.
• Redirects: any old address that shows an error page in Search Console or your analytics gets a redirect.
• Analytics: visits are recorded, and traffic arrives on the new pages.

Google expects some movement in rankings while it processes a move, and says it can take a few weeks or more to show new addresses on a site of moderate size. Compare search clicks with the same weeks before launch, not with the day before.

After a month, when nothing has come up, cancel the old hosting. Our website setup includes the first 30 days after launch to fix and adjust, as the prices page lists, and the weeks after launch are part of how a build runs: see websites. For speed checks on the new pages, see PageSpeed Insights explained.