Custom Domains And HTTPS

A generated Vercel URL is enough for learning, previews, and quick review. A production website usually needs a real domain such as example.com or www.example.com. A custom domain makes the site easier to trust, easier to share, and easier to keep stable even when the underlying deployment platform changes.

Domains are also where deployment begins to touch ownership and operations. The person who controls DNS can decide where traffic goes. The person who controls the Vercel project can decide which deployment the domain serves. The person who controls billing can decide whether the project keeps running. For a personal course project, one person may own all of that. For client or business work, those responsibilities should be explicit.

This lesson teaches the domain model Vercel expects: add the domain to a project, configure DNS at the registrar or DNS provider, verify that traffic reaches Vercel, and rely on Vercel-managed HTTPS once the domain is configured correctly. The exact dashboard screens and registrar panels can change, so focus on the concepts.

Domain Names, DNS, And Vercel Projects

A domain name is a human-readable name that points users toward a service. DNS is the system that answers questions such as "where should example.com go?" Vercel is the platform serving your deployment. Connecting a custom domain means making DNS and Vercel agree.

The Vercel side says:

This project is allowed to serve example.com.
This project should serve www.example.com.
This domain is verified and configured.

The DNS side says:

Requests for example.com should go to the address Vercel recommends.
Requests for www.example.com should go to the hostname Vercel recommends.

Both sides matter. If the domain is added in Vercel but DNS still points somewhere else, users will not reach the Vercel deployment. If DNS points to Vercel but the domain is not configured in the project, Vercel may not know which project should answer.

Apex Domains And Subdomains

The apex domain is the root name, such as example.com. A subdomain is a name below it, such as www.example.com, app.example.com, or docs.example.com.

Many websites use both apex and www:

example.com
www.example.com

You should choose which one is canonical. The canonical domain is the preferred public address. The other domain usually redirects to it.

For example:

Canonical: https://www.example.com
Redirect:  https://example.com -> https://www.example.com

Or:

Canonical: https://example.com
Redirect:  https://www.example.com -> https://example.com

Either can be valid. What matters is choosing intentionally and avoiding two independent copies of the same site. Search engines, analytics, cookies, and user bookmarks all become easier to reason about when one address is canonical.

DNS Record Basics

Vercel's dashboard gives the DNS records it expects. You normally configure those records wherever DNS is managed. That might be the domain registrar, a separate DNS provider, or Vercel itself if the domain uses Vercel nameservers.

The common record types are:

A record
  points a name to an IPv4 address

CNAME record
  points a name to another hostname

TXT record
  stores text used for verification or service configuration

Apex domains often use an A record or provider-specific flattening/alias behavior. Subdomains such as www often use a CNAME. Do not guess. Use the records Vercel shows for your domain and project.

DNS record names can be confusing in registrar dashboards. Some providers ask for www; others expect the full name www.example.com. Some use @ to mean the apex/root domain. If the dashboard says @, that usually means the root domain, not an email address.

A simple note helps avoid mistakes:

Apex/root: example.com, often shown as @
Subdomain: www.example.com, often shown as www
Canonical domain: chosen production address
DNS provider: where records are edited
Vercel project: where the domain is added

Adding The Domain In Vercel

In Vercel, open the project and add the custom domain in the Domains settings. Vercel will check whether it can verify the domain and whether DNS points correctly.

For a course exercise, use a domain you own personally and can safely edit. Do not practice on a client domain, employer domain, or production business domain unless you are working under the correct account, plan, and approval process. A wrong DNS change can take a real site offline.

A safe domain setup sequence is:

1. Confirm who owns the domain.
2. Confirm where DNS is managed.
3. Add the domain to the Vercel project.
4. Copy the exact DNS records Vercel recommends.
5. Add or update records at the DNS provider.
6. Wait for Vercel to verify configuration.
7. Open the domain in a browser.
8. Confirm HTTPS works.
9. Confirm the chosen canonical redirect works.

Do not delete existing DNS records casually. A domain may also receive email, serve another subdomain, verify analytics, or support other services. If you do not know what a record does, identify it before removing it.

HTTPS And Certificates

HTTPS protects the connection between the browser and the site. It prevents ordinary network observers from reading or changing traffic in transit and allows browsers to show the secure lock indicator. Modern production sites should use HTTPS by default.

Vercel manages HTTPS for configured domains. Once the domain is added, verified, and pointed correctly, Vercel can provision and manage certificates for the domain. You should not need to manually upload a certificate for normal Vercel domain usage.

That does not mean HTTPS is instant in every case. DNS changes can take time to propagate. Certificate issuance can depend on correct domain validation. If the browser shows a certificate warning immediately after a DNS change, do not panic, but do investigate. Check Vercel's domain status, confirm DNS records, and wait for propagation if the records are fresh.

A useful verification is:

http://example.com
  redirects or upgrades to HTTPS

https://example.com
  loads without certificate warning

https://www.example.com
  loads or redirects according to canonical choice

If one version works and the other does not, check whether both the apex and www names were added and configured.

Domain Ownership For Client Work

A client should usually own their domain. They should own the registrar account or have clear organizational control over it. They should also own the Vercel team or project that serves the production site. A contractor can be invited with appropriate access, but the client's production domain should not depend on a contractor's personal account.

Bad ownership creates real risk:

• the client cannot change DNS after the developer leaves;
• billing failure in a personal account affects a business website;
• production secrets and domain settings live with the wrong person;
• the wrong team can redirect traffic;
• domain renewal notices go to an old email address;
• the site cannot be recovered quickly during an incident.

For commercial work, write down ownership before launch:

Domain registrar owner: client organization
DNS provider: client organization account
Vercel team owner: client organization
Billing owner: client organization
Developer access: least privilege, removable
Canonical domain: agreed before launch

This is not bureaucracy. It is part of keeping production recoverable.

Avoiding DNS Downtime

DNS changes can break working sites. Before changing records, identify what currently serves the domain. Is it an old host? A WordPress site? A staging page? Email verification? A CDN? A redirect service?

For a real migration, plan the cutover:

Current production host identified.
New Vercel deployment verified on generated URL.
Custom domain added in Vercel.
Required DNS records recorded.
Rollback record values saved.
Low-risk launch window chosen if needed.
Post-change checks prepared.

For a first course site, the risk is low because the domain likely has no users. For a business domain, the risk can be high. Never experiment with production DNS without permission and a rollback plan.

DNS propagation also means changes are not always visible everywhere at once. Your phone, laptop, office network, and public DNS resolver may not all see the new answer immediately. Test from more than one network or DNS checker when diagnosing, but do not paste private project details into random tools.

Canonical Redirects And Clean Addresses

Once both apex and www work, decide which address users should see. Redirect the other address to the canonical one. This avoids duplicate versions of the site.

A consistent domain plan might be:

User-facing domain: www.example.com
Apex behavior: redirects to www.example.com
Preview URLs: used only for review
Generated deployment URLs: used for diagnosis and comparison

Or:

User-facing domain: example.com
www behavior: redirects to example.com
Preview URLs: used only for review
Generated deployment URLs: used for diagnosis and comparison

Do not switch the canonical domain casually after launch. Cookies, analytics, search indexing, backlinks, and user bookmarks can all be affected. If a change is necessary, use deliberate redirects and verify important paths.

Troubleshooting A Domain That Does Not Work

When a custom domain does not load, diagnose one layer at a time. First check whether the domain is added to the correct Vercel project. A domain added to a different project or team will not prove that this project is configured correctly. Next check where DNS is actually managed. The registrar may show nameservers that point to another provider, which means editing records at the registrar will not affect live DNS answers.

Then compare the live DNS records with the exact records Vercel recommends. Watch for common small errors: an extra domain suffix, a record added to the wrong host name, an old conflicting record, or a CNAME placed where the provider expects an apex-compatible record. If the records were just changed, allow for propagation and cached answers before making several unrelated edits.

Finally, test both HTTP and HTTPS for the apex and www names. A domain can point correctly while certificate issuance is still pending, or HTTPS can work for one name while the other name was never added. Record what you tested and what happened. Clear observations make DNS problems much easier to resolve than repeated guessing.

Verification Checklist

After connecting a custom domain, check the public result:

Apex domain configured or intentionally unused.
www subdomain configured or intentionally unused.
Canonical redirect works.
HTTPS loads without certificate warnings.
Generated Vercel URL still works for deployment comparison.
Production domain serves the expected deployment.
No private preview content is exposed on the production domain.
DNS ownership and billing ownership are documented.

For a real project, also check analytics, forms, webhooks, cookies, OAuth redirect URLs, payment return URLs, email links, sitemap URLs, and canonical metadata. Many integrations care about the exact domain.

Common Domain Mistakes

The first mistake is editing DNS at the wrong provider. If the domain uses external nameservers, changing records at the registrar may do nothing.

The second mistake is configuring only www and forgetting the apex, or configuring only the apex and forgetting www. Users type both.

The third mistake is expecting DNS to update everywhere instantly. Propagation takes time and caches may hold older answers.

The fourth mistake is deleting email records. Website DNS changes should not break MX, SPF, DKIM, or DMARC records used for email.

The fifth mistake is treating HTTPS warnings as cosmetic. A certificate warning means users cannot safely trust the connection. Fix it before calling the launch complete.

The sixth mistake is using a custom domain before plan and ownership questions are settled. A production domain makes the deployment feel official, so the account, billing, and responsibility model must already be right.

Review Questions

• What is the difference between an apex domain and a subdomain?
• Why should a site choose one canonical domain?
• What has to be configured both in Vercel and at the DNS provider?
• Why should client domains be owned by the client organization?
• What should you verify after Vercel provisions HTTPS?
• Why should you avoid deleting unknown DNS records?

Official References

• Vercel Domains Overview
• Adding and Configuring a Custom Domain
• Vercel Deployment Environments