Before launch
Check the address, the action, and the evidence
an SME website can look finished while still missing the operational pieces: canonical URLs, SSL, form delivery, redirects, analytics, search metadata, and a rollback plan. The launch checklist below is written for a practical New Zealand SME site, not a large product team with a full release department.
Technical launch checks
Make the public version predictable
Search engines and customers should see one stable version of the website. Before launch, decide the preferred domain, confirm SSL, test redirects, and make sure the sitemap and canonical tags tell the same story.
Canonical domain
Pick apex or www, then redirect the other version. Test HTTP to HTTPS and check that internal links use the preferred version consistently.
Old URL handling
If the site replaces an older one, list important old URLs and redirect them to the closest useful new page. Do not send every old page to the homepage by default.
Indexing signals
Confirm title tags, meta descriptions, canonical tags, robots rules, XML sitemap entries, and important internal links before asking Google to crawl the site.
Performance basics
Check the homepage and core service pages on mobile data. Look for oversized images, layout shifts, slow third-party widgets, and blocked assets.
Search Console
Make crawl and indexing checks explicit after launch
Google Search Central treats sitemaps, canonicals, crawl access, and URL Inspection as separate signals. A sitemap can help discovery, but it does not guarantee indexing. A canonical tells Google your preferred URL, but conflicting redirects, sitemap URLs, or internal links can weaken the signal.
Sitemap signal
List the preferred canonical URLs in the sitemap, keep it at the site root, and submit it in Search Console after launch.
Canonical consistency
Use redirects, `rel="canonical"`, sitemap URLs, and internal links to point at the same preferred URL.
Recrawl expectations
Request indexing only for pages you manage, expect crawling to take time, and monitor Indexing reports rather than assuming instant inclusion.
Launch note
Record the date sitemap was submitted, which URLs were inspected, and what Search Console showed for canonical, crawl, and indexing status.
Customer path
Test the actions that create business value
A launch is not only a design sign-off. It is a working customer path. Someone should be able to find the business, understand the service, make contact, and receive a reply without the process depending on luck or one person's inbox.
Forms
Submit each form from desktop and mobile, confirm the notification arrives, check reply-to details, and make sure the message contains enough context to act on.
Phone and email links
Tap phone links on a mobile device, test mailto links, and check the footer, contact page, and service pages for consistent details.
Service clarity
Each important service page should answer what is offered, who it helps, where it is available, what the next step is, and how to ask for help.
Trust evidence
Use genuine project examples, useful process notes, clear policies, and current contact details. Thin claims are weaker than visible, specific evidence.
Handover
Leave the site maintainable after launch day
Small sites often break later because nobody knows where the domain, DNS, hosting, analytics, or backups live. A short handover note prevents future changes from becoming detective work.
Access register
Record registrar, DNS host, web host, CMS, analytics, Search Console, form provider, email provider, and billing owner in a secure place.
Backup point
Take a pre-launch backup and a post-launch backup. Record what files or database were captured and how to restore them.
Change log
List launch-day changes: redirects, DNS edits, sitemap submissions, analytics setup, plugin updates, and content updates.
Ownership
Make sure the business, not a forgotten contractor account, controls the core domain, hosting, analytics, and recovery channels.
What to test after launch
Once the site is live, test it like a customer: open it on mobile data, search the business name, use the contact path, confirm the sitemap can be fetched, and watch Search Console for crawl errors or pages Google cannot discover.
Launch follow-up
Route post-launch problems to the right support path
A launch issue is easier to fix when the symptom is routed to the right layer. A broken contact form, a missing page in Google, a mail bounce, and a DNS propagation issue all need different evidence. Use the closest path below before changing records, plugins, redirects, or provider settings.
DNS, redirects, or partial reachability
Use DNS and routing support when the issue involves nameservers, A/CNAME records, TTL, SSL, redirects, resolver cache, or different results across networks.
Form email, bounce, or spam placement
Use email deliverability support when launch forms, booking tools, CRMs, invoices, or newsletters need SPF, DKIM, DMARC, sender inventory, or bounce evidence.
Domain, DNS, and email ownership
Use the domains/DNS/email path when the registrar, DNS host, website host, mail provider, or rollback owner is unclear.
Search visibility and indexing basics
Use SEO consulting when the issue is crawl/indexing triage, canonicals, metadata, internal links, structured data, or Search Console interpretation.
Website and search reading path
Use the topic hub when the site needs a broader order: launch checks, SEO basics, source archive proof, technical audits, and measurement.
Services hub
Use the services hub when the launch symptom crosses into Microsoft 365, remote IT support, networking, fibre, website support, or handover work.
Professional context
How launch work connects to current project evidence
Launch checks are most useful when they connect to public evidence: a maintained site, a clear profile, visible projects, and technical notes that explain how the work is kept understandable after launch day.
Current profile
About John Finnerty gives the broader software development and technical consulting context behind these launch notes.
Project examples
The project hub links selected project notes, repositories, and case studies that show the same launch fundamentals in practice.
New Zealand context
The New Zealand profile connects website, DNS, support, and project work into one current owned asset.
Related reading
The DNS and email checklist covers the domain and mailbox layer that should be checked before launch.
Related services
Website launch support and handover checks
Launch-day problems are usually boring and fixable: DNS, redirects, forms, tracking, and missing internal links. The services hub and Christchurch IT support page describe the support areas these checklists connect to.