The most expensive website launch problems are often painfully ordinary. A quote form submits successfully but sends the message to an old inbox. The phone number works on desktop but is not tappable on mobile. A staging password is removed from the homepage but not from the pricing page. Analytics records visits but not the actions the business actually cares about.
None of these problems requires a dramatic technical failure. They happen when a team checks whether the site looks finished but does not check whether the complete customer journey works. A strong launch review connects content, design, development, search, accessibility, privacy, security, and business operations.
This 25-step checklist is written for Canadian small businesses launching a new website or redesign in 2026. It is deliberately practical: each item explains what to inspect, why it matters, and what evidence to keep before changing the domain or announcing the site.
Business foundation: make the website useful before making it live
1. Confirm the audience, goal, and primary action
Write one sentence describing who the website serves, what problem that person is trying to solve, and what action the business wants next. The primary action might be requesting a quote, calling, booking, buying, visiting a location, or starting a trial. A page can contain several options, but visitors should not have to guess which one matters.
Use the sentence as a launch test. Does the homepage explain the offer without internal jargon? Is the main action visible on a small phone? Does the action lead to a working process with an owner? If the answer depends on a future content update, the page is not finished.
2. Give every page one clear purpose
List the pages intended for launch and assign each a visitor question, business goal, primary search topic, and next step. This prevents two service pages from competing with nearly identical content and exposes pages that exist only because they were in an old menu.
| Page | Visitor question | Primary action | Evidence of readiness |
|---|---|---|---|
| Homepage | Is this company relevant and trustworthy? | Choose a service or contact the business | Offer, service area, proof, and next step are clear |
| Service page | Can this company solve my specific problem? | Request a consultation or quote | Scope, outcomes, process, FAQs, and limitations are accurate |
| About page | Who is behind the business? | Build confidence or make contact | Real identity, experience, location, and claims are approved |
| Contact page | How can I reach the right person? | Submit, call, email, or visit | Every channel works and has an accountable recipient |
3. Verify every claim, price, location, and contact detail
Read the production copy as a customer, not as its author. Confirm service areas, prices, turnaround times, certifications, staff names, testimonials, business hours, policies, and availability. Remove placeholder text, stock-template claims, expired promotions, and links to draft documents.
Search the repository or content system for old phone numbers, domains, email addresses, legal names, and test values. A polished contact page does not help if the footer, structured data, checkout email, or PDF still carries outdated information.
4. Approve proof, images, and content rights
Confirm permission to publish customer names, logos, reviews, project screenshots, staff photos, and case-study results. Keep the source and approval for each asset. Write useful alternative text for informative images, and use empty alt text for decorative images so assistive technology can skip them.
Compress and size images for their displayed use. A full-resolution camera photo should not be sent to a small card. Avoid placing essential text only inside an image because it becomes harder to read, translate, resize, search, and maintain.
Customer journeys: test the website as a real visitor
5. Test navigation, search, breadcrumbs, and the logo link
Open every header, footer, mobile-menu, breadcrumb, card, and in-page link. Confirm the logo returns home, the current location is understandable, menus can be closed, and no important page is isolated. Use descriptive link text such as “Microsoft 365 migration services” instead of repeating “learn more” everywhere.
6. Test real mobile devices and narrow screens
Responsive screenshots are a useful start, but they do not reproduce every browser, keyboard, touch, and network behaviour. Test at least one current iPhone and Android device if possible. Check menus, sticky bars, modals, forms, maps, tables, horizontal scrolling, text size, tap targets, orientation changes, and the on-screen keyboard.
Google uses mobile-first indexing, so mobile content and metadata should not be a reduced or inconsistent version of the desktop experience. More importantly, customers should be able to complete the same important task without pinching, guessing, or dismissing overlapping elements.
7. Submit every form from beginning to end
Test contact, quote, booking, newsletter, login, password-reset, search, payment, and upload forms with valid and invalid input. Confirm labels, required fields, error messages, keyboard focus, spam protection, success messages, notifications, CRM records, autoresponders, and mobile behaviour.
- Use a real external address rather than only a company-domain account.
- Confirm the message reaches the correct person and does not land in spam.
- Check that replies go to the visitor when appropriate, not to a no-reply address.
- Test duplicate submissions, slow connections, large messages, and expired sessions.
- Ensure sensitive values do not appear in URLs, analytics events, or unnecessary notification emails.
- Record who owns each lead and the expected response time after launch.
8. Verify phone, email, maps, scheduling, and external links
Call every displayed number, tap every email address, open every map pin, and complete a test booking. Confirm social profiles, payment pages, review links, partner portals, downloadable files, and third-party widgets. External services change independently, so keep a short list of launch-critical dependencies and their owners.
9. Design useful empty, error, and unavailable states
Test a missing page, an empty search, a failed form, an unavailable product, a declined payment, and a disconnected integration. A helpful error state explains what happened in plain language, preserves entered information where safe, offers a next step, and gives the support team enough context to investigate without exposing technical secrets.
10. Check supported browsers without demanding identical pixels
Agree which browsers and device versions the business will support, then test the core journeys in them. The goal is equivalent access and function, not perfect visual identity. Pay attention to older embedded browsers, privacy settings, autofill, date inputs, file uploads, and third-party scripts that behave differently across platforms.
Accessibility and performance: make the experience usable
11. Complete important journeys with a keyboard
Start at the address bar and use Tab, Shift+Tab, Enter, Space, Escape, and arrow keys. Focus should be visible, move in a logical order, reach every interactive control, and escape menus or dialogs. Skip links and semantic headings help people move past repeated navigation.
W3C organizes WCAG 2.2 around content being perceivable, operable, understandable, and robust. Automated tools can find some problems, but keyboard use, zoom, screen-reader behaviour, error clarity, and real human testing still require judgment.
12. Review contrast, zoom, headings, labels, and media
- Zoom to 200 percent and confirm content remains readable and operable without losing essential information.
- Check text and control contrast, including hover, focus, disabled, error, and placeholder states.
- Use one descriptive H1 and a logical heading hierarchy rather than choosing headings for size alone.
- Associate visible labels and instructions with form fields; do not rely on placeholder text as the label.
- Provide captions or transcripts where audio or video carries important information.
- Avoid unexpected movement, flashing, autoplay, and interactions that require precise dragging when a simpler option can be provided.
13. Measure Core Web Vitals on representative pages
Measure the homepage, the heaviest service or product page, an article, and the primary conversion page. Current Core Web Vitals are Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. Chrome's published “good” thresholds are LCP at 2.5 seconds or less, INP at 200 milliseconds or less, and CLS at 0.1 or less, evaluated at the 75th percentile.
Laboratory tests are valuable before launch; field data shows what real visitors experience after launch. Optimize the largest visible image, fonts, script execution, third-party tags, caching, server response, and layout dimensions. Do not remove useful content merely to produce a perfect score; improve the delivery of the experience the customer needs.
Search readiness: help engines discover and understand the right pages
14. Confirm production pages are indexable—and private pages are not
Inspect HTTP status codes, robots directives, password protection, canonical tags, and response content on the final production URLs. Remove staging-wide noindex controls only when the site is truly ready. Keep account, checkout, internal search, test, and duplicate utility URLs out of search when appropriate.
Do not use robots.txt as a privacy control. Google states that robots.txt manages crawler access and is not a reliable mechanism for keeping a page out of search. Sensitive content should require proper authentication; pages that may be crawled but should not be indexed need an appropriate noindex control.
15. Freeze URLs and map redirects before launch
Use short, descriptive, stable URLs. If the launch replaces an existing site, export the old indexable URLs and map each important one to the most relevant new destination with a permanent server-side redirect. Avoid sending every retired page to the homepage; that hides missing content and creates a poor visitor experience.
Update internal links to the final URLs rather than relying on redirects. Test redirect chains, loops, mixed HTTP and HTTPS behaviour, www and non-www handling, trailing slashes, uppercase paths, campaign links, and bookmarked legacy pages.
16. Write unique titles, descriptions, and social previews
Give each important page a concise title that reflects its primary topic and business, plus a useful meta description that accurately previews the page. These elements influence understanding and may influence how a result is presented, but a search engine may generate a different snippet.
Set canonical URLs and Open Graph or comparable social metadata. Share the production URL in the messaging tools customers actually use and inspect the resulting preview. Confirm the title, description, image, dimensions, secure URL, and brand name are correct.
17. Check headings, visible content, and internal links
Important information should be present in accessible page content, not hidden only inside an image, animation, or script interaction. Link related services, examples, FAQs, and articles where the relationship helps a visitor. Internal links support discovery and clarify site structure, but they should read naturally rather than repeating a keyword unnaturally.
18. Generate the XML sitemap and verify robots.txt
Include preferred canonical, indexable URLs in the XML sitemap and use accurate modification dates. Exclude redirects, errors, duplicate parameters, private pages, and alternate URLs that should not appear in search. Reference the sitemap from robots.txt and submit it through Google Search Console after launch.
19. Add only accurate, relevant structured data
Structured data can give machines explicit information about a page and make eligible content understandable for certain search features. Use types that match visible content, such as Organization, LocalBusiness when applicable, BreadcrumbList, Article, Product, or FAQ-related markup where supported and appropriate.
Validate syntax and required properties, keep markup consistent with what a visitor can see, and use the canonical production URLs. Structured data does not guarantee a rich result, ranking, or recommendation by an AI system. It improves machine-readable context and eligibility when implemented accurately.
Privacy, email, and security: protect the business and its visitors
20. Inventory every piece of personal information the site collects
List data collected through forms, accounts, chat, analytics, advertising tags, payments, scheduling, embedded media, cookies, logs, and third-party services. For each item, record the purpose, destination, access, retention, deletion process, and whether information crosses a provincial or national border.
Canadian privacy obligations depend on the organization, province, industry, data, and activity. PIPEDA sets principles including accountability, identifying purposes, consent, limiting collection and retention, safeguards, openness, and access. Alberta, British Columbia, and Quebec have substantially similar private-sector laws, and sector-specific rules may also apply. Treat this checklist as an engineering and content review, not legal advice.
21. Make privacy explanations and choices meaningful
Explain what information is collected, why, which important third parties receive it, how long it is kept, and how a person can ask questions or exercise applicable rights. Place important explanations where the decision occurs instead of burying everything in one long policy.
The Office of the Privacy Commissioner of Canada says valid consent should be meaningful: people should reasonably understand the nature, purpose, and consequences of the collection, use, or disclosure. Review analytics, advertising, chat, video, and cookie tools against the site's actual consent design and applicable requirements.
22. Separate an inquiry from marketing consent
A person requesting a quote is not automatically asking for every future newsletter. If the site collects email or text-message marketing subscriptions, design the wording, records, unsubscribe process, sender identification, and message workflow around Canada's Anti-Spam Legislation and any other applicable rules.
Official CASL guidance states that businesses generally need consent before sending commercial electronic messages. Consent can depend on context and legal exceptions, so have the final workflow reviewed when the business is uncertain. Test that unsubscribe requests work promptly throughout the email platform, CRM, and any connected automation.
23. Harden the production website and administration path
- Enforce HTTPS and test certificate renewal, redirects, mixed content, and secure cookies.
- Remove test accounts, sample applications, debug output, directory listings, and unused plugins or integrations.
- Use unique administrator accounts, least privilege, multifactor authentication, and protected recovery methods.
- Store secrets outside source code and the browser; rotate credentials exposed during development.
- Patch the operating system, runtime, framework, CMS, plugins, themes, dependencies, and management tools.
- Apply appropriate security headers, request limits, bot controls, input validation, output encoding, and upload restrictions.
- Back up content, configuration, databases, keys, and recovery instructions, then prove that restoration works.
- Define who receives security alerts and how a vulnerability, compromised account, or malicious change will be handled.
The Canadian Centre for Cyber Security recommends timely patching and replacing unsupported products. Launch-day hardening should become an ongoing maintenance process because internet-facing software, dependencies, credentials, and threats continue to change.
Measurement and operations: know whether the launch works tomorrow
24. Validate analytics, conversions, and operational alerts
Decide which actions represent value—qualified form submissions, calls, bookings, purchases, downloads, directions, or account creation—and test each event in the production analytics property. Exclude internal traffic where appropriate, preserve campaign parameters, confirm consent behaviour, and prevent sensitive form values from entering analytics.
Analytics cannot replace operational monitoring. Add uptime checks for critical pages and journeys, error tracking, form-delivery monitoring, certificate and domain renewal reminders, backup alerts, and a contact who can respond. A green homepage does not prove that checkout, authentication, or lead delivery works.
25. Write the launch, rollback, and first-30-days plan
Choose a launch window with the right people available. Lower DNS time-to-live in advance when a migration requires it, preserve the old environment long enough for a safe rollback, take backups, freeze risky content changes, and write the exact deployment and verification order.
| When | Review | Owner evidence |
|---|---|---|
| Before cutover | Backups, DNS, certificates, redirects, environment values, forms, analytics, monitoring, and rollback trigger | Approved launch record |
| First hour | Homepage, priority pages, mobile journey, form delivery, transactions, redirects, robots controls, logs, and alerts | Timestamped smoke-test results |
| First 48 hours | Search Console access, sitemap processing, crawl errors, traffic, conversions, customer feedback, email delivery, and performance | Issue list with owners and priority |
| First 30 days | Real Core Web Vitals, search queries, lead quality, broken links, accessibility feedback, security updates, content gaps, and conversion friction | Measured improvement backlog |
Do not delete the old site, DNS records, analytics history, or source material during the excitement of launch. Record what changed, when it changed, who approved it, and how to reverse it. Schedule ownership for content, security, dependencies, backups, forms, domains, certificates, privacy reviews, and performance.
The launch-day shortlist
- Primary audience, offer, service area, and conversion action are clear.
- Every launch page has an owner, purpose, approved copy, and working next step.
- Navigation, forms, calls, bookings, payments, email delivery, and error paths were tested.
- Core journeys work on real mobile devices, current browsers, keyboard, and zoom.
- Production URLs, redirects, canonicals, titles, descriptions, social previews, robots controls, and sitemap are correct.
- Relevant structured data matches visible content and passes validation.
- Privacy explanations, consent choices, marketing subscriptions, retention, and third parties match the real implementation.
- HTTPS, administration, secrets, patches, backups, logging, alerts, and restoration are ready.
- Analytics records meaningful outcomes without collecting unnecessary sensitive information.
- The launch owner has a smoke test, rollback criteria, contact list, and 30-day improvement plan.
The bottom line
A strong website launch is not the moment a new design appears. It is the moment customers can understand the offer, complete important tasks, trust how their information is handled, and reach a business that is ready to respond.
Use the checklist to collect evidence, not to chase a ceremonial row of green boxes. Fix anything that can lose a lead, expose information, block a customer, break an existing URL, or leave the team blind after launch. Record lower-risk improvements for the first 30 days, publish deliberately, and keep improving from real behaviour rather than assumptions.