7 Technical Checks I Run Before Launching a Small-Business Website

A small-business website can look finished and still fail at the things that matter: loading on a real phone, sending an enquiry, appearing correctly in search, or giving the owner control of their own accounts.

This is the practical pre-launch checklist I use before calling a website ready. It is intentionally framework-agnostic, so the same checks work whether the site uses Next.js, WordPress, a static-site generator, or a custom stack.

1. Test the real conversion path

Do not stop after checking that the contact form looks correct. Submit it from beginning to end.

For every form, test:

• valid input;
• empty required fields;
• an invalid email address or phone number;
• a slow or failed network request;
• the confirmation shown to the visitor;
• the notification received by the business;
• duplicate submissions;
• basic spam protection.

A successful API response is not enough. Confirm that the enquiry reaches the inbox or CRM the business actually monitors. Also make the failure message useful: “Something went wrong” gives the visitor no way forward, while a phone or email fallback can save the lead.

2. Check the site on a physical phone

Responsive mode in browser developer tools is useful, but it is not a complete mobile test.

Open the production build on at least one real phone and check:

• navigation with a thumb;
• tap targets and fixed WhatsApp/call buttons;
• text size without zooming;
• forms when the on-screen keyboard is open;
• long headings and translated text;
• portrait and landscape orientation;
• slow mobile data, not only office Wi-Fi.

Pay particular attention to sticky elements. A header, cookie banner and floating contact button can each look reasonable alone but cover half the viewport when combined.

3. Verify the crawl and index signals

Before launch, inspect what the server actually returns—not only what appears after JavaScript runs.

At minimum, confirm:

• every important page has one descriptive title;
• the main heading accurately describes the page;
• canonical URLs point to the intended production URLs;
• production pages do not contain an accidental noindex directive;
• robots.txt does not block important routes or assets;
• the XML sitemap uses final HTTPS URLs;
• internal navigation uses crawlable links;
• old staging URLs are not referenced anywhere.

A quick response-header check is useful:

curl -I https://example.com/
curl -I https://example.com/contact
curl -I https://example.com/a-page-that-does-not-exist

The important pages should return the expected success response, and a nonexistent URL should return a genuine 404 rather than a misleading 200 page.

4. Measure performance before adding more scripts

Run Lighthouse or PageSpeed Insights, but treat the result as a diagnostic rather than a single pass/fail score. Lab data and real-user field data answer different questions.

Common launch-day problems include:

• an oversized hero image;
• images without width and height;
• fonts blocking the first render;
• third-party chat, tracking and animation scripts loading immediately;
• JavaScript shipped to pages that do not need it;
• layout movement caused by late-loading banners or embeds.

Start with the largest visible element and the scripts loaded on every page. Removing one unnecessary dependency often helps more than applying several tiny optimisations.

5. Validate analytics and conversion events

“Analytics installed” should mean more than finding a tracking ID in the code.

Using a real visit, verify that the analytics platform records:

• the page view;
• a successful enquiry submission;
• meaningful call or WhatsApp clicks, if those are business goals;
• the correct production hostname;
• campaign parameters where they are needed;
• no duplicate events from repeated tag installation.

Name events around user actions rather than interface details. lead_form_submitted remains understandable if the button text or component changes; blue_button_clicked does not.

6. Confirm ownership, security and handover

The business should know who controls each critical asset before the site launches.

Document ownership of:

• the domain registrar;
• DNS;
• hosting;
• source-code repository;
• business email;
• analytics and search tools;
• paid plugins or licences;
• backups.

Use individual accounts and appropriate roles where possible instead of sharing one password. Keep secrets in environment variables, enable HTTPS, remove test credentials and confirm that public client-side bundles do not expose private keys.

A beautiful website becomes a liability if the owner cannot renew the domain or recover access six months later.

7. Test failure, rollback and recovery

The final check is not “Does the happy path work?” It is “What happens when something breaks?”

Before release, know:

• how to roll back the deployment;
• where backups are stored;
• whether a backup has ever been restored successfully;
• who receives uptime or form-delivery alerts;
• what visitors see for 404 and server-error states;
• who has responsibility for fixes after launch.

If the deployment platform supports preview builds, test the release candidate there first. Record the last known-good version so the team is not trying to reconstruct it during an incident.

A compact launch sequence

My preferred order is:

1. Freeze new features.
2. Test forms and business notifications.
3. Test real mobile devices.
4. Verify crawl/index signals.
5. Measure performance and remove obvious waste.
6. Validate analytics events.
7. Confirm ownership, backup and rollback.
8. Deploy, then repeat the critical checks on production.

The goal is not a perfect audit score. It is a website that loads reliably, can be discovered, captures real enquiries and remains under the business owner's control.

What is the launch check your team learned only after something failed in production?

---

AI-assistance disclosure: I used AI to help organise and edit this checklist. The recommendations were reviewed against my own website-launch process before publication.