Using a custom domain with an Emergent project

Choose a primary address

Decide whether the primary address will include www. The other version should normally redirect to it, and the page’s canonical URL and sitemap should use the same primary form. This keeps shared links and search signals consistent. Make the decision before distributing printed material or sending launch messages.

Read the project-specific instructions

Emergent documents custom-domain support, but the connection details must come from the deployment you are configuring. Find the domain settings for the correct project and record the requested record type, host, and value. Do not assume another hosting provider’s IP address or CNAME target will work. Confirm the applicable plan and deployment requirements first.

Preserve unrelated DNS records

A domain can also handle email and verification for other services. Record the current configuration before editing it. Change only the records needed for the website connection. In particular, do not delete mail-routing or email-authentication records just because they are not mentioned in the website setup instructions.

Check the whole connection

After applying changes, use the platform’s verification status and then visit the primary address in a browser. Check HTTPS without bypassing certificate warnings. Test both root and www versions, one internal page, and a nonexistent page. DNS caching can mean that results differ temporarily between networks.

Finish the launch details

Update canonical URLs, sitemap entries, and social metadata to the primary domain. Check forms and service callbacks that may have been configured against a preview address. Keep access to the registrar and DNS account documented for the person who will maintain the site.

Understand the three pieces of a domain connection

The registrar manages the domain registration, the DNS provider answers where the domain points, and the hosting platform serves the website. These may be the same company or three different services. Knowing which account controls each piece prevents changing an unrelated setting when a connection fails.

A domain can serve a website and email at the same time. Website records should not be changed by deleting everything in the DNS zone. Record the existing setup first, especially mail-routing and email-authentication records. If someone else manages the domain, obtain the required change through that person rather than creating a competing configuration.

Choose the primary hostname

Decide whether the main address will be example.com or www.example.com. The alternative should normally redirect to the primary address. Use the same choice in canonical URLs, the sitemap, navigation, and social metadata. This is a consistency decision; the presence of www is not a substitute for useful content or a guarantee of rankings.

For a project under a subdomain, identify the exact name: app.example.com is different from example.com. A root-domain change can affect an existing business website, while a subdomain may allow the new application to launch separately. Confirm the intended scope before editing records.

Get records from the actual deployment

Emergent’s deployment tutorial describes adding a custom domain through deployment settings and then configuring DNS. Its examples contain specific addresses and reflect an older interface. Use the record values shown for your current project, not the numerical values from a tutorial or another person’s account. Source details.

Copy the type, host, and value exactly. A DNS provider may ask for only the subdomain label while another displays the full hostname. Check the preview of the resulting name before saving. Accidentally creating app.example.com.example.com is a common kind of entry mistake.

The placeholders above are not working DNS values. They explain the fields. Keep the actual values in the hosting interface as the source of truth and avoid publishing private verification details unnecessarily.

Make a small, reversible change

Save a record of the existing configuration and identify exactly which records conflict with the requested website connection. Replace or remove only the relevant conflicting records according to the provider’s instructions. Preserve unrelated email and verification entries. If a proxy or CDN is involved, follow the platform’s current guidance rather than assuming every proxy setting works.

After saving, return to the hosting platform and request verification if that control is available. DNS changes can appear at different times across resolvers because of caching. Repeatedly changing values during propagation can make troubleshooting harder. First check that the values are correct, then allow the expected verification process to complete.

Verify more than the homepage

Open the primary hostname over HTTPS, the alternate hostname, a real internal page, and a nonexistent page. Check that redirects preserve useful paths where appropriate. A request to www.example.com/services should not unexpectedly send every visitor to the homepage if the intended page exists on the primary host.

Inspect forms, login callbacks, and integrations that may still reference the preview address. A website can render correctly while authentication fails because the new domain is not in the permitted callback configuration. Update the relevant service settings and test the whole journey on the final address.

Troubleshoot by layer

Do not bypass a certificate warning and call the domain finished. Resolve the configuration or wait for the platform’s certificate process as appropriate. If the required settings appear correct but verification does not complete, collect the hostname, current public records, and platform status for support. Never send passwords or secret keys as part of a routine support description.

Update discovery and measurement

Set the canonical address consistently on public pages and regenerate the sitemap using the primary host. Verify ownership in Search Console through its supported process and submit the sitemap. Keep analytics configured for the production journey so preview testing does not become confused with real acquisition data.

Check old links if the domain replaces an existing site. Important previous URLs may need redirects to the corresponding new content. Redirecting every missing page to the homepage can confuse readers and obscure genuine errors. Maintain a small mapping for valuable pages that moved.

Document ownership and renewal

Record which business account owns the domain, who can edit DNS, and when registration renews. Keep access with the organisation rather than only with a temporary contractor. Note which services depend on the domain, including email, so future changes are reviewed in context.

A successful launch is not only a green verification badge. It is a working address, valid HTTPS, correct routing, functioning integrations, and a clear maintenance owner. Recheck those parts after moving hosting or changing domain providers, even when the initial connection was straightforward.

Before calling the domain ready

• The project reports the domain as verified.
• HTTPS loads without warnings.
• The alternate hostname redirects as intended.
• Email still works after DNS changes.
• Internal pages and forms work on the new address.