Business website launch checklist: function, SEO and access

A business website is ready to go live once four things are proven: customers can complete the main task from a phone, their requests reach the right person, Google is allowed to crawl the public pages, and you have the access needed to restore the website. Smaller problems outside those four, such as uneven spacing between sections, can be scheduled after launch.

Use this checklist with the developer and whoever is responsible on the business side. Mark each check as passed, needs fixing or not applicable, then write down who fixes it and who rechecks it before the launch date.

Eight checks that must pass

1. The main task can be completed from a phone, through the address you will share.
2. Forms reach the right recipient.
3. The WhatsApp button and email address lead to the right destination.
4. Contact details, services and ordering terms are approved by the person in charge.
5. Public pages are free of noindex tags and robots.txt blocks left over from testing.
6. Admin pages and private areas are closed to the public.
7. Your business holds the domain, hosting and admin accounts, with an active recovery email.
8. A backup exists, and someone knows how to restore it.

These checks are not scored. In a made-up example, seven of the eight checks pass, but the enquiry form does not reach staff. The launch is still delayed, because that form is the main way the business receives enquiries.

How to decide whether to delay or go live

Sort each finding as a launch blocker or a fix that can be scheduled. Delay the launch if the main action fails, data goes to the wrong party, private areas are open to the public, or recovery access is unclear. Display problems that do not hide information or important buttons can be fixed after launch, by a set deadline.

Record the reason for the decision and the retest result in the test log, so the team does not reopen the same debate just before the launch date.

Test the customer journey from start to finish

1. Open the website on a phone through the address you will share.
2. Find the main service or product without help from the project team.
3. Read the terms, service area and information needed to order.
4. Tap the contact button or send a test request using test data.
5. Make sure the request reaches the right recipient and can be acted on.

For the WhatsApp button, check the destination number and the pre-filled message. For email, check the recipient address and make sure the test message lands in a monitored folder. If there is a checkout, use the testing method agreed with the payment provider, then check the order status in the admin panel.

Try failure cases too: an empty required field, a badly formatted email address, and the connection dropping mid-send. Visitors should see a clear message explaining what went wrong. A button that changes colour after being pressed does not prove the form worked, so always check on the receiving end.

Content customers rely on

• Business name, contact number, address and opening hours are accurate.
• Services, service areas and ordering terms are approved by the person in charge.
• Photos, logos, testimonials and client names are used with the appropriate permission.
• No placeholder text, test products, empty links or conflicting information.
• Required policies match how the website collects data and handles transactions.

Check details that repeat across the header, footer, contact page and forms. One old number left behind on a single button can still send prospective customers to the wrong place. For material that changes regularly, decide who will update it after launch.

Mobile display and keyboard use

At the very least, test on the phones your team actually has. Check that the text is readable, the menu opens and closes, and important buttons are not covered by banners or floating buttons. Rotate the screen to find sections that get cut off.

On a computer, you can start straight away with the Easy Checks from the W3C, the body that sets web standards. Move through the page with Tab and Shift+Tab, then make sure every element can be reached, the focus position is visible, the order makes sense, and you never get stuck on one element. Zoom the text to about 200 percent, then check that nothing overlaps or is cut off.

Check the forms as well. The W3C explains that every field needs a label connected to it, so assistive technology can identify it, and clicking the label also activates the field.

Settings that let Google crawl your public pages

This part is best left to the developer; you only need to ask for the results. A website built in a test environment is usually closed to search engines on purpose, so that setting must be reversed at launch.

What to check	Sign of a problem and where to check
Noindex	content="noindex" is still in the robots meta tag on a public page. Check the page source or the URL Inspection tool in Search Console, Google's free tool for site owners.
robots.txt	Disallow: / is left over from testing. Check the /robots.txt address.
Canonical	Points to the test address. Check the page source.
Sitemap	Contains test URLs or URLs that are not full (absolute) addresses. Check the sitemap file and Search Console.
Page status	Important pages return an error, or their titles and descriptions are not relevant. Check with URL Inspection.

Noindex and robots.txt control two different things, and each can get in the way of the other. Google's documentation explains that noindex is only read if Googlebot, Google's crawler, is allowed to crawl the page. On a page blocked by robots.txt the rule is never read, and the page can still appear in search results if other pages link to it. The robots meta tag specification says the same.

For public pages, you want robots.txt to allow access and no noindex tag on the page. Indexing settings are not a security measure either. Admin pages and private data must be protected by a login or access control, because noindex only asks for a page not to be shown in search results.

Once the website is live, use Search Console to check a URL's index status, test a live URL and submit a sitemap. Google describes a sitemap as only a hint, not a guarantee of crawling, so neither the launch nor a submitted sitemap means every page will be indexed right away or reach a given ranking.

If the new website replaces an old one and the page addresses change, there is one more job. Google's site move guide recommends mapping every old URL to its new URL with a permanent server-side redirect, such as a 301 or 308. Avoid redirect chains, do not send many old URLs to one unrelated page such as the home page, and test the redirects once they are live.

Make access and recovery clear

Record who holds the domain, hosting, admin and third-party service accounts. Check each recovery email and give each person their own access, matched to their role. Keep passwords out of briefs and chats that were not built to store credentials.

Ask what is backed up, where it is stored and who can restore it. For WordPress, the official backup documentation says both the database and the files are needed to restore a website in full. Other platforms need a procedure that fits their architecture. If a restore test is part of the agreed work, ask for proof of a restore to a separate environment.

Test log format

One table is enough, as long as every row has evidence and an owner. Here is a made-up example.

Task	Expected result and evidence	Status
Contact form	Staff receive the test message. Evidence: time sent and the recipient's confirmation.	Needs fixing, retest
Mobile menu	The services page opens and the menu can be closed. Evidence: device and screenshot.	Passed
Home page	The URL can be inspected, with no noindex tag or robots.txt block. Evidence: the URL and the result.	Passed

Go through this checklist when you agree the scope of a web development project. Once customers are using the website, the same checks continue in the business website maintenance checklist and as part of a website maintenance service.