Website launch checklist for Australian small businesses: 12 checks that caught real faults
A pre-launch list built from faults we found on our own client sites after launch: forms that did not deliver, tracking that was blocked, http that did not redirect and more.
A launch checklist is only worth following if each item has a reason, so every check below comes from a fault we found on a real site. The twelve checks cover enquiries, tracking, addresses, security, search and email. The first is the one most often skipped: submit a real enquiry and confirm it reaches the person who will answer it.
Enquiries
1. Submit a real enquiry end to end. Use a phone on mobile data and an email address you can read. Check the inbox, the spam folder and the address the lead should reach. After we moved a group of sites to a new host on 28 August, one form sent every enquiry to us instead of the client, one showed an error, and one told visitors they were on a list while quietly failing to send anything. The three cases are in our post on forms that say sent but send nothing.
2. Check where enquiries are routed. On a builder's site, the delivery address was a testing address of ours during the build and had to be switched to the client's inbox at launch. Check it again after the launch, not just before. Settings held outside the site's code are the ones that get left behind.
3. Test the phone links on a phone. Tap the number. A phone number written as plain text, or a link with a typo, loses the call from a trade customer who is already holding their phone.
Tracking
4. Open the console and scroll. A security policy can block Google Analytics and Google Ads tags without any visible sign. On one client site our policy blocked tracking from 2 July to 1 October, and a second site looked fine on arrival but blocked the scroll and engagement events, which only a test that scrolled the pages exposed. Eight audits had passed in between. The method is in our post on Google Ads tracking blocked by your website.
5. Confirm your own visit in the real-time report. Open Google Analytics, load the site, click the contact button and look for the events. A tag in the page's code proves nothing about whether it reports.
Addresses and security
6. Redirect every old address that had traffic. When we rebuilt a workwear supplier's site, the business had a Shopify shop and a WordPress site, and their old addresses are redirected to the matching new pages. Without that, every old link and search result leads to an error. Our post on redesigning without losing your rankings goes into how to build the list.
7. Make http redirect to https, and check both. On 17 August we found five of our client sites serving the http version of the address with a normal page and no redirect. One of those had an http page indexed on its own, with 77 impressions at position 27, beside 119 impressions at position 28 for the https version. The same page was splitting its own signals across two addresses. A padlock on the https version does not tell you what the http version does, so request both.
8. Make sure there is one canonical tag per page. A canonical tag tells search engines which address is the main one for a page. From a rebuild on 9 June, one client site emitted a root-level canonical on every page, beside the page's own. Google still reported the right canonical, but conflicting hints may be ignored. Fixed and verified on 21 September.
Search
9. Check the sitemap dates. If a sitemap says every page changed today, or leaves the date out, Google has less reason to recrawl new pages. We wrote up what happened with a builder's blog in sitemap dates and new posts that are not recrawled.
10. Read the page titles and descriptions. They are what appears in the results. Our audit of 12 of our own sites on 12 October flagged titles and descriptions outside the lengths our audit tool expects, mostly from one template. See the meta title and description audit.
Domain and email
11. Copy every email record before changing name servers. The website and email share a domain but not a service. On one site we copied all 15 records and compared the old and new zones record by record before the switch. The details are in email stopped working after a website move.
12. Phase the switch and check the expiry date. On a rebuild on 9 October, the old hosting target was deleted early, and the client, on a stale DNS answer, saw an error page from the old provider. The rebuild had to restore the old target as a safety net. The rule since is to keep the old target serving for about 48 hours until DNS has settled. Check the domain's expiry and what pays the renewal at the same time, because auto-renew can fail.
The same list as a one-page summary
| Area | Check | Evidence it works |
|---|---|---|
| Enquiries | Real submission arrives | Message in the right inbox |
| Enquiries | Routing address correct | Not a test address |
| Enquiries | Phone links | Tap on a phone |
| Tracking | No blocked requests | Console clean after a scroll |
| Tracking | Events reach Analytics | Visible in the real-time report |
| Addresses | Old URLs redirect | Each old address lands on a page |
| Security | http redirects to https | Request both |
| Search | One canonical per page | View source |
| Search | Sitemap dates accurate | Open sitemap.xml |
| Search | Titles and descriptions | Read them |
| Mail records copied | Send both ways | |
| Domain | Old target kept, expiry known | Calendar entry |
What we skipped
We have not put a speed figure in this list. Speed matters, and our guide to reading a website speed test covers it, but we have not published measured results from our sites, so we do not quote any here.
How this fits a monthly plan
A launch is when these faults are most likely, and several of the faults above (the blocked tracking, the http pages, the root canonical) sat unnoticed for weeks or months after a site went live. That is the reason we charge monthly: the work does not end on launch day. Our base plan has no upfront build fee and includes upkeep, small edits and a monthly report, so this checking stays with the site. To see how we build, read the web design service. To start, get started here.
Common questions
What should I check before launching a website?
Submit a real enquiry and confirm it arrives, test tracking with a scroll and a click, redirect old addresses to new ones, confirm http redirects to https, check that email still works, and look at the sitemap and canonical tags. The list below has twelve checks with the reason for each.
How do I test that my contact form works?
Use your phone on mobile data, submit with an email address you can read, and check the inbox, the spam folder and the address you expect leads to arrive at. A success message on the page does not prove an email left.
Should I keep my old site running after launch?
Yes, for a few days. Name server changes take time to reach every network, and visitors on an out-of-date answer will still be sent to the old address.
How long does a website launch take?
The switch itself can be done in an afternoon. Our plans advertise a 48 hour go live, and the checks below are what decide whether the site is really working afterwards.