Back to Blogs
The last day of a website project is when the small mistakes show up. A contact form that sends to the wrong inbox. A page still saying "Lorem ipsum" at the bottom. A site that Google is told not to index because a setting from the test server came along. None of these are hard to fix, but they are embarrassing when a client finds them a week after launch, and some of them quietly cost enquiries.
So before I switch any site live, I go through the same list. It has grown over the years from things I got wrong or nearly got wrong. This is that list, in roughly the order I do it.
Content and copy
I start with the words, because they are what visitors actually read and they are the easiest thing to overlook when you have been staring at the design for weeks.
Read every page from top to bottom
Not skim, read. I open each page and read it like a visitor would, including the footer. This is where I find leftover placeholder text, a service the client stopped offering, an old phone number, or two pages that say slightly different things about opening hours.
Check names, numbers and prices with the owner
Phone numbers, WhatsApp links, email addresses, addresses and prices all go back to the client for one final confirmation. I tap every phone and WhatsApp link on a real phone to make sure they open the right number. A single wrong digit can mean a month of missed calls before anyone notices.
Replace every "#" link
During a build I often use "#" as a temporary link for social icons and menu items. Before launch I search the code for href="#" and fix or remove each one. A social icon that goes nowhere looks careless, and it is better to remove it than to leave it broken.
Forms and emails
For most small business sites the contact form is the whole point, so I test it more than anything else.
- I submit every form with real details and confirm the email arrives in the owner's main inbox, not spam.
- I check that pressing Reply on that email goes to the visitor, not back to the website.
- I check that the enquiry is also saved in the database or admin panel, so nothing is lost if an email goes missing.
- I submit the form empty and with a bad email address to see that the error messages make sense.
- After a successful submit, the visitor should see a clear message that it worked. I hide the form and show a short thank you note so nobody sends it twice.
If emails go to spam, I fix that before launch rather than after. It usually comes down to how the site sends mail and the domain's SPF, DKIM and DMARC records.
Mobile and different browsers
Most visitors on the small business sites I build come from phones, so the mobile check is not optional.
Use a real phone, not only the browser's mobile view
The desktop browser's device mode is useful while building, but it misses things. On a real phone I check that nothing scrolls sideways, that buttons are big enough to tap, that text is readable without zooming, and that the menu opens and closes properly. I also fill in the contact form on the phone, because a form that is fine on desktop can be cramped and annoying on a small screen.
Try more than one browser
I open the site in Chrome, Safari on an iPhone and Firefox at the very least. Safari in particular still finds small layout problems that Chrome hides.
Search engine basics
A launch is the best time to get the search basics right, because fixing them later means waiting for Google to notice the changes.
- Indexing is allowed. Test and staging sites are usually blocked from search engines. I check that the live site does not still have a
noindextag or a robots.txt that blocks everything. This one mistake can keep a site out of Google for weeks. - Each page has its own title and meta description. Written for people, describing what is on that page, not the same text copied across the whole site.
- One clear H1 per page, with headings below it in a sensible order.
- Canonical tags and one main address. The site should open on one version, either with www or without, and the other should redirect to it. Same for http and https.
- A sitemap.xml, which I submit in Google Search Console once the site is live.
- Images have alt text that describes them, and social sharing tags are set so links look right when shared on WhatsApp, Facebook or LinkedIn.
If the site is replacing an old one, I also make a list of the old page addresses and set up redirects to the matching new pages. Old links in Google and on other sites keep working, and the site does not lose the ranking it already had.
Speed and images
I run the main pages through PageSpeed Insights and look at the mobile results. I am not chasing a perfect score, but I want the page to load quickly on an average phone connection.
The biggest problem is almost always images. A client sends a 6 MB photo straight from their camera and it ends up on the homepage. Before launch I resize photos to the size they are actually shown at, save them as WebP, and lazy load the ones further down the page. That alone often cuts the page weight by more than half.
Security and the technical side
SSL and HTTPS everywhere
The SSL certificate should be active and every page should load on https without browser warnings. I look for "mixed content", where an image or script is still loaded over http, because it can break the padlock icon.
Turn off debug output
On PHP sites, error messages should be logged, not shown to visitors. A visible error can reveal file paths or database details. I also make sure passwords and config files with secrets sit outside the public folder.
Admin access
The admin panel gets a strong password, test accounts are deleted, and I give the client their own login rather than sharing mine.
A 404 page that helps
I visit a page that does not exist to check the site shows a friendly 404 page with links back to the main sections, not a blank server error.
Backups and tracking
Before the switch I take a full backup of the files and database, and I check that the hosting has automatic backups turned on. If something goes wrong on launch day, I want to be able to go back in minutes.
I also set up Google Search Console and a simple analytics tool, so the owner can see later how people find the site and which pages they visit. I keep this light. Most small business owners only need to know how many people visited and how many got in touch.
The day after launch
Launch is not the end of the checklist. The next day I check a few things again:
- The site opens on the real domain from a different network and a phone on mobile data, since DNS changes can take a while to reach everyone.
- A fresh test enquiry still arrives in the inbox from the live site.
- Search Console has accepted the sitemap and shows no big errors.
- The hosting error log has nothing new and worrying in it.
Then I send the client a short note with their admin login, where the backups are, and what to do if something looks wrong.
Why I bother with a list
I could probably do most of this from memory. But at the end of a project I am tired and keen to finish, which is exactly when things get skipped. A written list removes that. It takes me an hour or two per site, and it has saved me from more awkward phone calls than I can count.
If you have a site that is about to launch, or one that is already live and you are not sure some of this was done, send me a message. I'm happy to go through it with you and tell you honestly what needs fixing and what is fine as it is.
