Every site builder tells you the same thing: "connect your custom domain and you're done." We believed that too, until we actually checked what happens technically when a site built on a shared platform gets its own domain connected — and found something that most site builders either can't fix, or leave as an easy-to-skip setting.
What actually happens when you "connect your domain"
When a business builds a site on a platform like ours (or Wix, Squarespace, Webflow, GoHighLevel), it initially lives at a subdomain of the platform's own domain — something like yourbusiness.oursitebuilder.com. When they connect their own domain, the expectation is simple: now yourbusiness.com is "the" site.
Here's what most people don't realize: the old subdomain doesn't go away. It keeps serving the exact same content, indefinitely, at its own separate address. You now have two live URLs showing identical content to Google — which is the textbook definition of a duplicate-content problem.
We checked how the major platforms actually handle this
Rather than assume, we looked at what real site builders actually do:
- Squarespace sets a canonical tag pointing to your custom domain — a good instinct — but their own documentation confirms you cannot disable or forward the built-in subdomain at all. Real-world consequence, also documented: those subdomain URLs keep turning up in Google search results anyway, diluting SEO and confusing visitors who land on the wrong address.
- Wix recommends manually setting your custom domain as "primary" to reduce the confusion — a real setting, but one the site owner has to remember to configure.
- Webflow actually gets this right with a genuine server-side 301 redirect — but only if you remember to set a "default domain." Their own help docs warn that skipping this step causes real SEO and crawling problems.
- GoHighLevel — the funnel-builder platform much of the site-builder world (including a lot of what this space is modeled on) is built around — has the exact same gap, and it's documented well enough that third-party agencies have written entire guides about it: funnels start on a shared platform subdomain, and when a custom domain is connected, "the [subdomain] version often stays indexed... every backlink and ranking signal is split between two URLs." GHL's own support docs walk you through setting up your own 301 redirects manually afterward — it isn't automatic.
The pattern: nobody does this automatically, invisibly, by default. It's either impossible to fully fix (Squarespace), or it's on the business owner to remember a setting most people have never heard of (Wix, Webflow), or it's a known enough problem that there's a cottage industry of guides written just to help people work around it after the fact (GoHighLevel).
Why a canonical tag isn't enough
A canonical tag is a hint, not an instruction. Google generally respects it well, but:
- It doesn't pass along link equity. If anyone bookmarked or linked to the old subdomain URL before the domain switch, a canonical tag doesn't transfer that value to the new domain — only a real redirect does.
- Not every crawler weighs it as reliably as Google does — including some of the AI crawlers we wrote about in our last post.
- It relies on the duplicate page staying live and getting re-crawled before Google fully sorts out which version is "real" — which can take time, during which both versions can appear in search results.
What we built instead
Once a business's custom domain is verified — not just entered, but confirmed via DNS — every request to their old subdomain now automatically redirects with a real server-side 301, permanently, to the same page on their real domain. No setting to remember, no opt-in, no dashboard toggle to forget. It's the default behavior the moment DNS verification succeeds.
We deliberately gated this on verification, not just entering a domain — the subdomain has to stay reachable during the DNS propagation window before the custom domain is actually live, or we'd strand real visitors mid-setup.
The takeaway
"Connect your domain" sounds like a complete step. On most platforms, it's actually the start of a second, invisible problem that either can't be fixed or depends on the business owner finding and flipping a setting they don't know exists. We'd rather it just be handled — permanently, automatically, the moment your domain is verified.