Website Launch Checklist: SEO, Analytics, Forms, and QA

A website launch is a controlled transfer of risk. The code moves to production, but so do the forms, tracking, URLs, content, permissions, and customer journeys that the business will depend on. A launch can look successful in a browser while leads disappear, analytics double-count, old rankings land on 404 pages, or private staging rules block the new site from search.

The answer is not an enormous checklist completed by one exhausted developer. It is a short ownership plan supported by specific checks, evidence, and a rollback path. Marketing, operations, design, development, and whoever receives enquiries all have a role.

This checklist is designed for business websites and supports Scallar's website development and launch work. Adapt it to your stack and risk. Payments, healthcare, finance, authentication, and regulated data need additional specialist review.

First: Decide Whether the Website Is Ready to Launch

Hold a go/no-go review before changing DNS or production routing. List open issues as blockers, accepted risks, and post-launch improvements. A spelling correction may wait. A broken lead form, missing redirect map, insecure administrator account, or unknown backup state should not.

Name these owners:

• Launch lead who makes the final go/no-go decision
• Technical owner for deployment, DNS, hosting, and rollback
• Content owner for facts, links, and approvals
• SEO owner for URLs, redirects, indexation, and monitoring
• Analytics owner for events, consent, and reporting
• Enquiry owner who confirms leads reach the right team
• Business contact who can approve urgent changes

Share the launch window and escalation path. Avoid launching just before a holiday or when the people who can fix issues are unavailable.

Content and Brand QA

Review every priority page with real content. Check company name, address, phone, email, service descriptions, author details, dates, policies, qualifications, and claims. Verify that testimonials, client logos, ratings, statistics, and case results are genuine and approved. Remove placeholders and demo content.

Check headings for one clear H1, logical H2/H3 structure, and no text clipped on mobile. Links should describe their destination. Buttons need consistent labels and useful focus states. Downloadable files should open and show current branding.

Review social sharing images and favicons. Test the site title in a browser tab, a mobile home screen, and common link previews. Confirm that image licences and fonts permit the planned use.

URL and Redirect Checklist

For a new website replacing an old one, URL control is one of the highest-risk tasks. Export all known old URLs from the sitemap, analytics, Search Console, crawl data, backlinks, and server records. Map each valuable old URL to the closest relevant new destination. Do not redirect everything to the homepage.

Test redirects for one hop, correct status, and final destination. Update internal links to point directly to final URLs so users and crawlers do not repeatedly pass through redirects. Preserve useful query parameters only where needed.

Check trailing slash, uppercase, www, HTTP, and hostname behaviour. There should be one preferred canonical version. Ensure non-production hosts cannot be indexed.

For a detailed replacement workflow, use the website migration and redirect checklist.

On-Page SEO Checks

Every indexable page should have a distinct, accurate title and meta description appropriate to its intent. Confirm one canonical URL, crawlable main content, useful headings, indexable status, and relevant internal links. Images need descriptive alternatives when they carry information and empty alternatives when they are decorative.

Validate structured data against visible content. Breadcrumb, Organization, LocalBusiness, Article, FAQ, Product, and Service schema are useful only where the page genuinely supports them. Do not add ratings, reviews, pricing, or claims that the business cannot substantiate.

Generate the production XML sitemap from canonical indexable URLs. Exclude staging, API, search, and intentionally non-indexable routes. Reference the sitemap from robots.txt and submit it in Search Console after launch.

Check hreflang only if the site has genuine regional or language alternatives. Incorrect hreflang is worse than none. Ensure pagination and filtered pages follow a deliberate index strategy.

Robots, Canonicals, and Status Codes

One of the most damaging launch mistakes is carrying a staging noindex rule into production. Inspect rendered HTML and response headers, not only source configuration. Confirm that important pages return 200, removed pages return a real 404 or 410 where appropriate, and redirects use 301 or 308 for permanent moves.

Canonical tags should point to the intended public URL, not staging, localhost, another region, or a generic parent. Self-referencing canonicals are normal for unique pages. Do not canonicalise genuinely distinct service-city pages to the service hub simply to avoid reviewing their quality.

Test robots.txt as a public visitor. It should not block assets needed for rendering. If AI crawler rules are included, make them a deliberate policy rather than copying a generic file.

Forms and Lead Delivery

Test every form from beginning to end. Use valid and invalid data, mobile and desktop, common email providers, slow connections, and repeated submissions. Confirm required fields, inline errors, consent wording, server-side validation, spam controls, success state, and what happens if the email or CRM provider fails.

The submitter acknowledgement and the agency notification are separate flows; verify both. Confirm the reply-to address uses the submitter's email without spoofing the sender domain. Check spam folders and mail authentication. Store enough server-side evidence to investigate delivery without logging unnecessary personal data.

Verify phone, mailto, WhatsApp, booking, and map links. Make sure country codes and pre-filled messages are correct. Test the route after a browser refresh and back navigation so a success page does not accidentally resubmit.

If forms connect several systems, document the API integration, source of truth, retry behaviour, and owner of failed leads.

Analytics and Conversion Measurement

Decide what the business needs to know. Page views alone are not a measurement plan. Define events for form success, booking completion, phone click, WhatsApp click, email click, important download, account creation, purchase, or other genuine conversions.

Test events in production or a production-like environment. Confirm each action fires once, carries useful non-sensitive parameters, and appears in the correct analytics property. Exclude internal or developer traffic where practical. Check cross-domain tracking for third-party booking or payment flows.

Verify consent behaviour for the markets served. Tags that require consent should not run before the choice. The privacy policy should accurately describe the deployed tools, not a copied list.

Annotate the launch date and preserve old reporting. A changed URL or event name can make performance look different even when customer behaviour is unchanged.

Search Console and Webmaster Tools

Verify domain ownership before launch day. Submit the sitemap, inspect the homepage and several key templates, and monitor indexing and enhancement reports. Keep access under company-controlled accounts with more than one responsible user.

Do not request indexing for thousands of pages manually. A clean sitemap, internal links, correct status codes, and server-rendered content are the scalable path. Manual inspection is useful for a small set of priority pages and diagnosing exceptions.

Performance and Core Web Vitals

Test representative templates on mobile, not only the homepage. Check the likely Largest Contentful Paint element, image dimensions, font loading, JavaScript execution, layout shift, and interaction delay. Compress images, use responsive sizes, and remove scripts that have no owner or business value.

Third-party tools often change performance after launch. Include analytics, consent, chat, maps, embeds, and marketing tags in the test. Confirm caching and compression headers in production. A CDN does not automatically fix a heavy page.

Set a baseline and monitor real-user data over time. Laboratory tests are useful for diagnosis; field data shows what customers experience.

Accessibility and Usability

Navigate the site using a keyboard. Focus should be visible and follow a logical order. Menus, dialogs, accordions, carousels, forms, and cookie controls must work without a mouse. Check headings, landmarks, labels, error messages, text contrast, zoom, and reduced-motion behaviour.

Test on narrow screens with large text. Content should not overlap, disappear, or require horizontal scrolling. Do not encode essential instructions in colour alone. Captions or transcripts may be needed for meaningful media.

Automated tools catch only part of the problem. The website accessibility guide for Indian businesses provides a practical manual review sequence.

Security and Privacy Checks

Confirm HTTPS, secure cookies, environment separation, secret storage, administrator roles, multi-factor authentication, dependency updates, spam protection, backups, and restore instructions. Remove test accounts and sample API keys. Restrict dashboards and preview environments.

Check security headers and content security policy where applicable. Avoid exposing stack traces or personal data in client errors. Rate-limit sensitive endpoints and validate uploads. Review third-party scripts and permissions.

Security is not complete at launch. Use the small-business website security checklist to assign recurring maintenance.

Infrastructure, DNS, and Deployment

Document current DNS records and lower TTL in advance when a change is planned. Confirm certificate issuance, environment variables, database migrations, storage permissions, cache invalidation, and background jobs. Back up data and verify that a restore is possible.

Use a repeatable deployment process with logs. Blue-green or staged deployment can reduce downtime, but the inactive environment must use a free port and the reverse proxy must point to the healthy target. Health checks should test a meaningful application endpoint, not only whether a container exists.

Prepare rollback criteria. If forms, authentication, checkout, or key pages fail, the team should know who can reverse the release and how much data would be affected.

Browser and Device Coverage

Test supported browsers and common screen sizes. Include at least one real Android phone and iPhone when the audience uses them. Check navigation, forms, sticky controls, tables, videos, downloads, hover-only information, and orientation changes.

Do not try to make every old browser identical. Define supported behaviour and ensure unsupported features fail gracefully. The goal is access to information and tasks, not pixel-perfect sameness.

Email, Domain, and Reputation Checks

Forms and transactional emails need a properly authenticated sending domain. Confirm SPF, DKIM, and DMARC alignment with the chosen provider. Use a real sender identity and a monitored reply path. Avoid hard-coding a personal account that may leave the company.

Check that domain renewal, DNS, mail provider, hosting, analytics, and Search Console are held in company-controlled accounts. Record recovery methods and responsible people.

Launch-Day Sequence

1. Freeze non-essential content changes.
2. Take backups and record the current production state.
3. Confirm owners and communication channel.
4. Deploy the application and required migrations.
5. Apply DNS or proxy changes.
6. Run automated health checks.
7. Test the homepage, priority pages, and conversion journeys.
8. Verify redirects, robots, canonicals, sitemap, analytics, and forms.
9. Notify internal teams only after core checks pass.
10. Begin monitoring logs, leads, traffic, and uptime.

Keep a timestamped record of issues and decisions. This prevents several people from making conflicting emergency changes.

The First 24 Hours

Monitor server errors, 404s, redirects, form submissions, email delivery, analytics events, Search Console inspection, payment or booking completion, and customer reports. Crawl a representative set of URLs from outside the development environment.

Check whether sales received real leads and whether the source data is useful. A green API response is not enough if notifications go to the wrong mailbox.

Avoid making broad SEO changes in reaction to a few hours of data. Fix proven technical errors immediately; observe ranking and indexing trends over a more meaningful period.

The First Week and First Month

During the first week, review coverage, performance, broken links, popular journeys, conversion events, and content questions from the team. Resolve launch defects separately from enhancement ideas.

During the first month, compare organic landing pages, enquiries, engagement, and speed with the pre-launch baseline. Check whether editors can publish safely. Schedule dependency updates, backup tests, content review, and a conversion improvement backlog.

The website is ready for iterative work when the operational foundation is stable. That is the point at which tests, content expansion, and campaign landing pages create reliable learning.