# Corporate Website Launch Process: Domain, Server, Certificate, Cache, and Verification Checklist

Source: https://www.jvds.cn/en/share/website-design/website-launch-process
Language: en
Published: 2026-09-18
Author: JVDS Design Studio

A corporate website launch should verify the release version, accounts and environments, domains and certificates, caches, business tasks, SEO and analytics, and recovery conditions as one delivery. A working test domain does not mean the production domain's forms, files, and callbacks have passed. A new version appearing in one region does not establish consistency across other entry points.

Before launch, define the scope, window, owners, and decision criteria. If old pages, incorrect content, or intake interruptions occur, save test conditions first, then gather evidence from DNS resolution, the origin, and caches. Avoid everyone changing production settings simultaneously without being able to explain which action worked.

## 1. Freeze the Selected Version and Inventory Assets and Recovery Conditions

After selecting a candidate release, record code and content versions, change scope, and unresolved items. The owner agrees how new materials and necessary fixes are handled during the freeze, rather than imposing one lead time on every project. Appropriate staff confirm important business descriptions, images, contacts, and applicable legal pages.

Inventory account roles, necessary permissions, and renewal arrangements for domains, DNS, servers, CDNs, databases, email, analytics, and third-party services. Logging in, changing configuration, and performing recovery are different capabilities. Check them against actual tasks.

For a redesign, retain inventories of old URLs, important content, and files, and assign relevant new destinations. Recovery plans should distinguish code, configuration, content, attachments, and records created during launch. A backup file does not establish verified usability. For basic preparation, consult [corporate website backup and recovery drills](https://www.jvds.cn/en/share/website-design/enterprise-website-backup).

**Completion check:**Each release item, owner, and recovery subject is clear. Blocking issues are not treated as ordinary post-launch tasks.

## 2. Rehearse Key Functions in the Production Environment

Have technical staff check the production runtime, database, configuration, file permissions, time zone, and upload conditions. Controlled preview methods can verify builds, editing, attachments, interfaces, and email, but the actual system determines the method. Manage test and production secrets and access scopes separately. Do not put production secrets in public materials or code.

Rehearsal involves more than the homepage. Backend content saves, readable images and downloads, recorded contact paths, and third-party callbacks under production conditions provide the basis for proceeding with the switch. Record configuration differences between environments. Identical program packages do not establish identical behavior.

For the relationship between server choices and target markets, see [comparing tasks for domestic and overseas servers](https://www.jvds.cn/en/share/website-design/domestic-vs-overseas-server). Regional access and information intake still require verification under actual project conditions. A server name cannot guarantee global speed.

## 3. Switch DNS and Certificates and Record Results Across Entry Points

Before changes, save current DNS records and target configuration. Confirm how the root domain, www, and other variants in use reach the canonical address. TTL affects cache duration; check adjustments and actual effectiveness in the DNS system rather than promising a fixed wait. If different address records coexist, check whether any still point to the old environment.

Certificates should cover required domains, with clear renewal, HTTP-to-HTTPS, and variant redirects. After switching, use actual devices and different networks to check certificate chains, mixed content on HTTPS pages, and redirect chains or loops. A homepage padlock alone is insufficient. Old-page destinations should correspond to relevant content, while nonexistent pages return accurate results. Manage controlled test domains according to access and indexing plans. Production switching involves more than removing a page notice.

If one region shows an old page, first record the complete URL, time, language, network, browser, and identifying features of the old content. Technical staff then check the DNS destination at that time, the host receiving the request, and the origin version. Opening an IP directly may not use the same domain or routing, so operations staff should not infer origin content from it.

**Completion check:**Required entry points, certificates, and canonical destinations match the confirmed plan. Regional differences have verifiable conditions, rather than only a screenshot labeled “broken on mobile.”

![Artwork](https://www.jvds.cn/upload/2026/0824/1787562378685-843703.webp)

Concept illustration of allowing propagation time at each domain, DNS, and SSL step

## 4. Investigate Browser, CDN, and Origin Caches Separately

First confirm whether the origin actually outputs the selected version, then compare the pages and resources users receive. If the origin is still old, refreshing the CDN may merely retrieve old content again. If the origin is correct but an entry point is outdated, check browser, edge, or application caches and their rules.

Cloudflare's CDN troubleshooting guidance notes that stale content may relate to TTL, and query parameters and cache rules also affect cached copies. Technical staff should check cached objects and rules on the actual platform, especially whether language, parameters, or user states need separate treatment. Content in another language must not become a shared copy by mistake.

When clearing caches, record the objects, execution time, and results, then retest the original URL under the original conditions. Page HTML, images, and stylesheets may update differently. Do not inspect only above-the-fold text. Load images, fonts, and downloads and check their versions. For resources read across origins, check permissions and CORS policies according to actual loading methods. Static assets may use version identifiers under the plan, while HTML and dynamic business tasks need separately confirmed caching arrangements.

A new private window may reduce some browser-state effects, but does not independently rule out DNS or CDN issues. Repeat the same customer task in key regions and networks under recorded conditions. Technical staff can compare actual responses where needed. Do not keep changing entry points merely to find the new version.

For multilingual relationships and conditions, see [routing, content, and cache checks in multilingual development](https://www.jvds.cn/en/share/website-design/multilingual-website-development-i18n).

**Completion check:**Evidence identifies the layer responsible for old content, and the same task uses the correct version after changes. A refresh acknowledgment is not treated as proof that every node and browser updated.

## 5. Follow Actual Business Tasks and Check SEO and Analytics

Use prepared test information to submit forms. Check messages, backend records, actual notification receipt, and the receiving role separately. If the project includes login, payments, maps, text messages, or other interfaces, check production conditions and failure handling individually. Features not used need not be tested merely to complete the checklist.

SEO checks cover status codes, titles and descriptions, canonical tags, robots directives, applicable structured data, sharing resources, and language relationships. Sitemaps should use confirmed canonical URLs. Give Search Console and analytics permissions to agreed roles. Google's sitemap guidance makes clear that sitemaps help discover URLs but do not guarantee all pages are crawled or indexed. A crawl request is not an acknowledgment of immediate indexing. Check markup against visible page facts rather than copying test content.

Test analytics events against agreed actions and avoid duplicate sends from code in multiple places. Page views, button clicks, and business receipt are different evidence. One event cannot prove an inquiry is complete. Retain existing analytics assets and observation definitions according to the project so later comparisons have a clear scope.

![Testing](https://www.jvds.cn/upload/2026/0824/1787562379698-106486.webp)

Concept illustration of testing forms, email, and third-party interfaces through actual workflows

## 6. Continue Observing After Release and Define Recovery Decisions

Immediately after switching, prioritize access, certificates, core tasks, and error records. Then observe actual receipt, regional versions, caches, crawling, and search changes within business windows. Timing depends on site scale and risk. Do not announce that every system has finished processing after a fixed half hour or day.

If key tasks fail, an authorized owner decides under predefined conditions whether to keep fixing, suspend, or recover. Page rollback and database recovery have different scopes. Before acting, confirm how new inquiries, attachments, and processing statuses are retained. Restoring pages should not overwrite new business information.

Record selected versions, anomalies, actions, recovery results, and remaining matters, then retest actual historical entry points and key regions. Unpassed scope should retain an owner. Site-wide totals must not conceal problems with one product, language, or region.

**Completion check:**Business paths within the selected release scope work, configuration and content agree, anomalies and recovery are traceable, and subsequent maintainers know what remains to observe.

![Artwork](https://www.jvds.cn/upload/2026/0824/1787562381017-424308.webp)

Concept illustration of continued post-release observation within actual business windows

## Frequently Asked Questions

### How long must we wait after DNS changes to confirm launch?

Verify according to records, TTL, caches, and actual entry points, without one universal deadline. Business tasks and recovery scope still need checking.

### If CDN clearing succeeds, will customers definitely see the new version?

Check the origin, other caches, and the same access conditions as well. A clearing result does not establish that every user updated.

### When can the old environment be shut down?

First confirm DNS resolution, old entry points, data, and the recovery window. Business and technical owners jointly decide specific conditions.