How to Connect a Domain to GoHighLevel depends on whether you want to use a root domain such as example.com or a subdomain such as go.example.com, but the basic process is straightforward: add the domain in HighLevel, configure or authorize the required DNS record, verify the connection, assign the domain to your site, and select the correct default page.

The basic setup looks like this:

Domain

↓

DNS Provider

↓

HighLevel Verification

↓

Website / Funnel

↓

Default Page

↓

Automatic SSL

HighLevel currently supports both automatic Domain Connect and manual DNS configuration for Sites products such as Websites, Funnels, Stores, Blogs, and Webinars.

For a dedicated reference page about this process, see How to Connect a Domain to GoHighLevel.

Start Your GoHighLevel 30-Day Free Trial →

Connecting a domain tells the Domain Name System where visitors should be sent when they enter your branded web address.

For example:

example.com

can load:

Your HighLevel Website

while:

offers.example.com

could load:

Your HighLevel Funnel

HighLevel supports custom domains for customer-facing Sites experiences, allowing businesses to publish content using their own branded addresses rather than relying on a default platform URL.

Within HighLevel Sites, custom domains can currently be used for supported experiences including:

The exact configuration depends on the HighLevel product you are connecting.

This guide focuses primarily on:

Websites

and:

Funnels

because they are among the most common domain use cases.

Before changing DNS, decide which address you actually want HighLevel to use.

A root domain is the primary domain:

example.com

A subdomain adds a prefix:

www.example.com

go.example.com

offers.example.com

book.example.com

HighLevel supports both root domains and subdomains for Sites.

Use the root domain when HighLevel will host the primary public website.

For example:

example.com

→ HighLevel Website

Use a subdomain when the root domain already serves another important system.

For example:

example.com

→ WordPress Website

go.example.com

→ HighLevel Funnel

HighLevel specifically warns against repointing a root domain that is already being used for another website or service. In that situation, an available subdomain is generally the safer architecture.

A common domain mistake is trying to make the exact same hostname serve multiple unrelated platforms simultaneously.

For example:

example.com

cannot normally point directly to:

WordPress Server

and:

HighLevel Server

at the same time.

HighLevel documents that one hostname cannot point to multiple platforms or servers simultaneously.

Instead, structure the domain family.

example.com

→ Existing Website

offers.example.com

→ HighLevel Funnel

book.example.com

→ HighLevel Booking Experience

This keeps each hostname's destination clear.

The current setup can be completed in five main stages.

Inside the relevant HighLevel sub-account:

Settings

↓

Domains & URL Redirects

↓

+ Connect a domain

Then locate:

Funnel / Website / Store / Blog / Webinar

and select:

Connect

This opens the Sites domain connection workflow.

Enter the address you want to connect.

For a root domain:

example.com

For a subdomain:

offers.example.com

Do not automatically choose the root domain simply because it looks cleaner.

First determine whether that root domain already hosts something important.

HighLevel currently provides two primary connection methods:

HighLevel attempts to detect a supported DNS provider and configure the necessary records through an authorization process.

You manually add the required DNS record at the provider that manages the domain's active DNS.

Both methods ultimately accomplish the same objective:

Point the selected hostname to HighLevel.

Domain Connect is the easier method when the provider is supported.

The workflow is:

Enter Domain

↓

Continue

↓

Provider Detected

↓

Authorize

↓

Sign In to Provider

↓

Approve DNS Changes

↓

Return to HighLevel

↓

Verification

HighLevel can automatically create the necessary records after successful authorization.

It reduces the need to manually work with:

A Records

CNAME Records

Hosts

and:

Targets

This can reduce configuration mistakes.

However, you should still understand what DNS is doing.

Automatic configuration does not make DNS conflicts impossible.

Manual setup gives you direct control over the DNS records.

After entering the domain, choose:

Add record manually

HighLevel will provide the required configuration.

For its current Sites infrastructure, HighLevel documents the following manual setup.

Always follow the records HighLevel displays for your actual connection if the platform instructions differ in the future.

Suppose you want:

example.com

to load your HighLevel site.

The documented manual configuration is:

Type: A

Host: @

Value: 162.159.140.166

The @ symbol normally represents the root domain at DNS providers.

Suppose you want:

offers.example.com

The documented CNAME setup is:

Type: CNAME

Host: offers

Target: sites.ludicrous.cloud

Notice that the Host is:

offers

not:

offers.example.com

and not:

https://offers.example.com

HighLevel specifically instructs users to enter only the subdomain portion in the Host/Name field.

If you configure:

offers.example.com

do not create both:

A record for offers

and:

CNAME record for offers

HighLevel explicitly warns against creating both record types for the same hostname.

Choose the supported configuration you intend to use.

Suppose your business owns:

brightagency.com

and HighLevel will host the main website.

Your architecture could be:

brightagency.com

↓

A Record

↓

HighLevel

↓

Website

The process is:

When connecting a root domain, HighLevel can also configure the www version and redirect it to the root domain using a 301 redirect.

This allows:

www.brightagency.com

to redirect to:

brightagency.com

when configured through the supported setup.

Suppose:

brightagency.com

already hosts a WordPress site.

Do not casually repoint its root A record to HighLevel.

Doing that could replace the destination of the existing website.

Instead, you might create:

go.brightagency.com

Then:

brightagency.com

→ WordPress

go.brightagency.com

→ HighLevel

This is one of the main reasons subdomains are useful.

HighLevel recommends using a subdomain when the root domain is already being used elsewhere.

Suppose you run a campaign.

You could use:

offers.brightagency.com

Then:

Ad

↓

offers.brightagency.com

↓

HighLevel Funnel

↓

Lead Form

↓

CRM

↓

Workflow

The main website does not need to move.

Only the campaign subdomain points to HighLevel.

After DNS is configured, HighLevel needs to detect the correct record.

This may happen quickly.

But DNS changes are not always immediate.

HighLevel advises that DNS propagation can take up to 24 hours.

Therefore:

Record Added

does not always mean:

Globally Updated Immediately

Avoid repeatedly changing correct records simply because verification does not happen within a few minutes.

DNS information is distributed across many systems.

When you change a record, different DNS resolvers may receive the new information at different times.

That creates a temporary period where:

Some Users See New Destination

while:

Others May Still See Old Destination

This is propagation.

HighLevel states that DNS changes may require up to 24 hours to propagate.

Often the change happens sooner.

But plan for propagation when launching important campaigns.

DNS verification alone is not the end of the process.

HighLevel must also know:

Which Website?

or:

Which Funnel?

should use the domain.

After verification:

HighLevel then begins provisioning SSL automatically.

Suppose your domain is:

example.com

but your homepage exists internally as:

/home

Without correct default-page configuration, visitors may not see the intended page when entering:

example.com

HighLevel allows you to choose the page or funnel step that loads at the bare domain.

The goal is:

example.com

→ Homepage

instead of requiring:

example.com/home

The connected domain can be managed from:

Settings

↓

Domains & URL Redirects

↓

Manage Domain

↓

Edit Domain

Then choose the appropriate default page.

A 404 page handles URLs that do not exist.

For example:

example.com/old-page

If that path no longer exists, visitors should receive a useful error experience rather than confusing behavior.

HighLevel's current domain settings support configuring a default 404/error page for eligible Sites domains.

A useful 404 page can provide:

Clear Error Message

Homepage Link

Navigation

and:

Relevant CTA

Do not leave users at a dead end.

After a domain connects successfully, HighLevel automatically provisions SSL for supported Sites domains.

You generally do not need to purchase a separate SSL certificate specifically for the connected HighLevel Sites domain.

The result should be:

https://example.com

rather than an unsecured HTTP-only experience.

HighLevel notes that SSL provisioning can take a few minutes after the domain is successfully linked.

If the domain was just connected, allow the provisioning process to complete before assuming SSL is broken.

Cloudflare requires special attention.

If Cloudflare manages your DNS, HighLevel currently instructs users to set the relevant A or CNAME record to:

DNS only

not:

Proxied.

In Cloudflare terms:

DNS only

is the required setting for the HighLevel Sites record.

When proxying is enabled, Cloudflare sits between the hostname and the destination.

HighLevel's current Sites domain configuration does not support Cloudflare Proxy on the records used for this connection.

Symptoms may include:

Domain Verification Failure

Privacy / SSL Errors

Missing Images

or:

Site Loading Problems

If DNS otherwise appears correct, check the Cloudflare proxy setting.

Suppose:

offers.example.com

will point to HighLevel.

Create:

Type: CNAME

Name: offers

Target: sites.ludicrous.cloud

Proxy Status: DNS only

Then return to HighLevel and verify the connection.

One of the most common mistakes is editing DNS at the wrong company.

Suppose:

Domain Registered At: GoDaddy

but:

Nameservers Point To: Cloudflare

In that situation, the active DNS is controlled by Cloudflare.

Changing the DNS zone inside GoDaddy may not affect the live domain.

Always determine:

Who manages the active nameservers?

before changing records.

These are not always the same company.

The company where the domain is registered.

The service whose nameservers currently control DNS.

They may be identical.

But they do not have to be.

The active nameserver configuration determines where the relevant DNS changes must be made.

Nameservers tell the internet where to look for a domain's DNS records.

HighLevel's domain documentation identifies nameservers as the system that organizes and controls DNS records for the domain.

Before troubleshooting an apparently correct record, confirm you edited the correct DNS zone.

HighLevel may report that the required record cannot be found.

Check these items in order:

1. Correct DNS Provider

↓

2. Correct Host

↓

3. Correct Record Type

↓

4. Correct Target

↓

5. No Conflicting Record

↓

6. Cloudflare DNS Only

↓

7. DNS Propagation

HighLevel specifically recommends checking these areas when the required record cannot be detected.

For:

www.example.com

the Host normally should be:

www

For:

offers.example.com

the Host normally should be:

offers

Do not enter:

https://offers.example.com

HighLevel's current manual configuration instructions require the subdomain portion rather than the full URL in the Host/Name field.

For the documented CNAME Sites configuration:

sites.ludicrous.cloud

is the current target.

For the documented Sites A record:

162.159.140.166

is the current target.

Because infrastructure can change, use the record HighLevel displays in your account if it differs from documentation.

Suppose www already has:

A → Old Server

and you add:

CNAME → HighLevel

That creates a conflict.

HighLevel explicitly says not to create an A and CNAME for the same hostname.

Remove or update conflicting records only after confirming what the old record is used for.

HighLevel's domain troubleshooting documentation also identifies AAAA record conflicts as a potential domain connection problem.

An AAAA record points to an IPv6 address.

If domain verification or routing remains inconsistent despite the required HighLevel records being correct, inspect other records associated with the same hostname rather than looking only at the A/CNAME entry.

CAA records control which certificate authorities are allowed to issue certificates for a domain.

HighLevel identifies CAA conflicts as another potential domain troubleshooting area.

This becomes particularly relevant when:

DNS verifies

but:

SSL provisioning fails

Do not delete security-related DNS records blindly.

Understand what they control before modifying them.

Another possible issue is that the domain is already connected to another destination or HighLevel configuration.

HighLevel lists:

Domain is Connected Elsewhere

among its current troubleshooting scenarios.

Before reconnecting a domain, identify the existing use.

This usually indicates that a DNS record serving the existing website was replaced.

For example:

Before:

example.com

→ Existing Hosting

After:

example.com

→ HighLevel

The browser is now correctly following the new DNS instruction.

The problem is architectural, not necessarily a HighLevel malfunction.

If the original website needs to remain active, restore the appropriate setup and use a separate subdomain for HighLevel.

If DNS is correct but the visitor receives a 404, check:

Is the domain verified?

Is it linked to the correct funnel?

Is the correct step selected?

Is the requested path valid?

Is a default page configured?

HighLevel specifically recommends confirming domain verification and funnel assignment when a funnel does not load.

A common configuration problem occurs when:

example.com

works

but:

www.example.com

does not.

Or the opposite.

HighLevel's root-domain connection flow can add the www version and configure a 301 redirect to the root domain.

Choose a canonical version and configure routing consistently.

A 301 redirect permanently sends visitors from one URL to another.

For example:

www.example.com

→

example.com

This helps consolidate visitors around the intended domain version.

It can also reduce duplicate URL confusion.

Possible causes include:

DNS Cache

Browser Cache

Propagation

Wrong Default Page

or:

Wrong Site Assignment

Check each layer.

Do not immediately delete and recreate the domain connection.

If DNS has just been verified, allow time for SSL provisioning.

HighLevel automatically begins the SSL process after the domain connection is completed.

If SSL remains unavailable after the normal setup period, inspect:

DNS

Proxy Status

CAA Records

and:

Domain Assignment

before troubleshooting further.

Yes.

A connected domain can serve multiple pages through URL paths.

For example:

example.com

example.com/about

example.com/services

example.com/contact

A domain does not mean:

One Domain = One Page

The domain establishes the host.

Paths organize content beneath it.

HighLevel's documentation states that multiple funnels/websites can be connected within the same domain environment, subject to correct paths and configuration.

Plan paths carefully to avoid conflicts.

A business using HighLevel for its complete public website might use:

Root

example.com

Pages

example.com/about

example.com/services

example.com/contact

Funnels

example.com/special-offer

This can keep the customer-facing experience under one domain.

A business keeping another website platform could use:

Main Website

example.com

HighLevel Funnel

go.example.com

HighLevel Campaign

offers.example.com

This creates separation between systems.

There is no universal answer based solely on whether you use a root domain or subdomain.

The larger SEO considerations include:

Site Architecture

Content Quality

Internal Linking

Indexability

Canonicalization

Redirects

Performance

and:

Search Intent

Do not move an established website purely because you assume HighLevel requires the root domain.

It does not.

Website DNS and email DNS serve different purposes.

An:

A Record

or:

CNAME

can route web traffic.

MX Records

control email delivery.

Connecting a HighLevel Website or Funnel does not mean you should randomly replace existing MX records.

Doing so can disrupt business email.

These are different configurations.

A Sites domain is used for experiences such as:

Website

Funnel

Store

or:

Blog

An email sending domain is used for email infrastructure and authentication.

HighLevel documents these as different domain types with different purposes.

Do not copy DNS records from one domain feature into another.

These are also different.

A Sites domain publishes customer-facing website/funnel content.

A white-label domain relates to agency branding and platform access.

HighLevel maintains separate domain configurations for different products.

Always choose the domain connection type based on what you are actually trying to publish or brand.

WordPress hosting is another separate use case.

If:

example.com

already points to WordPress,

you could use:

go.example.com

for a HighLevel funnel.

This avoids making both services compete for the same hostname.

HighLevel also allows domains purchased directly through its platform to be managed from within HighLevel.

For these domains, supported DNS records can be managed without signing into a separate registrar.

Current supported DNS management includes record types such as:

A

CNAME

AAAA

MX

and:

TXT.

This is different from connecting a domain purchased from an external registrar.

Purchased elsewhere.

DNS may be managed at:

Cloudflare

GoDaddy

Namecheap

or another provider.

You connect it to HighLevel.

Purchased through HighLevel.

DNS management is available within the HighLevel domain environment.

Both can ultimately be used with supported HighLevel Sites.

Yes.

This is often the cleanest architecture.

For example:

example.com

→ Main Website

shop.example.com

→ Store

go.example.com

→ Funnel

members.example.com

→ Another supported service where applicable

HighLevel's purchased-domain guidance recommends subdomains when different experiences need distinct destinations within the same domain family.

Before changing DNS, verify:

I own or control the domain.

I know where active DNS is managed.

I know whether the root domain already hosts a website.

I know whether I need root or subdomain.

I know which HighLevel Website/Funnel will use it.

I have identified any existing conflicting records.

This prevents most avoidable problems.

After adding the record, confirm:

Correct Type

Correct Host

Correct Target

No Duplicate A/CNAME

Cloudflare Proxy Off if applicable

Correct DNS Provider

Propagation Allowed

Do not proceed based only on what the DNS dashboard looks like.

HighLevel still needs to verify the record.

Inside HighLevel, confirm:

Domain Verified

↓

Correct Site Selected

↓

Correct Default Page Selected

↓

Domain Linked

↓

SSL Active

↓

404 Page Configured

↓

Live Site Tested

This completes the actual connection process.

After launch, test:

HTTP → HTTPS

Root Domain

www Version

Homepage

Important Paths

404 Page

Forms

Buttons

Navigation

Mobile

Tracking

and:

Redirects

HighLevel recommends testing website navigation, forms, buttons, and mobile layouts before publishing.

Suppose:

Domain: brightagency.com

Existing Website: WordPress

New HighLevel Funnel: Lead generation campaign

Do not repoint:

brightagency.com

Instead create:

go.brightagency.com

Then:

Type: CNAME

Host: go

Target: sites.ludicrous.cloud

Settings

↓

Domains & URL Redirects

↓

Connect a Domain

↓

go.brightagency.com

↓

Funnel / Website / Store / Blog / Webinar

↓

Verify

↓

Select Funnel

↓

Select Default Step

↓

Link Domain

↓

SSL

Then test:

https://go.brightagency.com

This preserves the WordPress website while adding HighLevel to the same domain family.

Suppose HighLevel will host everything at:

brightagency.com

The documented manual configuration would use:

Type: A

Host: @

Target: 162.159.140.166

Then:

HighLevel Verification

↓

Select Website

↓

Select Homepage

↓

Link Domain

↓

SSL Provisioned

↓

Configure www Redirect

↓

Test

HighLevel's root-domain workflow can also configure www and redirect it to the root domain.

If you are moving an existing live site to HighLevel, domain connection is only one part of the migration.

Also review:

Existing URLs

Redirects

Metadata

Canonical URLs

Analytics

Search Console

Forms

Tracking

Sitemaps

and:

Internal Links

Changing DNS does not automatically migrate the SEO architecture of the previous website.

A safer launch sequence is:

Build

↓

Review

↓

Test

↓

Prepare Redirects

↓

Connect Domain

↓

Publish

↓

QA

Do not point a production domain at an unfinished website simply because the DNS setup is ready.

For supported HighLevel Sites connections, no separate SSL purchase is normally required.

HighLevel provisions SSL automatically after the domain is successfully connected.

HighLevel's current Sites domain documentation states that there is no fixed limit on the number of domains you can add to an account for these supported uses.

However, more domains do not automatically improve marketing.

Each domain or subdomain should have a clear purpose.

A simple agency architecture might be:

Main Brand

agency.com

Lead Campaign

go.agency.com

Special Offer

offers.agency.com

But avoid creating unnecessary subdomains simply because the platform allows them.

Use the simplest structure that supports the customer journey.

If HighLevel hosts the full site:

localbusiness.com

may be sufficient.

Then use paths:

localbusiness.com/services

localbusiness.com/contact

localbusiness.com/book

instead of creating a subdomain for every page.

If WordPress remains the primary website:

business.com

→ WordPress

Then:

go.business.com

→ HighLevel Funnel

This is often easier than migrating the entire site solely to use HighLevel funnels.

For campaign-focused funnels:

offer.example.com

or:

go.example.com

can provide a branded address while keeping the main site untouched.

The exact naming matters less than:

Clarity

Consistency

and:

Correct DNS Configuration

Explore GoHighLevel With a 30-Day Free Trial →

Go to the relevant sub-account, open Settings → Domains & URL Redirects → Connect a domain, choose the Sites product, enter the root domain or subdomain, complete Domain Connect or manual DNS setup, verify the record, and link the domain to the correct Website or Funnel.

Yes. HighLevel supports root domains such as example.com for Sites products. Its current manual configuration documents an A record for the root hostname.

Yes. Subdomains such as go.example.com or offers.example.com can be connected to supported HighLevel Sites.

HighLevel's current manual Sites documentation specifies sites.ludicrous.cloud as the CNAME target for supported subdomain configurations.

HighLevel's current manual Sites documentation specifies 162.159.140.166 for the applicable A record configuration.

For the documented manual configuration, a root domain uses the A record, while a subdomain can use the documented CNAME or supported A-record alternative. Do not create both A and CNAME records for the same hostname.

Yes, but HighLevel currently requires the applicable Sites A or CNAME record in Cloudflare to use DNS only rather than Proxied.

One common reason is that the HighLevel record is set to Proxied. HighLevel currently instructs Cloudflare users to turn proxying off for the relevant Sites DNS record.

HighLevel advises that DNS changes can take up to 24 hours to propagate.

Yes. HighLevel automatically provisions SSL after a supported Sites domain is successfully connected.

Normally no for a supported HighLevel Sites domain. HighLevel states that it automatically generates SSL after successful domain connection.

Yes. If the root domain already serves WordPress, you can use a separate subdomain such as go.example.com for a HighLevel funnel rather than repointing the root hostname. HighLevel recommends using a subdomain when the root is already in use.

No. HighLevel states that a single domain/subdomain hostname cannot point to multiple platforms or servers simultaneously. Use different subdomains when different platforms need separate destinations.

Common causes include editing DNS at the wrong provider, using the wrong Host value, using an incorrect target, conflicting records, Cloudflare proxying, or waiting for DNS propagation.

Usually no. For offers.example.com, HighLevel's manual instructions specify using only offers as the Host/Name.

No. HighLevel explicitly says not to create both an A and CNAME record for the same hostname.

The default page is the Website page or Funnel step that loads when someone visits the domain without an additional URL path. HighLevel lets you assign this during or after domain setup.

Yes. Current HighLevel Sites domain management supports configuring a default 404/error page for connected domains.

Yes. During root-domain setup, HighLevel can add the www version and configure a 301 redirect from www to the root domain.

Check that DNS is verified, the domain is linked to the correct funnel, the requested path exists, and the appropriate default page or funnel step is configured.

Yes. HighLevel supports domains purchased and managed directly within the platform.

Yes. HighLevel currently supports managing DNS records such as A, CNAME, AAAA, MX, and TXT for domains purchased through its platform.

No. HighLevel uses different domain configurations for Sites, email sending, WordPress, Client Portal, agency branding, and other products.

No. A Sites domain publishes customer-facing Website, Funnel, Store, Blog, or related content. White-label domains serve different agency-branding purposes.

Not merely to connect a Website or Funnel. MX records control email delivery and should not be replaced unless the specific email configuration requires it.

Use the root domain when HighLevel should serve the primary site. Use a subdomain when the root domain already hosts another website or when you want a separate branded address for a funnel or campaign.

Connecting a domain to Go High Level is fundamentally a DNS routing process.

The cleanest setup is:

Choose Root Domain or Subdomain

↓

Add Domain in HighLevel

↓

Use Domain Connect or Manual DNS

↓

Verify Records

↓

Select Website / Funnel

↓

Set Default Page

↓

Link Domain

↓

Automatic SSL

↓

Test

For a new HighLevel-hosted website, the root domain may be appropriate.

For an existing website hosted elsewhere, a subdomain is often safer:

Main Website

example.com

↓

Existing Platform

while:

HighLevel Funnel

go.example.com

↓

HighLevel

HighLevel currently supports automatic Domain Connect where available and manual configuration when necessary. Its documented manual Sites configuration uses an A record for the root domain and supports CNAME-based subdomain configuration.

The most important rule is to understand the existing domain architecture before changing DNS.

Do not overwrite an active website record without knowing what it serves.

Do not create both an A and CNAME for the same hostname.

Do not enable Cloudflare Proxy on the HighLevel Sites connection record.

Do not modify MX records merely because you are connecting a website.

And do not assume a domain connection is complete until you have tested:

DNS

SSL

Root / www Behavior

Default Page

Important Paths

404 Handling

Forms

Navigation

and:

Mobile Experience

Once those pieces work together, the architecture becomes simple:

Branded Domain

↓

HighLevel Website or Funnel

↓

Conversion

↓

CRM

↓

Workflow

That gives visitors a professional branded URL while keeping the domain connected to the broader HighLevel marketing and CRM system.

Start Your GoHighLevel 30-Day Free Trial →