The complete website launch checklist — pre-launch and post-launch, step by step

Why a launch checklist matters more than the build

A beautifully built website can still fail on launch day. The most expensive mistakes in a web project almost never happen during design or development — they happen in the few hours when a site moves from staging to production and a single missed setting silently undoes months of work.

The classic example is the staging noindex tag. Designers block search engines from crawling the staging site so unfinished pages do not get indexed. That tag is correct on staging and catastrophic on production. When it ships to the live site unremoved, Google obediently keeps every page out of its index — and the business spends six weeks wondering why a brand-new site generates zero organic traffic before someone finally checks the robots meta tag. It is the most common launch failure in the industry, and it is entirely preventable with one checklist item.

The second category of launch failure is the redesign that forgets redirects. A new site with new URLs throws away every backlink, every bookmark, and every ranking the old URLs earned unless each old address 301-redirects to its new equivalent. A Canadian business that ranked on page one for "commercial cleaning Mississauga" can drop off the map entirely the day a new site goes live without a redirect map. The traffic loss is real, immediate, and slow to recover.

The third category is the broken conversion path. A form that worked perfectly on staging but routes to a dead inbox on production, a payment button that 404s, a phone number that is wrong on the mobile header — these are revenue leaks that look invisible because the site appears to work. Every one of them is caught by a disciplined end-to-end test before and after go-live.

A launch checklist is insurance. It costs a few hours of methodical verification and it protects the entire investment in the site. Run it in two passes: a pre-launch pass on staging in the days before go-live, and a post-launch pass on the live URL within minutes of the site going public.

Pre-launch vs. post-launch at a glance

The table below splits the full checklist into the two phases. Pre-launch items are verified on staging or in your CMS before the DNS cutover; post-launch items can only be confirmed once the site is live on its real domain.

Work top to bottom in each column. The sections below expand every row into specific, actionable steps you can hand to a developer or run yourself.

SEO launch checklist: don't lose visibility on day one

SEO at launch is mostly about not breaking what already works and giving Google clean signals to crawl the new site. It is far easier to preserve rankings than to rebuild them, so this section is the highest-stakes part of any launch.

Start with on-page fundamentals. Every page needs one unique <title> tag under about 60 characters and one unique meta description under about 155 characters. Duplicate titles across pages confuse Google and waste ranking potential. Each page needs exactly one <h1>, with a logical h2/h3 structure beneath it. Image alt text should be present and descriptive on every meaningful image — it serves both accessibility and image search.

Next, confirm your structured data. Add the schema types relevant to the business — LocalBusiness and Service for service companies, Product and Offer for ecommerce, Article for editorial pages, and FAQPage wherever you publish genuine question-and-answer content. Validate every block in Google's Rich Results Test before launch; a single malformed JSON-LD block can disqualify a page from rich results.

Build and validate an XML sitemap that lists only canonical, indexable URLs — no redirect targets, no noindex pages, no parameter duplicates. Reference it in robots.txt. Set a self-referencing canonical tag on every page so Google knows the preferred URL when query strings or trailing slashes create duplicates.

The pre-launch SEO checklist:

• ☑ Unique title tag (≤60 chars) and meta description (≤155 chars) on every page.
• ☑ One H1 per page with a logical heading hierarchy below it.
• ☑ Descriptive alt text on every content image.
• ☑ Self-referencing canonical tags set site-wide.
• ☑ Schema markup added and validated in the Rich Results Test.
• ☑ XML sitemap generated with only canonical, indexable URLs.
• ☑ robots.txt allows crawling and references the sitemap.
• ☑ Open Graph and Twitter card tags set so shared links preview correctly.
• ☑ Internal links updated to new URLs — no links pointing at old or staging addresses.
• ☑ 404 page is custom and helpful, linking back to key sections.

For a local Canadian business, double-check that your NAP (name, address, phone) on the site matches your Google Business Profile and major directories exactly — inconsistency dilutes local ranking signals. The local SEO guide covers the directory and citation work that should accompany a new launch.

Redirects: the step most redesigns get wrong

If your URLs are changing — a different CMS, a new structure, a domain change, or simply cleaner slugs — redirects are not optional. A 301 (permanent) redirect tells search engines that a page has moved and passes the large majority of its accumulated ranking authority to the new URL. Without it, the old page returns a 404, the authority evaporates, and any inbound link pointing at the old URL leads visitors to a dead end.

Do this before launch, methodically:

1. Crawl the old site to capture every URL. Use Screaming Frog, Sitebulb, or export the existing Search Console "Pages" report. You want a complete inventory of every indexed URL, including PDFs and images that earn traffic. Pull your top landing pages from Google Analytics so you prioritize the URLs that actually drive visits.
2. Map each old URL to its closest new equivalent. Build a spreadsheet with two columns: old URL and new URL. Map like-for-like where possible. When a page no longer exists, redirect to the most relevant parent category — never blanket-redirect everything to the homepage, which Google treats as a soft 404 and ignores.
3. Implement 301 redirects, not 302s. A 302 is temporary and does not pass authority reliably. Implement the rules in your server config, CMS redirect manager, or a plugin (Redirection for WordPress is the common choice). Avoid redirect chains — old URL should point directly to the final new URL, not hop through two or three intermediaries.
4. Preserve the HTTPS and www/non-www canonical. Force a single canonical host: pick https://www. or https:// (non-www) and redirect the other variant. Mixed canonicals split your authority and create duplicate-content noise.
5. Test every redirect after launch. Re-crawl the old URL list against the live site and confirm each returns a single 301 to a live 200-status page. Fix any that resolve to 404s or chains. Watch the Search Console "Pages" report for the first month for crawl errors and address them promptly.

If the domain itself is changing, also use the Search Console "Change of Address" tool to signal the move to Google, and keep the redirects in place for at least a year — search engines and inbound links take time to fully migrate.

Performance and Core Web Vitals checklist

Core Web Vitals are part of Google's ranking signals and a direct driver of conversion. A site that loads slowly on mobile loses visitors before the page even renders. Google measures three field metrics, and your launch target is to pass all three on mobile, which is the harder bar.

Note that INP replaced First Input Delay as a Core Web Vital — make sure any older audit you rely on is measuring INP. Run both a lab test (PageSpeed Insights, Lighthouse) and, after the site has live traffic, the field data in the Search Console Core Web Vitals report.

The performance launch checklist:

• ☑ Compress and right-size every image. Serve modern formats (WebP or AVIF), set explicit width and height to prevent layout shift, and lazy-load anything below the fold.
• ☑ Preload the LCP image (usually the hero) so it paints fast; mark it loading="eager", not lazy.
• ☑ Minify and defer JavaScript and CSS. Remove render-blocking resources; defer non-critical scripts; eliminate unused code from page builders.
• ☑ Enable caching and a CDN. Browser caching plus a content delivery network keeps Canadian visitors fast whether they load from Vancouver or St. John's.
• ☑ Reserve space for ads, embeds, and fonts to keep CLS under 0.1; use font-display: swap and preconnect to font hosts.
• ☑ Test on a throttled mobile connection, not just your office fibre — your visitors are on transit and patchy LTE.
• ☑ Confirm the page weight is reasonable — aim for under 2 MB total on the homepage where feasible.

The full optimization workflow — including how to diagnose a failing LCP and reduce INP — lives in the page speed and Core Web Vitals guide. Run PageSpeed Insights on the live URL the moment the site is public, because lab scores on staging do not always match production with real DNS, CDN, and caching behaviour.

Analytics and GA4 setup checklist

If you launch without analytics, the first weeks of traffic — often your most informative — are lost forever. Analytics cannot be backfilled, so this must be live on day one. Google Analytics 4 (GA4) is the current standard; Universal Analytics was fully retired, so any guide referencing UA properties is outdated.

The analytics launch checklist:

• ☑ Create a GA4 property and install the tag on every page — ideally through Google Tag Manager so you can manage events without code changes.
• ☑ Verify real-time data records by loading the live site and watching the GA4 Realtime report show your own session.
• ☑ Configure key conversion events — form submissions, phone-number taps, button clicks, and (for ecommerce) purchase events — and mark them as conversions in GA4.
• ☑ Verify the property in Google Search Console and link it to GA4 so you see search queries alongside behaviour.
• ☑ Filter out internal traffic so your own team's visits do not distort the data.
• ☑ Set data retention and IP handling appropriately — GA4 anonymizes IPs by default, which supports PIPEDA and Law 25 compliance, but document it in your privacy policy.
• ☑ Add Bing Webmaster Tools as well — it is free, takes ten minutes, and Bing powers a meaningful slice of Canadian search plus several AI assistants.
• ☑ Gate marketing tags behind consent where your consent banner requires it, so analytics and ad pixels only fire after the visitor agrees.

Test the conversion events the same way a visitor would: submit the real form, tap the real phone link on a phone, complete a test purchase if you run ecommerce. An event that exists in your configuration but never fires on the live site is worse than no event, because it gives you false confidence in empty data.

Security and SSL launch checklist

Security at launch protects both your visitors and your search rankings. A site without HTTPS triggers a "Not Secure" warning in every modern browser, which devastates conversion and trust. HTTPS is also a confirmed Google ranking signal. The good news is that getting it right is straightforward.

The security launch checklist:

• ☑ Install a valid SSL/TLS certificate. Most quality Canadian hosts include a free Let's Encrypt certificate; confirm it covers both www and the apex domain.
• ☑ Force HTTPS site-wide with a server-level redirect so every HTTP request upgrades to HTTPS automatically.
• ☑ Eliminate mixed content. Scan for any images, scripts, or stylesheets still loading over http:// — a single insecure asset breaks the padlock on the whole page.
• ☑ Set security headers — HSTS, X-Content-Type-Options, X-Frame-Options or a frame-ancestors Content-Security-Policy, and Referrer-Policy.
• ☑ Harden the CMS. Update core, themes, and plugins to current versions; remove unused plugins; change default admin usernames; enforce strong passwords and two-factor authentication on all admin accounts.
• ☑ Install a firewall and malware scanner (Wordfence, Sucuri, or your host's WAF) and enable automatic security updates.
• ☑ Protect forms with spam filtering — a honeypot field plus rate limiting or a privacy-respecting CAPTCHA stops bot submissions from flooding your inbox.
• ☑ Confirm ecommerce checkout is PCI-DSS compliant. Use a hosted gateway (Stripe, Shopify Payments, Square) so card data never touches your server.

After launch, load several pages and confirm the padlock appears on each. Run a free SSL check (SSL Labs) to confirm the certificate chain is complete and the grade is A or better. A certificate that is valid but misconfigured can still throw warnings on some devices.

Accessibility checklist (WCAG 2.1 AA basics)

Accessibility is both a legal consideration and a quality baseline. In Canada, organizations subject to the Accessibility for Ontarians with Disabilities Act (AODA) and similar provincial laws — including the Accessible Canada Act for federally regulated entities and British Columbia's Accessible BC Act — are increasingly expected to meet WCAG 2.1 Level AA. Beyond compliance, an accessible site reaches more customers and tends to be cleaner, faster, and better for SEO.

The accessibility launch checklist:

• ☑ Colour contrast meets AA — at least 4.5:1 for normal text and 3:1 for large text. Test with a contrast checker, not your eyes.
• ☑ Every image has appropriate alt text, and decorative images use empty alt="" so screen readers skip them.
• ☑ The whole site is keyboard-navigable — you can reach and operate every link, button, and form field with Tab and Enter, with a visible focus indicator.
• ☑ Forms have proper labels tied to inputs, and errors are announced in text, not colour alone.
• ☑ Headings are structured logically (one H1, no skipped levels) so screen-reader users can navigate by heading.
• ☑ Interactive elements use semantic HTML or ARIA roles — a clickable <div> is invisible to assistive tech; use real buttons and links.
• ☑ Video and audio have captions or transcripts, and nothing auto-plays sound.
• ☑ Text resizes to 200% without breaking layout, and the site works in both orientations on mobile.

Run an automated scan (axe DevTools, WAVE, or Lighthouse) to catch the obvious failures, but do not stop there — automated tools catch perhaps a third of real issues. Tab through the live site with your keyboard and run one page through a screen reader (VoiceOver on Mac, NVDA on Windows) to find the problems automation misses. The full method is in the web accessibility (WCAG) guide.

Forms, email, and conversion-path checklist

Forms are where a website earns its keep, and they are the single most common thing to break silently at launch. The form looks fine, the success message appears — but the email never arrives, because the production mail configuration differs from staging. Test every conversion path as a real user, end to end, on the live site.

The forms and email launch checklist:

• ☑ Submit every form on the live site and confirm the notification email actually lands in the right inbox — not spam, not a dead alias.
• ☑ Confirm the auto-reply (if any) reaches the submitter and reads correctly with no placeholder text.
• ☑ Check the success state and error state — required-field validation should be clear, and a failed submission should never lose the visitor's typed data.
• ☑ Verify CRM/automation routing — if leads flow to HubSpot, Zoho, Mailchimp, or a spreadsheet, confirm a test submission appears there.
• ☑ Set up SPF, DKIM, and DMARC on the sending domain so your transactional and notification emails are not flagged as spam.
• ☑ Add CASL-compliant consent to any newsletter or marketing signup — Canada's Anti-Spam Legislation requires express or implied consent and a clear unsubscribe path, and it is actively enforced.
• ☑ Test every call-to-action — phone links dial on mobile, mailto links open a client, map links open the right location, and booking widgets (Calendly, Jane, Acuity) load and accept a test booking.
• ☑ Confirm anti-spam protection works without blocking real users — a broken CAPTCHA silently kills conversions.

For ecommerce, extend this to the entire purchase flow: add to cart, apply a discount code, calculate Canadian shipping and taxes correctly by province, complete a real test transaction, and confirm the order confirmation email and any fulfilment notification both fire. A checkout that fails at the payment step is invisible until you actually run a card through it.

Backups and rollback plan

Launch day is exactly when you most want a way back. Before you flip the switch, you need a known-good backup and a tested plan to restore it if something goes badly wrong. This is not paranoia — DNS changes, plugin conflicts, and migration errors do happen, and the difference between a ten-minute hiccup and a two-day outage is whether you prepared a rollback.

The backup and rollback checklist:

• ☑ Take a full backup of the old live site (files plus database) before any DNS or hosting change, and store it offsite — not only on the same server.
• ☑ Take a full backup of the new site immediately after launch, once content is final, as your clean baseline.
• ☑ Confirm automated backups are scheduled going forward — daily for active or ecommerce sites, weekly at minimum for brochure sites.
• ☑ Verify the restore actually works by doing a test restore to a staging environment — an untested backup is a hope, not a plan.
• ☑ Document the rollback steps and DNS TTL so you know how fast you can revert if launch goes sideways. Lower the DNS TTL a day before launch so changes (and reversals) propagate quickly.
• ☑ Store backups in two locations — host plus an independent cloud (the off-host copy is what saves you when the host itself is the problem).

Where your backups and customer data are stored has a privacy dimension too: if you process the personal information of Quebec residents, Law 25 imposes obligations around data location and breach notification. Keep a record of where backups live and who can access them.

Legal, privacy, and PIPEDA compliance checklist

Any Canadian website that collects personal information — even something as ordinary as a contact form or analytics cookie — has legal obligations. The federal baseline is PIPEDA (the Personal Information Protection and Electronic Documents Act). Quebec adds Law 25 (formerly Bill 64), which is stricter and now fully in force, and Alberta and B.C. have their own private-sector privacy laws. Getting the legal pages right at launch avoids complaints, fines, and the scramble of retrofitting consent later.

The legal launch checklist:

• ☑ Publish a privacy policy that states what data you collect, why, how it is used, where it is stored, how long you keep it, and how visitors can request access or deletion. Name a contact for privacy inquiries — Law 25 requires a designated privacy officer.
• ☑ Publish terms of service / terms of use.
• ☑ Add a cookie/consent banner where you use analytics or marketing cookies. Under Law 25, consent must be clear and granular, and tracking should not fire before consent is given.
• ☑ Make signup consent CASL-compliant with explicit opt-in language and a working unsubscribe link in every marketing email.
• ☑ Add a return, refund, and shipping policy for ecommerce, plus clear pricing in CAD and tax handling by province.
• ☑ Provide an accessibility statement if you are subject to AODA or similar — many Canadian organizations are required to publish one.
• ☑ Confirm copyright and licensing on all images, fonts, and content — stock licences cover the use, and you own or have rights to every asset on the site.
• ☑ For bilingual or Quebec-facing sites, ensure French content meets the Charter of the French Language (Bill 96) requirements where applicable.

Template legal pages from a reputable Canadian source are a reasonable starting point for a small brochure site, but anything handling payments, health data, or significant personal information warrants a review by a Canadian lawyer. Budget CA$500–$2,000 for proper legal pages on a transactional site — far cheaper than a privacy complaint.

Cross-device and cross-browser QA checklist

Your site does not exist on your monitor — it exists on hundreds of screen sizes, browsers, and connection speeds. The majority of Canadian web traffic is now mobile, so mobile is the primary test surface, not an afterthought. QA the real experience on real hardware, because emulators and responsive-mode previews miss touch-target sizing, font rendering, and performance quirks.

The QA launch checklist:

• ☑ Test on real devices — at minimum one iPhone (Safari) and one Android (Chrome), plus a tablet. Borrow phones if you have to; do not ship blind.
• ☑ Test the major browsers — Chrome, Safari, Firefox, and Edge — on desktop. Safari in particular renders some CSS differently.
• ☑ Check every breakpoint — phone portrait and landscape, tablet, laptop, and large desktop. Look for overflow, overlapping elements, and broken grids.
• ☑ Verify touch targets are large enough (about 44×44px) and not crowded together on mobile.
• ☑ Proofread every page. Typos, placeholder "Lorem ipsum," wrong phone numbers, and broken French accents (mojibake) all survive into production more often than anyone admits.
• ☑ Click every link. Run a broken-link crawler and manually click the navigation, footer, and key CTAs. Internal links should point to live new URLs, not staging.
• ☑ Test the navigation and search — mobile menu opens and closes, dropdowns work on touch, and any on-site search returns results.
• ☑ Confirm the favicon, social share previews, and 404 page all render correctly.

A practical tactic: get two or three people who did not build the site to run through it on their own phones and report anything confusing. Fresh eyes catch the broken thing the build team has stopped seeing. Responsive behaviour patterns are covered in depth in the responsive web design best practices guide.

Launch day: the go-live sequence

With pre-launch QA complete, launch day is a tight, ordered sequence. Run it early in the week — Tuesday or Wednesday morning — so the whole team is available to respond. Never launch on a Friday or before a long weekend; if something breaks, you do not want it bleeding traffic and leads through three days when nobody is watching.

1. Take the final pre-launch backup of both the old and new sites, stored offsite. This is your rollback point.
2. Point DNS / publish the site. With DNS TTL already lowered the day before, the cutover propagates within minutes to a couple of hours.
3. Remove the noindex tag immediately. This is the make-or-break step. Confirm the robots meta tag is gone and robots.txt allows crawling. Run a live check on three or four pages.
4. Confirm SSL and force-HTTPS work on the live domain — padlock on every page, no mixed-content warnings.
5. Submit the XML sitemap in Google Search Console and Bing Webmaster Tools, then request indexing of the homepage and top pages via URL Inspection.
6. Verify analytics records live traffic — load the site and watch the GA4 Realtime report show your session.
7. Run the redirect crawl against your old-URL list and fix any 404s or chains on the spot.
8. Test forms and checkout end-to-end on production — submit, confirm the email lands, run a test order if you sell online.
9. Run PageSpeed Insights on the live URL and re-check Core Web Vitals with real DNS/CDN behaviour.
10. Monitor for 48 hours. Watch Search Console for crawl errors, GA4 for traffic anomalies, and your inbox for form submissions. Address issues immediately while attention is high.

A clean go-live sequence turns launch day from a high-stress gamble into a routine, checkable process. The teams that ship calmly are simply the ones running a list.

The first 30 days after launch

Launch is the start of the work, not the end. The first month is when you confirm everything is healthy and start turning a working site into a performing one. A new site does not rank overnight — Google needs to recrawl, reindex, and re-evaluate, which takes weeks — so patience plus monitoring is the right posture.

The 30-day post-launch checklist:

• ☑ Watch Search Console "Pages" coverage daily for the first two weeks — confirm new URLs are getting indexed and old URLs are dropping out cleanly via redirects.
• ☑ Monitor Core Web Vitals field data as real-user data accumulates; lab and field scores can diverge.
• ☑ Track conversions in GA4 against a baseline — if form submissions or sales drop versus the old site, investigate the conversion path immediately.
• ☑ Fix crawl errors and broken links as Search Console surfaces them.
• ☑ Update your Google Business Profile and key directories with the new URL and confirm NAP consistency.
• ☑ Confirm the first scheduled backup ran and is restorable.
• ☑ Review behaviour data — high-bounce pages, low scroll depth, and drop-off points reveal the first round of improvements.
• ☑ Plan a content and SEO cadence — the launch was the foundation; ongoing content is what builds rankings over the following months.

If organic traffic dips in the first week or two after a migration, do not panic and start changing things at random — a temporary dip while Google re-evaluates is normal. Confirm your redirects, indexability, and Core Web Vitals are clean, then give it time. If the dip persists past four to six weeks with all technicals verified, that is when deeper investigation is warranted.

FAQ: website launch checklist