Corporate Website Launch Process and Checklist

Many website incidents happen in the final mile: everything works in development, but forms stop arriving on the production domain, images trigger cross-origin errors, old links return 404, analytics loads twice, or HTTPS redirects loop. These issues seem unrelated, but usually share one cause: launch was not managed as a separate project.

A mature launch process defines a window, owners, validation items, and rollback conditions. Freeze the release before deployment, verify it against a checklist afterward, and restore service quickly when a blocker appears instead of letting everyone improvise in production.

01 One Week Before Launch: Freeze Scope and Inventory Assets

After selecting the release candidate, allow only blocker fixes—no last-minute pages or motion. List owners for domain, server, CDN, database, email, forms, analytics, and third-party accounts, and confirm renewals and two-factor authentication.

When replacing an old site, crawl old URLs, titles, status codes, and high-traffic pages and prepare 301 mappings. Switching without a migration table commonly breaks every old link.

02 Server and Environment: Rehearse in Production Conditions

Runtime, database, cache, file permissions, and environment variables may differ from test. Preview through a temporary domain or Hosts entry and validate builds, APIs, uploads, email, and scheduled tasks.

Production secrets should not enter the code repository. Configure least privilege, log rotation, backups, and monitoring, and verify server time zone, character encoding, and upload limits.

03 Domain, DNS, and SSL: Allow Time for Propagation

Record current DNS before switching, lower TTL in advance where appropriate, and choose either the root domain or www as canonical. SSL certificates must cover required domains and renew automatically; permanently redirect HTTP to HTTPS so multiple versions are not accessible.

Test from different networks and devices after the change, checking certificate chains, mixed content, and redirects. Company-network testing alone can hide problems behind local DNS caches.

04 Cache and CDN: Fast but Still Updatable

Static assets can use long caching with fingerprinted filenames; HTML and APIs need more care. If users see old pages after launch, identify browser, CDN, server, or application cache rather than repeatedly redeploying.

Validate image, font, download, and cross-origin policies in the CDN, and ensure cache-purge access belongs to the client account. Do not cache forms, login, or personalized content incorrectly.

05 Test Forms, Email, and Third-Party APIs End to End

Development success does not guarantee production callbacks. Submit forms with real email addresses and phones and verify front-end confirmation, back-office records, notifications, CRM, spam controls, and privacy consent.

Update production callback domains, allowlists, and keys for payments, maps, login, SMS, video, chat, and other services. Record owners and failure fallbacks for every critical integration.

06 SEO and Analytics: Baseline Work Required on Launch Day

Review title, description, canonical, robots, and status codes for every indexable page. Generate a sitemap containing only canonical URLs and verify the property in Search Console. Google notes that sitemap submission and crawl requests support discovery but do not guarantee immediate indexing.

Avoid duplicate analytics loading and validate page views, form submissions, phone or WeChat clicks, and other key events on the live domain. For redesigns, retain existing analytics properties to compare before and after.

□ robots.txt does not accidentally block production pages;

□ Test and preview pages do not enter the index;

□ Canonical and sitemap use the same canonical domain;

□ Old-URL redirects create no chains or loops;

□ 404 and 500 pages return correct status codes;

□ Structured data, social images, and favicon load correctly;

□ The client owns access to Search Console and analytics.

07 What to Check at 30 Minutes, 24 Hours, and 7 Days

Launch does not end at publish. During the first 30 minutes, monitor access, core functions, and error logs. At 24 hours, review real traffic, forms, email, crawling, and performance. After a week, check indexing, 404s, redirects, search performance, and user feedback.

08 Define Rollback Conditions Before an Incident

Roll back immediately if core pages become inaccessible, transactions fail, data is abnormal, or a security risk appears. Local styling and low-frequency content issues can be fixed in the new release. Define thresholds and decision authority before launch rather than debating during an incident.

Rollback can involve database, cache, and DNS as well as code. Rehearse at least once in a test environment and prove that backups restore successfully.

Frequently Asked Questions

Does launching a new website require downtime?

A new site usually does not. Redesigns can reduce interruption through predeployment, short switching windows, and cache strategy. Complex systems should plan maintenance windows.

How long does DNS propagation take?

It varies by record, TTL, ISP cache, and region—from minutes to much longer. Prepare in advance and retain the old environment during the switch.

Should we submit the website to Google immediately after launch?

Submit the sitemap and use URL Inspection to request crawling for a few important URLs, but Google's systems still determine crawling and indexing.

Can every old page redirect to the home page?

Avoid it. Redirect old URLs to the most relevant new page; when no equivalent exists, a 404 or 410 is usually clearer than sending everything home.

When can the old server be removed?

Wait until DNS is stable, redirects and data are validated, and a sufficient rollback window has passed. Timing depends on business risk and migration complexity.