My pre-launch checklist for a small business website

Launching a small business website is rarely difficult. What goes wrong is almost always something small that nobody checked: a contact form that sends enquiries to an inbox no one reads, a certificate that covers www but not the bare domain, or a staging setting that quietly tells search engines to ignore the whole site.

I build and launch websites for clients, and I go through this list before every handover. None of it is clever. It exists because launch day is exactly when the boring things get forgotten.

Content and copy

Replace every placeholder

After weeks of looking at a site, placeholders become invisible to you. They are very visible to the client’s customers.

During a build I use the Placeholder Image Generator for images that do not exist yet. I make them at the exact final dimensions, in a colour nobody would choose on purpose, and each one shows its own size by default. Before launch I search the templates and the CMS for anything left over: lorem ipsum, “example.com”, test phone numbers and those deliberately ugly images.

Check the copy is the approved copy

Text changes hands a lot during a project, and fixes made in the document do not always reach the site. If the client has signed off a final version, I paste it into Text Diff next to the text copied from the live page. Any paragraph that differs is flagged, even if only one word changed. It compares whole lines, so you still read the paragraph to find the word, but you know where to look.

It is also handy for comparing robots.txt or redirect rules between staging and live, where one stray line matters.

Titles and meta descriptions

Every page needs its own title and meta description, because they are usually what people see in search results. I write them, then paste them into the Word Counter to check the character count. As a rough guide I aim for titles of about 60 characters and descriptions of about 150 to 160. Google shortens them based on how much space they take up rather than a fixed count, so treat those as targets rather than limits, and put the important words first.

Images and branding

Compress and resize images

Clients send photos straight off their phones, several megabytes each. I run them through the Image Compressor, usually saving as WebP with “Fit within” set to a sensible maximum width. Formats and sizes are covered in Getting images ready for the web.

Strip location data from photos

A photo taken on a phone often records where it was taken. If the owner took the “about us” photos at home, the original files may carry their home address as GPS coordinates.

The Image Compressor removes metadata as a side effect of re-encoding. For photos I do not want to recompress, the EXIF Remover takes out EXIF, XMP and IPTC data without touching the image itself. It handles JPEG, PNG and WebP, but not iPhone HEIC files. There is more on this in how to remove location data from photos.

Favicon and home screen icons

A missing favicon makes a site look unfinished in a row of browser tabs. The Favicon Generator makes favicon.ico, an Apple touch icon, the Android icons and a web manifest from one image, and gives you the tags to paste into the page head. Check the 16 pixel preview: detailed logos turn to mush at that size, and a single letter or simple mark often works better.

Colour contrast

Brand colours are not always readable colours. I check each text and background pair in the Colour Converter, which shows the contrast ratio against WCAG 2.2: level AA needs 4.5:1 for normal text and 3:1 for large text. If a pair fails, it suggests the nearest shade of the text colour that passes. There is more in accessible brand colours.

Technical checks

SSL certificate

If the certificate does not cover the address someone types, they get a full-page browser warning. That is about the worst first impression a business website can make.

Export the certificate from your browser as PEM (or fetch it with openssl s_client) and paste it into the Certificate Decoder. Check two things. First, the list of domains must include both example.com and www.example.com. Browsers only check that list, and a wildcard such as *.example.com does not cover the bare domain. Second, check the expiry date: the decoder flags certificates that expire within 30 days. Most hosts renew certificates automatically now, but confirm it rather than assume it, especially as maximum certificate lifetimes are being shortened.

Redirects

Every version of the address (http and https, with and without www) should end up in one place, using a permanent (301) redirect. If the new site replaces an old one, map the old page addresses to their new equivalents too, or old links in search results and bookmarks lead to errors.

The 404 page

Type a nonsense address and check you get a helpful page with a way back to the main sections. Then check it really returns a 404 status code (the Network tab in your browser’s developer tools shows this). A “not found” page that returns 200 confuses search engines.

Forms actually deliver

This is the one I am most careful about, because a broken form fails silently. The site looks fine and the enquiries simply go nowhere. Submit every form on the live domain, not staging, and confirm each message arrives in the client’s real inbox rather than their spam folder. If the site sends email, the sending domain needs SPF and DKIM set up, or many mail providers will reject or junk the messages.

Search engines can see the site

Staging sites are usually hidden from search engines with a noindex tag or a robots.txt rule. Make sure that has gone. Then add the site to Google Search Console, submit the sitemap and give the client access, since that is where Google reports problems later.

Analytics and cookie consent

If the site uses analytics or anything else that sets non-essential cookies, the UK rules on consent apply. They have been changing, so check the ICO’s current guidance rather than copying what you did on the last site. Whatever you set up, test it: decline cookies and confirm that the analytics script really does not load.

Backups

A backup you have never restored is a hope, not a backup. Confirm what is backed up (files and database) and how often, restore one to a test location once, and agree in writing who looks after backups after handover.

Handover

Who owns the domain

This is the check that matters most in five years’ time. The domain should be registered in the client’s name, in an account they control, with automatic renewal and a contact email they actually read. If a developer holds it in their own account, the client can end up locked out of their own business name.

Logins

Every account gets its own password. I generate them with the Password Generator: long random passwords for anything stored in a password manager, and a passphrase for the few things the client has to type from memory. I share them through a password manager rather than plain email, suggest the client changes them after handover, and give each person their own login rather than one shared admin account.

Printed material

If new business cards or signage include a QR code, generate it once the final address is live. The QR Code Generator makes static codes, so the address is stored in the pattern itself and there is no third-party redirect to expire. Send the SVG to the printer, point the code at an address you are confident will not change, and scan the printed proof with a phone before the full run.

The checklist

On launch day

• Go live early in the week, and early in the day. If something breaks, people are around to fix it. Friday afternoon launches are a tradition best left to others.
• Lower the DNS time to live (TTL) a day or two before. Changes then spread faster, and you can switch back quickly.
• Keep the old site and hosting running until the new one has settled and everyone is seeing it.
• Run the checks again on the live domain. Passing on staging proves less than you would like.
• Look at Search Console a week later. Crawl errors tend to show up there before anyone emails you about them.