A custom domain launch is complete when visitors can reach the right website at the address you chose. A successful upload, a saved DNS record, or a provider dashboard showing “ready” is only one part of that result. Use this checklist to connect the address, protect existing services, and test the public website.
Start with the finished website files and run the local static-site preflight checker. It can catch a missing root index.html and some broken HTML asset references. Domain routing, certificates, forms, and public availability still need separate checks.
Choose the address visitors should use
Write down the final hostname, including whether it uses www. Record the current homepage and any important existing paths before changing anything. If the domain already serves another product, decide whether the new site belongs on a subdomain before touching the main address.
A small launch record might read: “The new marketing site will use www.example.com. The existing app stays on app.example.com. Email continues through the current mail provider.” These are illustrative addresses. Replace them with the actual hostnames and verify ownership of each one.
Choose a single preferred address for the public site. If both the apex and www are available, the alternate should lead visitors to the preferred address through a tested redirect. Avoid making two independently editable copies of the same website.
Capture the complete DNS state first
Save a fresh record of the whole DNS zone. Identify the records that the hosting provider actually asks you to change. Preserve mail routing, verification records, and services attached to other subdomains.
Do not replace a complete zone with a short list of website records. An apparently unrelated TXT record might support an existing service, and an MX record controls mail delivery. A website launch should not silently become an email migration.
Before saving changes, compare the intended before and after states. The reviewed change should name the exact record, hostname, value, and purpose. If the live zone changed while you prepared the plan, review the current state again.
Connect the domain through the current hosting workflow
Use the domain controls of the actual project that holds the website. Verify the project name and deployment address first; a similar project name is not enough. Follow that provider's current instructions for the requested DNS records rather than copying a configuration from a different host.
Keep the provider's working deployment address available during the change. It gives you a way to distinguish a website problem from a domain-routing problem. A pending domain or certificate state should remain pending in your launch record until the public address works.
Test HTTPS, redirects, and the page itself
Open the preferred address as a visitor. Check that the browser reaches the intended site over HTTPS without a certificate warning. Test the alternate hostname, the homepage, and at least one nested page. A redirect should preserve the intended destination rather than send every page to the homepage.
Then check the actual content:
- The title and main heading describe the right product.
- Images, styles, fonts, and navigation load from public addresses.
- A direct visit to a nested page works without starting at the homepage.
- A missing page returns a useful error instead of pretending to be a valid article.
- Contact forms and other important actions work using non-sensitive test inputs.
Use the broken-image troubleshooting guide if the homepage works but its assets do not. Use the contact-form guide to verify the complete submission flow.
Check search and sharing at the final address
Give each public page a canonical address, a descriptive title, and a relevant share image. Include the preferred public URLs in the sitemap and check that production pages are not accidentally marked noindex. Preview deployments can remain excluded from indexing.
A sitemap submission helps discovery; it does not prove that a page is indexed or ranked. Keep those states separate when reporting the launch. If the content moved from an older address, retain a reviewed redirect plan for important existing links.
Close the launch with an evidence record
Record the final hostname, deployment, pages tested, form result, and any unresolved issue. Include a screenshot of the public homepage and a way to recover the previous website configuration if needed. Hand over the domain and hosting responsibilities using the client website handoff checklist.
When the public checks pass, return to GeminiLaunch to continue publishing and maintaining the website. Repeat the public checks after later releases; a domain that worked on launch day can still point at a changed deployment.
Sources
- Google Search Central: consolidate duplicate URLs
- Google Search Central: build and submit a sitemap
- MDN: an overview of HTTP
Prepared with AI assistance using the current public product and linked references. Practical checklists and illustrative examples are original planning aids. They do not establish product guarantees or replace a situation-specific review.