How to Connect a Custom Domain to Vercel, Netlify, and Cloudflare Pages

Overview

If you publish sites regularly, domain setup becomes a repeated operational task rather than a one-time chore. The exact buttons vary by platform, but the underlying process is consistent: add the domain in your hosting platform, update DNS at your registrar or DNS provider, verify that the root and subdomain versions point where you expect, and confirm redirects, HTTPS, and indexing behavior after propagation.

This article focuses on four common scenarios developers revisit often:

• Connecting an apex domain such as example.com
• Connecting a www subdomain such as www.example.com
• Connecting another subdomain such as app.example.com or docs.example.com
• Migrating a domain from one hosting platform to another without leaving stale DNS behind

Before touching any records, define the target state in one sentence. For example: “The production site should resolve at example.com, www.example.com should redirect to it, and preview deployments should stay on platform-generated URLs.” That one sentence prevents a surprising number of DNS mistakes.

It also helps to separate three layers that are often confused:

• Registrar: where you bought the domain
• DNS host: where records such as A, CNAME, TXT, and NS are managed
• Hosting platform: Vercel, Netlify, or Cloudflare Pages, where the deployed site lives

Those layers may be handled by one company or split across several. When a connection fails, the issue is usually at the handoff between them.

If you are still deciding which platform to deploy on, see How to Deploy a Static Website: Netlify vs Vercel vs Cloudflare Pages. If you are deciding whether a section should live on a subdomain or inside a subdirectory, see Subdomain vs Subdirectory for SEO and Deployment: A Practical Decision Guide.

Checklist by scenario

Use this section as the working checklist before every launch or migration. The exact DNS values depend on the platform interface and your DNS setup, but the sequence stays reliable.

Scenario 1: Connect an apex domain to Vercel

If your main site should live at example.com, work through this order:

1. Add the production domain inside your Vercel project settings.
2. Decide whether DNS will remain with your current provider or be delegated elsewhere. Do not mix approaches casually.
3. Create or update the required DNS records for the apex domain exactly as shown in the platform’s instructions.
4. If you also want www, add www.example.com as a separate domain in the same project.
5. Choose the canonical production hostname: apex or www.
6. Set a redirect so only one public version is primary.
7. Wait for DNS propagation, then verify the domain status in the dashboard and in the browser.
8. Test HTTPS after the domain resolves consistently.

Practical note: apex domains cannot always use the same record type as subdomains. Many DNS issues come from copying a www pattern onto the root domain without checking whether your DNS provider supports that method.

Scenario 2: Connect a domain to Netlify

For Netlify, the pattern is similar, but you should be especially careful during migrations because old records often remain active.

1. Add the custom domain to the correct Netlify site, not a staging or test site.
2. Verify which hostname should be primary: example.com or www.example.com.
3. Create the DNS records recommended for your current DNS arrangement.
4. If Netlify DNS is not hosting your zone, confirm that your registrar still points to the intended nameservers.
5. Set the primary domain and redirect behavior inside the site settings.
6. Confirm that branch deploys or deploy previews are not accidentally indexed or linked as production URLs.
7. Test both HTTP and HTTPS requests for apex and www.

If your site was previously hosted elsewhere, compare the old DNS zone with the new one before making changes. A simple text diff can save time here; the process is similar to the config comparison workflow described in Text Diff Checker Guide for Comparing Code, Configs, and Content Changes.

Scenario 3: Set up a Cloudflare Pages custom domain

Cloudflare Pages is straightforward when Cloudflare already manages your DNS zone, but there are still details worth checking.

1. Add the custom domain to the Pages project.
2. Confirm the domain is in the correct Cloudflare account and zone.
3. Create or approve the necessary DNS records for the target hostname.
4. If you use both apex and www, decide which one should be canonical and redirect the other.
5. Review any existing page rules, redirect rules, or proxy-related settings that might affect the hostname.
6. Test the final site over HTTPS and check whether asset URLs, API calls, and redirects work correctly under the custom domain.

Cloudflare setups can fail in ways that look like application bugs. If pages load but scripts, images, or API requests break, inspect absolute URLs, mixed-content issues, and origin assumptions in your app configuration.

Scenario 4: Connect a subdomain such as app.example.com

Subdomains are often simpler than apex domains because they commonly use CNAME-style routing.

1. Add the exact subdomain in your hosting platform settings.
2. Create the DNS record for that hostname only.
3. Check whether the subdomain should be public, password-protected, or excluded from indexing.
4. Update application settings that rely on the public base URL, callback URL, or allowed origin list.
5. Test cookies, auth flows, and cross-origin behavior if the subdomain interacts with the main site.

This matters for apps, docs sites, marketing sites, and internal tools. A technically correct DNS setup can still break sign-in, webhooks, or session handling if the application still expects the old domain.

Scenario 5: Migrate a domain from one platform to another

This is where broken launches happen most often. Use a deliberate cutover checklist:

1. Inventory the existing DNS records before changing anything.
2. Identify which records are for web traffic, email, verification, and third-party services.
3. Add the domain in the new hosting platform first.
4. Prepare the new DNS records without deleting unrelated services such as MX, SPF, DKIM, or verification TXT records.
5. Remove or replace only the records that route the old website.
6. Confirm redirects and HTTPS on the new platform.
7. Check the live site from multiple networks or devices if possible.
8. After the cutover, remove stale records that no longer serve a purpose.

The key point is simple: moving a website should not accidentally move your mail, analytics verification, or other non-web services. DNS zones often contain years of additions, so change only what you can explain.

What to double-check

Once the domain appears connected, do a second pass. Most production mistakes are not in the initial record entry but in the details around the final behavior.

1. Canonical hostname

Decide whether your canonical public URL is apex or www. Then confirm:

• The non-canonical version redirects cleanly in one hop
• The browser lands on the expected final URL
• Your internal links and sitemap use the canonical hostname

If you maintain a sitemap, validate it after the move. See XML Sitemap Validator Checklist for Developers and Site Owners.

2. HTTPS and certificate issuance

Do not stop after the page loads once. Check:

• No certificate warnings on apex or subdomain variants
• No mixed-content warnings in the browser console
• Assets such as fonts, images, and scripts load over HTTPS

3. Redirect behavior

Test plain HTTP, HTTPS, apex, www, and any old hostnames that should now redirect. You want predictable behavior, not partial success.

4. Base URL assumptions inside the app

Many frameworks store public site URLs in environment variables or config files. Review:

• Canonical site URL
• API base URL
• Auth callback URLs
• CORS or allowed origin settings
• Webhook endpoints

This is especially important after moving from a platform-generated preview URL to a real domain.

5. SEO basics after the switch

Domain setup is a deployment task, but it affects crawlability and indexing immediately. Confirm:

• robots.txt is reachable on the live hostname
• Important pages do not accidentally carry noindex
• Canonical tags reference the production hostname
• Sitemap URLs reflect the final domain

If you need a quick review workflow, use Robots.txt Tester Guide: Common Rules, Mistakes, and SEO Checks.

6. DNS conflicts

Watch for overlapping records on the same hostname. A common example is leaving an old A record in place while also trying to use a new target method. If your domain partially resolves or resolves inconsistently, inspect the live DNS records instead of assuming propagation is the only issue.

7. Email records

When editing DNS for a website, do not accidentally remove MX records, SPF TXT records, or DKIM records used for mail delivery. Website launches should not break email.

Common mistakes

These are the mistakes worth checking first when a custom domain setup behaves oddly.

Adding the domain to the wrong project

Many teams have multiple sites with similar names: production, staging, personal fork, old migration target. Before editing DNS, verify the receiving project is the one you actually want public.

Forgetting to add both apex and www

Some developers add only one hostname, then assume the other will work automatically. Treat each hostname as intentional. Add it, route it, and redirect it explicitly.

Changing nameservers unintentionally

If you move DNS hosting, nameserver changes can affect every record in the zone, not just the website. This is a larger operation than editing one A or CNAME record. Plan it separately unless you are certain a full DNS move is appropriate.

Leaving stale verification or routing records

Old records can keep pointing traffic to retired infrastructure or confuse future troubleshooting. After a successful launch, clean up what is no longer needed.

Assuming DNS propagation is the only problem

Propagation does matter, but many failed setups are actually caused by wrong hostnames, duplicate records, app-level redirects, or incorrect environment variables. If the problem persists longer than expected, review the full chain.

Ignoring platform redirects and framework redirects

You may have redirects at the DNS platform, the hosting platform, inside your framework config, and in your application router. Too many layers can create loops or inconsistent behavior between environments.

Forgetting post-launch crawl checks

A site can be “live” and still be wrong for search engines. Check canonicals, sitemap URLs, and robots rules after any domain change. Small mistakes here can linger.

When to revisit

This setup should be revisited whenever the underlying inputs change, not only when something breaks. A short review before launch is faster than emergency debugging after launch.

Revisit your custom domain setup when:

• You launch a new project on Vercel, Netlify, or Cloudflare Pages
• You migrate a site between platforms
• You change registrars, DNS hosts, or nameservers
• You add a www version, subdomain, or regional hostname
• You update auth providers, callback URLs, or CORS rules
• You prepare for a seasonal campaign, product launch, or traffic spike
• You notice indexing changes, SSL errors, or redirect anomalies

A practical pre-launch routine looks like this:

1. Write down the intended public hostname and redirect behavior.
2. Add the domain to the hosting project.
3. Update only the necessary DNS records.
4. Verify apex, www, and HTTP/HTTPS behavior.
5. Check SSL, canonicals, robots, and sitemap URLs.
6. Confirm app config values such as callback URLs and API origins.
7. Remove stale records after the cutover is stable.

If you keep this checklist in your deployment notes, domain setup becomes a repeatable workflow rather than a memory test. That is the real goal: fewer surprises when you connect a custom domain to Vercel, connect a domain to Netlify, or configure a Cloudflare Pages custom domain for the next project.