How To Connect A Domain In GoHighLevel depends first on what you want the domain to power.
HighLevel supports branded domains for Sites products such as:
funnels;
websites;
stores;
blogs;
webinars.
For these products, you can connect either a root domain such as:
example.com
or a subdomain such as:
offers.example.com
HighLevel currently provides two main setup paths:
Domain Connect
for compatible DNS providers.
or:
Manual DNS Configuration
when automatic connection is unavailable or you prefer to manage records yourself.
The typical setup is:
Choose Domain
↓
Start Connection in HighLevel
↓
Authorize Domain Connect or Add DNS Record
↓
Wait for Verification
↓
Select Funnel / Website
↓
Choose Default Page
↓
HighLevel Provisions SSL
Connecting the correct hostname is important because changing DNS for an existing root domain can replace or interrupt the website already running there.
For an additional step-by-step reference, see our How to Connect a Domain to GoHighLevel guide.
What Does Connecting a Domain to GoHighLevel Mean?
Connecting a domain tells the DNS system that visitors requesting a particular hostname should be routed to a HighLevel Sites property.
For example:
example.com
could load a HighLevel website.
Or:
offers.example.com
could load a HighLevel funnel while the main website remains somewhere else.
HighLevel currently supports Sites-domain connections for products including Funnels, Websites, Stores, Blogs and Webinars.
This gives businesses flexibility.
You do not necessarily need to move the entire company website into HighLevel.
Root Domain vs Subdomain
Understanding this distinction prevents many DNS mistakes.
Root Domain
The primary domain:
example.com
Subdomain
A prefix added before the root domain:
www.example.com
go.example.com
offers.example.com
book.example.com
HighLevel supports both root domains and subdomains for compatible Sites products.
When Should You Use the Root Domain?
Use the root domain when HighLevel should power the primary website.
For example:
Business Website
→ example.com
Possible architecture:
example.com
↓
HighLevel Website
↓
Forms
↓
CRM
↓
Workflows
This is appropriate when HighLevel is intended to become the primary web platform.
When Should You Use a Subdomain?
Use a subdomain when the root domain already powers something you want to keep.
For example:
Main WordPress Website
example.com
and:
HighLevel Funnel
offers.example.com
HighLevel specifically warns that if the root domain already hosts an active website or service that needs to remain online, you should use an available subdomain rather than repointing the root domain.
This is one of the safest integration patterns.
Example: WordPress Plus HighLevel
Suppose:
example.com
runs WordPress.
You want a HighLevel advertising funnel.
Use:
go.example.com
for HighLevel.
Architecture:
example.com
→ WordPress.
go.example.com
→ HighLevel Funnel.
That lets you keep the existing website intact.
Do Not Repoint an Existing Root Domain Without Checking It
Changing DNS for:
example.com
can affect whatever currently uses that hostname.
Before changing it, determine whether the root domain already powers:
WordPress;
Shopify;
another website builder;
an application;
another service.
A domain connection should be planned as infrastructure, not treated like changing a page setting.
Step 1: Decide What You Are Connecting
Before touching DNS, determine the HighLevel product.
Examples:
Main Website
example.com
Campaign Funnel
offers.example.com
Webinar
webinar.example.com
Store
shop.example.com
The product and hostname should be decided first.
Step 2: Open Domains & URL Redirects
For a Sites domain, HighLevel's current setup flow begins inside the relevant sub-account.
Navigate to:
Settings
↓
Domains & URL Redirects
↓
+ Connect a domain
Then locate:
Funnel / Website / Store / Blog / Webinar
and choose Connect.
This is important because HighLevel has multiple domain-related features.
A Sites domain is not the same thing as every other domain type available in the platform.
Step 3: Enter the Domain
Enter either:
Root
example.com
or:
Subdomain
offers.example.com
Do not enter a full page URL such as:
https://example.com/page
You are connecting the hostname.
HighLevel then provides the appropriate connection path.
Step 4: Choose Automatic or Manual Setup
You can currently choose between:
Continue
Attempts the automatic Domain Connect flow.
Add Record Manually
Shows the DNS configuration required for manual setup.
Automatic setup is easier when your DNS provider is supported.
Manual setup gives you direct control.
What Is Domain Connect?
Domain Connect is HighLevel's automated DNS setup method.
Instead of copying records manually, HighLevel can detect supported providers and request authorization to configure the required DNS settings.
The basic process is:
Enter Domain
↓
HighLevel Detects Provider
↓
Authorize
↓
DNS Records Added
↓
Verification
This can eliminate several common formatting mistakes.
Domain Connect Does Not Sell or Host the Domain
Domain Connect is a connection feature.
It does not mean HighLevel automatically owns an externally registered domain.
HighLevel's documentation states that for the external Domain Connect flow, you must already have the domain registered with a domain provider.
HighLevel also now supports domains purchased directly through the platform, but those follow a separate management flow.
Automatic Domain Connection Process
For a supported provider:
1. Enter the hostname.
Example:
example.com
2. Click Continue.
3. Authorize the DNS provider.
HighLevel requests permission to configure the required records.
4. Confirm the connection.
5. Wait for DNS verification.
6. Link the domain to the desired HighLevel property.
This is usually the simplest approach.
When Manual DNS Is Better
Manual setup can be useful when:
your provider is unsupported by Domain Connect;
you manage DNS through another platform;
you want full control over records;
automatic authorization fails.
HighLevel displays the necessary DNS information during the connection process.
Always use the current values displayed by HighLevel rather than copying an old tutorial blindly.
DNS targets can change over time.
Current Manual CNAME Method
HighLevel's current manual documentation supports using a CNAME for subdomains.
The current target is:
sites.ludicrous.cloud
For example:
Field | Value |
Type | CNAME |
Host |
|
Target |
|
So:
offers.example.com
points to HighLevel.
HighLevel notes that you should enter only the subdomain part in the Host/Name field—not the complete URL.
Example CNAME Record
Suppose you want:
go.example.com
The DNS record would use:
Type
CNAME
Host / Name
go
Target
sites.ludicrous.cloud
Do not enter:
https://go.example.com
in the Host field.
Current Manual A Record Method
HighLevel's current documentation also supports an A record.
The presently documented IP is:
162.159.140.166
For a root domain, an example may be:
Field | Value |
Type | A |
Host |
|
Value |
|
However, use the record HighLevel shows inside your current account whenever possible.
Platform infrastructure can change.
Do Not Add Both Record Types for the Same Host
HighLevel specifically warns not to create both an A record and CNAME for the same hostname such as:
www
Choose the appropriate method.
Incorrect duplicate records can prevent verification or create unpredictable DNS behavior.
Root Domain Example
Suppose you want:
example.com
to run HighLevel.
A common manual configuration uses:
Type: A
Host: @
Value: the current HighLevel-provided IP.
Then HighLevel can also help configure the www version and redirect it to the root domain.
Subdomain Example
Suppose you want:
offers.example.com
A common setup is:
Type: CNAME
Host: offers
Target: sites.ludicrous.cloud
Your root domain can remain unchanged.
What Happens to WWW?
When connecting a root domain, HighLevel currently provides an option to add the www version as well.
The system can then configure a 301 redirect so:
www.example.com
redirects to:
example.com.
This creates a consistent canonical address for visitors.
Why WWW and Non-WWW Matter
Without a deliberate configuration, visitors might use both:
example.com
and:
www.example.com
A clear redirect strategy reduces ambiguity.
Example:
↓
301
↓
example.com
For SEO-focused websites, it also helps maintain a consistent preferred hostname.
Cloudflare Users: Set Records to DNS Only
This is one of the most common HighLevel domain issues.
If Cloudflare manages your DNS, HighLevel currently instructs users to keep the applicable A or CNAME record set to:
DNS only
rather than:
Proxied.
In Cloudflare terms:
Gray Cloud
is what you generally want for the HighLevel Sites record.
Why Cloudflare Proxy Can Cause Problems
If Cloudflare proxying sits between HighLevel and the hostname during the connection process, HighLevel may not be able to verify or provision the domain correctly.
If the domain refuses to connect:
inspect the record;
switch Proxy Status to DNS Only;
wait;
retry verification.
This is often easier than deleting everything and starting again.
DNS Propagation
DNS changes are not always instant.
HighLevel notes that manual DNS changes can take time to propagate and may take up to approximately 24 hours in some situations.
Frequently, they appear much sooner.
But do not repeatedly modify correct records simply because they have not verified after two minutes.
Step 5: Wait for HighLevel Verification
After the appropriate DNS record exists, return to HighLevel.
The platform checks whether the hostname points correctly.
Once verified, you can associate the domain with the appropriate content.
At this point:
DNS Is Connected
but you still need to decide:
What should visitors see?
Step 6: Associate the Domain With a Funnel or Website
After verification, HighLevel asks which Sites property should use the domain.
Select the applicable:
Funnel;
Website;
or other supported Sites property available in the flow.
Then choose the page or funnel step that should become the default landing page.
Finally:
Link Domain.
What Is a Default Page?
The default page is what opens when someone visits the hostname without an additional path.
Suppose your website page normally exists at:
example.com/home
But you want:
example.com
to open that page directly.
Set that page as the domain's default page.
The visitor then gets:
example.com
rather than needing:
example.com/home
Default Page Example
Website pages:
/home
/services
/contact
Set:
/home
as Default.
Then:
example.com
loads the Home page.
Visitors can still access:
example.com/services
and:
example.com/contact
according to your site configuration.
Configure a 404 Page
HighLevel's current domain management also lets you determine what visitors see when they request an invalid or unavailable URL.
For example:
example.com/does-not-exist
should not lead to a confusing experience.
Create a useful 404 page containing:
clear message;
homepage link;
important navigation;
possibly a search or CTA.
Step 7: Wait for SSL
Once the domain is successfully linked, HighLevel automatically starts provisioning an SSL certificate.
HighLevel says this can take a few minutes.
After SSL is ready, visitors should access:
https://example.com
instead of an insecure HTTP connection.
You Normally Do Not Need to Buy a Separate SSL Certificate
For HighLevel Sites domain connections, SSL is provisioned as part of the connection process.
That simplifies setup.
If the site still displays SSL errors shortly after connection, allow time for provisioning before changing DNS unnecessarily.
Step 8: Publish the Website
Connecting the domain does not automatically mean your most recent website changes are live.
HighLevel's website-launch documentation distinguishes between:
Save
and:
Publish
Saved changes do not become public until they are published.
A correct domain pointing at unpublished content can therefore appear incomplete.
Final Launch Sequence
A clean workflow is:
Build
↓
Save
↓
Preview
↓
Connect Domain
↓
Verify DNS
↓
Associate Page
↓
SSL
↓
Publish
↓
Test Public URL
Do not stop after DNS verification.
Test the Root URL
Open:
https://example.com
Check:
correct page;
SSL;
layout;
mobile rendering.
Then test other paths.
For example:
/contact
/services
/thank-you
A domain can connect successfully while individual pages still have configuration problems.
Test Both WWW and Non-WWW
Try:
https://example.com
and:
https://www.example.com
If you configured root-domain redirection, verify that the secondary version redirects correctly.
HighLevel's root-domain setup can configure www with a 301 redirect toward the root hostname.
Test Forms After Domain Connection
Changing domains can affect the customer journey.
Submit a test lead.
Verify:
Form
↓
Contact
↓
Workflow
↓
Opportunity
↓
Confirmation
The web page loading correctly does not guarantee the underlying automation works.
Test Calendars
If the website includes HighLevel booking:
open the public page;
select a date;
book a test appointment;
confirm the CRM receives it;
verify reminders.
A domain setup should be tested as part of the complete conversion flow.
Practical Use Case 1: HighLevel as the Main Website
Architecture:
example.com
↓
HighLevel Website
↓
Forms
↓
CRM
↓
Automation
This is the simplest domain architecture when HighLevel owns the whole website experience.
Practical Use Case 2: WordPress Main Site + HighLevel Funnel
Architecture:
example.com
→ WordPress.
go.example.com
→ HighLevel.
This is useful for businesses that want WordPress to continue handling:
SEO;
blog content;
main website;
while HighLevel handles campaign funnels.
Practical Use Case 3: Client Campaign Subdomain
An agency may create:
offer.clientdomain.com
for a paid advertising campaign.
Journey:
Meta / Google Ad
↓
offer.clientdomain.com
↓
Lead Form
↓
HighLevel CRM
↓
Workflow
This keeps campaign branding aligned with the client's domain.
Practical Use Case 4: Webinar Domain
Use:
webinar.example.com
for a HighLevel webinar experience.
That keeps the primary website untouched while creating a dedicated campaign hostname.
Practical Use Case 5: Store Domain
A business might use:
shop.example.com
for its HighLevel Store while:
example.com
remains the primary business website.
HighLevel's Sites-domain flow currently supports Stores alongside Websites, Funnels, Blogs and Webinars.
Practical Use Case 6: Blog Domain
A business could use:
blog.example.com
for a HighLevel Blog if it wants the content environment separated from the main hostname.
Whether this is better for SEO than placing the blog within the root-domain architecture depends on the wider site strategy.
Domain structure should follow a deliberate content plan.
Practical Use Case 7: Agency Template
An agency can standardize client subdomain naming.
For example:
Funnels
go.clientdomain.com
Bookings
book.clientdomain.com
This improves operational consistency.
But do not create unnecessary subdomains merely because they are available.
Each hostname adds something else to manage.
Root Domain vs Subdomain: Which Is Better?
Neither is universally better.
Use the root when:
HighLevel is the main website;
nothing important currently uses the root hostname.
Use a subdomain when:
an existing site must remain;
HighLevel powers only a campaign or specialized experience.
The safest decision is usually based on existing infrastructure.
How to Connect a Domain Purchased Through HighLevel
HighLevel also supports buying domains directly through the platform.
Domains purchased through HighLevel can have supported DNS records managed from inside the relevant sub-account rather than requiring another registrar dashboard.
The workflow differs from externally registered domains because HighLevel already manages the registration environment.
Purchased Domain Use Case
If an agency purchases:
clientbrand.com
through HighLevel, it can:
manage supported DNS records;
connect the domain to a Funnel;
connect it to a Website;
connect supported Sites products;
without switching between HighLevel and a separate registrar for routine configuration.
This can simplify client provisioning.
Domain Purchased Through HighLevel vs External Registrar
HighLevel-Purchased Domain
DNS management can happen inside HighLevel.
External Domain
DNS remains managed through the provider unless Domain Connect automatically configures the required records.
Neither approach is inherently better.
The important thing is knowing where authoritative DNS is managed.
Do Not Confuse a Sites Domain With an Email Sending Domain
HighLevel has multiple domain concepts.
Examples include:
Sites Domain;
Email Sending Domain;
Client Portal Domain;
API/white-label-related domains;
WordPress-related domains.
HighLevel's current documentation explicitly separates these different domain types.
Connecting:
example.com
to a funnel does not automatically configure everything needed for email authentication.
Sites Domain
Used for:
Websites;
Funnels;
Stores;
Blogs;
supported Sites experiences.
Email Sending Domain
Used for email infrastructure and authentication.
This follows a separate configuration process.
Do not overwrite email records because you are trying to connect a website.
Client Portal Domain
A Client Portal domain can provide a branded hostname for supported portal experiences.
Again, this is separate from the standard Sites domain flow.
The general lesson is:
Identify Domain Purpose First
↓
Then Configure DNS
Do Not Delete MX Records
When connecting a website domain, be careful around existing email records.
MX records typically determine where email for the domain is delivered.
A website DNS change should not require deleting unrelated email records unless current HighLevel instructions explicitly say otherwise for a specific configuration.
Changing unrelated DNS records can break business email.
Do Not Delete TXT Records Randomly
TXT records can support:
domain verification;
SPF;
DKIM-related configurations;
third-party services.
If you see unfamiliar DNS entries, do not remove them merely to make the DNS screen look cleaner.
Change only the records required for the HighLevel connection.
Troubleshooting: Domain Will Not Verify
Start with DNS.
Check:
Host
Is the Host value correct?
For:
go.example.com
the provider may expect:
go
rather than:
go.example.com.
Target
Does it exactly match HighLevel's current value?
Duplicate Records
Is there another conflicting A or CNAME for the same host?
Cloudflare
Is Proxy Status set to DNS Only?
Propagation
Have you allowed sufficient time?
These checks resolve many connection problems.
Troubleshooting: Existing Website Disappeared
If this happened after connecting the root domain, the DNS record may now point the root hostname at HighLevel instead of the previous hosting provider.
If the previous site needs to remain active:
restore the previous root-domain DNS
and instead connect an unused subdomain to HighLevel.
HighLevel specifically recommends using a subdomain when the root domain already hosts an active service that should remain online.
Troubleshooting: Cloudflare Domain Remains Pending
Check the orange-cloud proxy.
HighLevel's current setup documentation instructs Cloudflare users to set relevant A/CNAME records to:
DNS only.
Then allow DNS time to update and retry.
Troubleshooting: SSL Is Pending
If DNS has just connected:
wait a few minutes.
HighLevel provisions SSL automatically after the domain association succeeds.
If the issue remains after DNS has clearly propagated, inspect:
competing DNS records;
Cloudflare proxying;
incorrect host values.
Troubleshooting: Root Works but WWW Does Not
Check whether the www hostname was added.
For the root-domain setup, HighLevel can add the www version and configure a redirect to the root address.
If you configured records manually, confirm the www record exists and points correctly.
Troubleshooting: WWW Works but Root Does Not
The subdomain:
www.example.com
can have a valid CNAME while the apex:
example.com
still has no correct A record.
Check the root-domain record separately.
Each hostname needs an appropriate DNS path.
Troubleshooting: Site Shows the Wrong HighLevel Page
DNS may be correct.
The issue can instead be the default page association.
Open:
Settings
↓
Domains & URL Redirects
↓
Manage Domain
and inspect which page is selected as the default.
This is an application-level issue, not necessarily a DNS problem.
Troubleshooting: Changes Are Saved but Not Visible
Check whether the site was actually published.
HighLevel distinguishes:
Save
from:
Publish.
If DNS is correct but content looks old, publish the current version and retest.
Troubleshooting: DNS Changed but Browser Shows Old Version
Possible causes include:
local DNS cache;
browser cache;
ISP resolver cache;
propagation delay.
Try:
another network;
private/incognito browser;
a DNS lookup tool.
Do not repeatedly rewrite correct DNS records simply because one device shows cached results.
Domain Connection Checklist
Before changing anything:
1. Identify Current Website
Does the root domain already host something?
2. Choose Hostname
Root or subdomain?
3. Identify DNS Provider
Where are nameservers managed?
4. Start in HighLevel
Settings → Domains & URL Redirects
5. Choose Sites Product
Funnel / Website / Store / Blog / Webinar.
6. Use Domain Connect or Manual DNS
Follow current HighLevel values.
7. Verify DNS
Allow propagation.
8. Associate Content
Choose the correct site and default page.
9. Wait for SSL
Confirm HTTPS.
10. Publish
Make sure the content itself is live.
11. Test
Check the full conversion path.
This sequence prevents most common mistakes.
Recommended Agency Domain Architecture
An agency should create naming standards.
For example:
Main Client Website
client.com
HighLevel Marketing Funnel
go.client.com
Dedicated Booking Experience
book.client.com
But only create separate domains where they serve a clear purpose.
Too many hostnames increase maintenance.
Document DNS Changes
For every client, record:
domain;
registrar;
DNS provider;
HighLevel sub-account;
connected product;
hostname;
record type;
date configured.
Do not depend on one team member remembering the infrastructure.
Avoid Giving Everyone DNS Access
Domain controls are high-impact.
A single incorrect DNS edit can affect:
website;
email;
verification services.
Give registrar access only to people who genuinely need it.
Back Up Existing DNS Before Changes
Before editing records, save:
screenshots;
exported zone file where supported;
existing A/CNAME/MX/TXT values.
If something breaks, you have a reference for restoring the previous state.
Do Not Change Nameservers Unless Required
Connecting a Sites domain normally involves specific DNS records.
It does not necessarily require transferring the entire domain or changing its nameservers.
Changing nameservers moves control of the whole DNS zone.
That is a much larger change.
Follow the exact HighLevel connection instructions instead.
SEO Considerations When Changing Domains
If you are simply pointing an unused hostname to a new HighLevel website, SEO impact may be limited.
If you are replacing an existing live website, additional planning becomes necessary.
Consider:
URL structure;
redirects;
canonical tags;
sitemap;
indexing;
existing backlinks.
Connecting DNS is only the infrastructure step.
It does not automatically preserve an old site's SEO.
Migrating an Existing Website to HighLevel
Suppose the old site has:
example.com/services
and the new HighLevel version uses:
example.com/our-services
If the old URL has backlinks or traffic, create an appropriate redirect where supported.
Otherwise visitors may encounter:
404
and search engines may lose the old URL relationship.
Domain connection and website migration are separate tasks.
Keep URL Structure When Practical
If an existing site already ranks well, preserving important URLs can simplify migration.
For example, keep:
/services
rather than changing it unnecessarily to:
/what-we-do-new
unless there is a reason.
Every changed URL can create another redirect requirement.
Configure 404 Intentionally
HighLevel lets domain managers configure default and error-page behavior.
A good 404 page can help users recover.
Include:
homepage link;
important services;
contact option.
Do not leave visitors at a dead end.
Use a Subdomain for Temporary Campaigns
Suppose the primary website performs well.
Rather than rebuilding it for a six-week promotion, use:
promo.example.com
for HighLevel.
After the campaign:
keep it;
redirect it;
retire it carefully.
This isolates campaign infrastructure from the main site.
HighLevel Domain Connection for Agencies
Agencies should think about domain setup as part of onboarding.
A standard workflow could be:
Client Signs
↓
Collect Domain/DNS Access
↓
Determine Architecture
↓
Connect Subdomain
↓
Build Funnel
↓
Test
↓
Launch
Do not wait until the final launch day to discover nobody knows who manages DNS.
Collect Domain Information Early
During onboarding, ask:
Where is the domain registered?
Where is DNS hosted?
Who has login access?
Is Cloudflare involved?
What currently uses the root domain?
Is business email using the domain?
These questions prevent launch delays.
Do Not Ask Clients to Send Passwords by Plain Email
Use secure credential-sharing procedures appropriate to your organization.
Where possible, use:
delegated access;
temporary access;
provider authorization.
Domain credentials can control critical business infrastructure.
HighLevel Domain Connect Can Reduce Credential Handling
Where supported, Domain Connect allows the domain owner to authorize the connection directly with the provider rather than having the agency manually edit every DNS field.
That can simplify setup and reduce transcription errors.
Advantages of Domain Connect
Faster Setup
Less copying between dashboards.
Lower Error Risk
HighLevel configures required records.
Easier for Nontechnical Users
The provider handles much of the process.
Tradeoffs of Domain Connect
Provider Support
Not every DNS setup may support it.
Authorization Required
The user still needs access to the domain account.
Manual Knowledge Still Matters
An agency should understand DNS even when automation handles it.
Automatic setup is convenient.
It should not replace basic troubleshooting knowledge.
Advantages of Manual DNS
Control
You see exactly which record changes.
Broader Compatibility
Works when automatic Domain Connect is unavailable.
Easier Infrastructure Documentation
Technical teams may prefer explicit DNS management.
Tradeoffs of Manual DNS
More Error-Prone
A wrong host or target breaks the connection.
Provider Interfaces Differ
One registrar may call the field:
Host
another:
Name
another:
Record Name
Understanding the concept matters more than memorizing screenshots.
Common Mistake 1: Connecting the Root Domain When It Already Hosts a Website
Use a subdomain when the original site should remain.
Common Mistake 2: Entering the Full URL in the DNS Host Field
For:
go.example.com
the Host usually needs only:
go.
Common Mistake 3: Creating Both A and CNAME for the Same Host
Use one supported approach for the hostname.
Common Mistake 4: Leaving Cloudflare Proxy Enabled
Set the applicable HighLevel record to DNS Only.
Common Mistake 5: Expecting Instant Propagation
DNS can take time.
Common Mistake 6: Forgetting the Default Page
A connected domain still needs the correct landing-page association.
Common Mistake 7: Forgetting to Publish
Save is not Publish.
Common Mistake 8: Deleting Email DNS Records
Do not remove unrelated MX/TXT records.
Common Mistake 9: Confusing Sites Domain With Email Domain
HighLevel uses separate domain types for different products.
Common Mistake 10: Ignoring WWW
Choose and test your preferred hostname.
Common Mistake 11: Panicking While SSL Is Provisioning
Give HighLevel time to issue the certificate after successful verification.
Common Mistake 12: Launching Without End-to-End Testing
Test forms, calendars and workflows.
Limitations of Connecting a Domain to HighLevel
Domain connection solves only the routing layer.
It does not automatically:
Build the Website
You still need content and pages.
Migrate SEO
Existing redirects and URL strategy need separate attention.
Configure Email Authentication
Email sending domains are separate.
Fix Poor DNS Architecture
Conflicting records still need troubleshooting.
Preserve Every Existing Service
You must understand what the hostname currently points to.
The domain is infrastructure.
It is not the entire website setup.
When a Root Domain Is the Best Choice
Choose the root when:
HighLevel hosts the primary website;
no old website needs to stay;
you want the cleanest visitor URL.
Example:
brand.com
When a Subdomain Is the Best Choice
Choose a subdomain when:
the main site exists elsewhere;
you're building a dedicated funnel;
you want campaign separation.
Example:
offers.brand.com
This is frequently the safest hybrid architecture.
A Practical Domain Setup Example
Business currently has:
example.com
running WordPress.
It needs a HighLevel funnel.
Step 1
Choose:
go.example.com
Step 2
In HighLevel:
Settings → Domains & URL Redirects → Connect a Domain
Step 3
Enter:
go.example.com
Step 4
Use Domain Connect or create the displayed CNAME.
Current manual guidance uses:
go → sites.ludicrous.cloud.
Step 5
Set Cloudflare to DNS Only if applicable.
Step 6
Wait for verification.
Step 7
Select the funnel.
Step 8
Select the default funnel step.
Step 9
Wait for SSL.
Step 10
Test:
https://go.example.com
The original WordPress site remains at:
example.com
Frequently Asked Questions About How To Connect A Domain In GoHighLevel
How do I connect a domain to GoHighLevel?
Go to the relevant sub-account, open Settings → Domains & URL Redirects → + Connect a domain, choose the Sites product, enter the root domain or subdomain, then use Domain Connect or configure the required DNS record manually. After verification, select the Funnel or Website and its default page.
Can I connect a root domain to HighLevel?
Yes. HighLevel supports root domains such as example.com for compatible Sites products. If the root already hosts another website you want to keep, HighLevel recommends using a subdomain instead.
Can I connect a subdomain to GoHighLevel?
Yes. Examples include www.example.com, offers.example.com or go.example.com.
What CNAME does HighLevel currently use?
HighLevel's current manual setup documentation lists sites.ludicrous.cloud as the CNAME target for supported subdomain connections. Always confirm the value shown in your current HighLevel setup flow before changing DNS.
What A record does HighLevel currently use?
HighLevel's current manual documentation lists 162.159.140.166 for the supported A-record method. Because infrastructure can change, use the value displayed in your current HighLevel account when available.
Should I use an A record or CNAME?
Use the method HighLevel provides for the hostname you are connecting. Do not create both an A record and CNAME for the same hostname.
What should I do if I use Cloudflare?
Set the applicable HighLevel DNS record to DNS Only, not Proxied, during the supported connection configuration.
How long does DNS propagation take?
It can occur quickly, but HighLevel notes that manual DNS changes can take up to approximately 24 hours to propagate in some cases.
Does HighLevel provide SSL?
Yes. HighLevel automatically begins provisioning SSL after the Sites domain is successfully connected and associated.
Can HighLevel connect the WWW version too?
Yes. When setting up a root domain, HighLevel can add the www version and configure a 301 redirect from www to the root domain.
Can I keep WordPress on the root domain and use HighLevel?
Yes. Keep WordPress on example.com and connect a subdomain such as go.example.com or offers.example.com to HighLevel.
Can I buy a domain through HighLevel?
Yes. Domains purchased through HighLevel can be managed through the platform's domain management environment and connected to supported Sites products.
Is a website domain the same as an email sending domain?
No. HighLevel separates Sites domains from email sending domains and other specialized domain types.
Why does my HighLevel domain show the wrong page?
Check the default-page association under the domain management settings. The domain may be connected correctly while pointing at the wrong Website page or Funnel step.
Why are my saved website changes not live?
HighLevel requires you to Publish website changes. Saving alone does not update the public website.
Conclusion
Learning How To Connect A Domain In GoHighLevel becomes much easier once you separate the process into three layers:
DNS
↓
HighLevel Domain Association
↓
Website / Funnel Publishing
First, decide whether HighLevel should use:
the root domain
such as:
example.com
or:
a subdomain
such as:
offers.example.com.
If the root domain already runs another website that needs to remain active, use a subdomain rather than overwriting the existing root-domain connection.
Next, start the connection from:
Sub-Account
↓
Settings
↓
Domains & URL Redirects
↓
+ Connect a domain
and select the appropriate Sites product.
From there, choose:
Domain Connect
for supported automatic setup.
or:
Manual DNS
for direct control.
Current manual HighLevel documentation uses a CNAME target of:
sites.ludicrous.cloud
for supported subdomains and documents:
162.159.140.166
for the A-record method.
If Cloudflare manages DNS, ensure the applicable HighLevel record is set to:
DNS Only
rather than Proxied.
Once HighLevel verifies the hostname, select the correct Website or Funnel and designate the page that should open at the root of that hostname.
HighLevel then begins provisioning SSL automatically.
Finally, publish and test.
A professional launch checklist should verify:
HTTPS
Root / WWW Behavior
Default Page
404 Page
Forms
Calendars
CRM
Workflows
The most common domain mistakes usually happen when someone skips the architectural decision at the beginning.
They connect:
example.com
without realizing it already powers WordPress.
Or they add:
www.example.com
into a DNS Host field that only expects:
www.
Or they leave Cloudflare proxy enabled.
Or they successfully connect DNS but forget to associate the correct default page.
The safer approach is:
Understand Existing Infrastructure
↓
Choose Root or Subdomain
↓
Connect Only the Required DNS Record
↓
Verify
↓
Associate Content
↓
Provision SSL
↓
Publish
↓
Test End to End
For a business moving entirely to HighLevel, the root domain can provide the cleanest structure.
For a business keeping WordPress, Shopify or another existing website, a dedicated subdomain can give HighLevel its own branded campaign environment without disrupting the main site.
The best domain configuration is therefore not simply the one that connects successfully.
It is the one that fits the wider website, email, SEO and customer-journey architecture without breaking the services that are already working.