Custom domains make Build Me Web sites feel like your brand, not a temporary subdomain. This guide covers adding a hostname, publishing DNS records, enabling HTTPS, configuring redirects, and fixing the issues that most often block certificate issuance.
You will need access to your DNS provider (registrar or DNS host) and permission to edit Domains in the Build Me Web workspace. If marketing owns the brand domain but IT owns DNS, loop both parties in before a cutover window.
Add a domain
Go to Sites Domains Add domain. Enter the hostname visitors should type — apex (example.com), www, or a subdomain such as app.example.com. You can add multiple hostnames and designate one as canonical.
After you add a domain, the panel shows verification status, required DNS records, and certificate state. Leave this tab open while you edit DNS so you can refresh status without hunting through settings.
- Add the hostname exactly as customers will see it (punycode for IDN domains).
- Choose whether this host is primary for the site.
- Copy the DNS instructions for your provider.
- Optionally add a redirect-only host (for example, apex redirecting to www).
Add both apex and www even if one only redirects. It prevents competitors or typosquat confusion and keeps certificate coverage ready.
DNS records
Build Me Web tells you which records to create. Typical patterns:
- A / ALIAS / ANAME for apex domains pointing at our edge targets.
- CNAME for
wwwand other subdomains. - TXT for ownership verification when required.
Remove or update conflicting records that still point at a previous host. Split-brain DNS — half your users hitting the old IP — looks like “SSL is flaky” when it is really routing.
TTL guidance: lower TTLs (300 seconds) a day before migration; raise them after cutover is stable. If you use DNS proxy features, follow the panel’s proxied vs DNS-only recommendation so HTTP-01 or equivalent challenges can complete.
# Example shapes — use values from your Domains panel
example.com ALIAS
www.example.com CNAME
_bmw.example.com TXT SSL & redirects
Certificates issue and renew automatically after DNS verifies. Force HTTPS only after the first successful issuance. Enabling HTTPS-only too early can strand browsers if DNS still points elsewhere.
Configure apex ↔ www redirects so search engines and analytics see one canonical host. Pick a policy and apply it everywhere: marketing sites, app links, and email templates.
- HTTP to HTTPS redirect after certificates are active.
- Non-canonical host to canonical host with a 301 for permanent moves.
- Path-preserving redirects unless you intentionally collapse URLs.
HSTS can be enabled once you are confident the HTTPS setup is durable. Start with a modest max-age before jumping to multi-month values.
Troubleshooting
SSL stays pending: confirm DNS has no conflicting AAAA records pointing at unused IPv6 hosts, that CNAMEs are not flattened incorrectly, and that the hostname is not proxied in a way that breaks challenges. Propagation can take up to forty-eight hours, though most changes settle within an hour.
Certificate issued but browser warns: check that users hit the hostname on the certificate (www vs apex), clear intermediate cache, and confirm you are not serving an old host via stale DNS.
Redirect loops: ensure only one layer forces HTTPS and canonical host — duplicate rules at the DNS proxy and application layer often fight.
Email link mismatch: update transactional templates to the canonical HTTPS host so users are not sent to expired subdomains.
- DNS records match the Domains panel exactly
- Old host records removed or TTLs expired
- Canonical redirect verified with curl -I
- Search Console property covers the canonical host
Still stuck? Export the DNS screenshot and certificate status for support — that pair resolves most escalations without a screen share.
Prerequisites & preparation
Before changing production settings for custom domains, align the people who own content, DNS, analytics, and approvals. A fifteen-minute kickoff that names owners prevents multi-day Slack archaeology later. Capture decisions in the workspace notes so the next teammate inherits context instead of guesswork.
Gather credentials and access: workspace admin or editor role, DNS control when hostnames are involved, payment or API sandbox accounts when money paths are involved, and a shared checklist link. Confirm which environment you will rehearse in — preview first, production only after a green run.
Confirm DNS access, pick canonical host (apex vs www), and schedule a cutover window after lowering TTLs.
Detailed walkthrough
Work the happy path slowly the first time. Narrate what you expect to see after each click: a status badge, a DNS record, a webhook delivery, a Lighthouse metric. When reality diverges, stop and resolve the mismatch instead of clicking ahead — most outages begin as ignored yellow states.
- Add apex and www in Domains; designate the canonical host.
- Apply DNS records exactly as shown; remove conflicting legacy records.
- Wait for verification and certificate issuance before HTTPS-only.
- Configure redirects and verify with response header checks.
- Update email templates and ads to the canonical HTTPS URLs.
Edge cases & failure modes
Plan for partial failure. Networks drop, registrars delay, providers rate-limit, and humans approve the wrong revision. Your runbook should say what “abort” looks like: leave preview up, roll back the release, or freeze campaigns until metrics recover.
- Stale DNS TTLs sending a fraction of users to the old host.
- AAAA records pointing at unused IPv6 targets breaking intermittent clients.
- Proxy modes interfering with certificate HTTP challenges.
QA checklist before you announce
- Happy path verified on mobile and desktop
- Failure path messaging reviewed
- Owners named for the first hour after launch
- Rollback or freeze path documented
Operating the change
After launch, watch the metrics that prove the change worked — not vanity charts. Pair quantitative signals with one qualitative check (support ticket themes, sales feedback). Schedule a follow-up within a week to remove temporary flags, raise DNS TTLs, or archive the experiment.
Raise TTLs after stability; calendar certificate and DNS access reviews yearly.
Treat custom domains as a repeatable playbook. The second time your team runs it should be faster because the checklist and owners already exist.
Canonical host discipline affects SEO, analytics, and cookies. Pick once and enforce everywhere including emails.
HSTS should start with modest max-age until you trust the HTTPS setup under real traffic.
Document proxied vs DNS-only guidance for your DNS vendor so certificates can complete challenges.
When migrating from another host, keep the old host available until TTLs expire for all major resolvers.
Export DNS screenshots plus certificate status when escalating — it halves support time.
Subdomains for apps and marketing should follow the same TLS and redirect standards as the apex brand domain.