Website analytics QA checklist before launch

A website can look finished and still be impossible to measure. The design may be approved, the CMS may be populated, and the pages may load quickly, but if form submissions, booking clicks, ecommerce actions, campaign parameters, and search data are not captured correctly, the team loses the ability to learn after launch.

This website analytics QA checklist is for redesigns, Shopify storefront updates, WordPress theme launches, B2B website builds, and headless commerce migrations. Use it before launch day, not after the first performance report looks wrong. Analytics QA is part technical SEO, part conversion QA, and part operational handoff.

Start with a tracking map, not the analytics interface. A useful tracking map lists the user action, page or template, trigger rule, analytics destination, event name, parameters, owner, and expected business question. If the business question is unclear, the event will probably become noise.

Keep the map short enough that the team can maintain it. A B2B service site may only need form submissions, CTA clicks, booking links, downloads, phone links, email links, video plays, and key navigation events. A Shopify site may also need product views, add to cart, checkout starts, purchases, subscription actions, bundle interactions, and discount usage.

• Event name: the exact name that should appear in reporting.
• Trigger: click, form submit, route change, checkout action, file download, or visible component.
• Parameters: page type, service, product, campaign, locale, market, form type, or CTA position.
• Owner: who approves the event and who checks it after launch.

Before testing individual events, confirm the basics. Google Analytics 4, Google Tag Manager, consent tools, ad pixels, Search Console, Bing Webmaster Tools, CRM embeds, email platform scripts, and booking tools should load only where they are supposed to load. Duplicate tags are a common reason reports become inflated or inconsistent.

Check production and staging separately. Staging should be usable for QA, but it should not pollute production reports. Production should not depend on a temporary debug container or a developer account. For multilingual and multi-market sites, confirm the same rules work across language routes, localized URLs, and market-specific templates.

• Confirm one primary analytics property and one primary tag manager container.
• Block staging traffic from production reporting when possible.
• Check consent mode behavior before and after accepting cookies.
• Verify that route changes fire page views on single-page or headless front ends.

Do not test only the easiest form. Submit each important form with realistic data, including required fields, optional fields, validation errors, spam protection, thank-you states, email notifications, CRM handoff, and analytics events. If the website has booking links, phone links, email links, downloads, newsletter forms, quote requests, or ecommerce actions, test those too.

The test should answer two questions: did the user complete the action, and can the business see what happened? A lead form that sends an email but misses the analytics event is only half working. A form that records an event but never reaches the sales inbox is worse.

• Test desktop and mobile for each priority conversion.
• Submit at least one valid entry and one validation-error entry.
• Confirm the thank-you state, redirect, email alert, CRM record, and analytics event.
• Record the test timestamp so it can be matched inside reports.

A new website often launches near a campaign, product drop, trade show, or paid media push. That makes attribution QA more important. Test UTM parameters, paid landing pages, QR-code URLs, email campaign links, partner links, and redirected campaign URLs before real traffic starts.

Campaign QA is mostly about consistency. Pick a naming pattern for source, medium, campaign, content, and term. Then test whether those values survive redirects, language switching, trailing slash rules, and form submissions. If parameters disappear before the thank-you page or CRM record, the team will not know which campaign created the lead.

• Test one paid link, one email link, one organic social link, and one partner or QR-code link.
• Confirm redirects preserve useful parameters.
• Keep campaign naming lowercase and consistent.
• Document exceptions so future reports are not interpreted as traffic changes.

For redesigns and migrations, analytics QA should sit next to the redirect map. Important URLs, title changes, metadata changes, canonical rules, sitemap output, Search Console verification, and analytics event changes should be reviewed together. Otherwise the team may see a traffic shift after launch and have no clean way to diagnose it.

Save a pre-launch baseline for organic landing pages, top converting pages, branded queries, non-branded queries, indexed pages, crawl errors, and high-value backlinks. Then record what changed. If a service page moved, merged, or changed its event names, the report should make that visible.

• Export top landing pages and top conversion pages before launch.
• Confirm redirects, canonicals, sitemap inclusion, and robots rules.
• Verify Search Console ownership for every relevant domain or subdomain.
• Mark event-name changes so old and new reports can be compared honestly.

Analytics QA should include full journeys, not only isolated clicks. Pick the paths that matter most: homepage to service inquiry, case study to contact form, product page to checkout, blog post to consultation, or localized landing page to quote request. Run each path on mobile and desktop.

Watch what happens in the browser, the analytics debug view, the tag manager preview, and the business inbox or CRM. A journey is approved only when the user experience works and the measurement trail is visible from first page view to final action.

• Test homepage, service page, case study, blog, product page, cart, and contact page where relevant.
• Include at least one mobile test on a real device or realistic device profile.
• Confirm page view, CTA event, conversion event, source data, and business notification.
• Screenshot or record failures with URL, device, expected result, and actual result.