Custom Domains and Canonical URLs in a Multi-Tenant Platform
Every website on our platform starts with an address on a platform domain, built from the organization's name. Many organizations later connect their own domain, such as their company or church name. During and after that change, the same page may be reachable at more than one address.
Search engines do not like duplicates. If two addresses show the same page, they have to guess which one to index, and the page's reputation can be split between them. So our platform decides on a single preferred address for each website and uses it consistently. Here is how.
Canonical links name the preferred address
Every page includes a canonical link: a line in the page's code that tells search engines which address is the preferred version. Our platform builds that link from the website's preferred address, not simply from whatever address the visitor happened to use.
That means a visitor who reaches a page through the platform address still sees a canonical link pointing at the organization's own domain once it is connected and verified. Search engines learn which address to prefer.
A domain becomes preferred when it is verified
A custom domain does not become the preferred address the moment someone types it into a settings field. It becomes preferred when it is verified, its setup is complete and it is active. Until then, the platform address remains preferred, because pointing search engines at a domain that does not yet work would send visitors to errors.
When the domain becomes active, canonical links, sitemaps and other address-dependent files switch to it automatically. Nobody has to remember to update them.
Sitemaps and robots files follow
The sitemap lists every page using the preferred address. Files that include full addresses, such as robots.txt and llms.txt, are generated for the address in use and cached separately for each host, so a visitor on the custom domain never receives a file that lists the platform address. We describe that caching detail in why every cache key includes the customer.
Moving domains keeps paths intact
When addresses change on a larger scale, such as when our own platform moved to new domains, old addresses redirect permanently to the new ones with their paths and query strings kept intact. A link to a specific page on the old domain lands on the same page on the new one, rather than on a home page. Stateful paths, such as sign-in and payment callbacks, are moved carefully and only after their new addresses are registered with the services that call them.
Each website binds its own domain
In accounts with several websites, each domain is bound to a specific website, so visitors see the right site. Binding a domain does not move content, change another site's settings or alter email routing. Those are separate decisions with their own safeguards. You can read more in supporting several websites under one account.
Before a domain moves
When a website is being rebuilt before taking over an existing domain that is still live elsewhere, its pages may be marked not to be indexed for a while. That prevents the new version on the platform address from competing with the old site still running on the domain. Once the domain points to the new site, those pages can be opened to search engines, and canonical links already point at the right place.
DNS changes are careful
Connecting a domain usually involves changes to its DNS records. DNS also controls email, so careless changes can break an organization's mail. We capture the existing records before changing anything, change only what the website needs and leave mail routing alone unless that is explicitly part of the work.
Frequently asked questions
What is a canonical URL?
A canonical URL is the preferred address for a page, declared in the page's code so search engines know which version to index when several addresses show the same content.
Will my old platform address still work after I connect my domain?
Pages remain reachable, but canonical links and sitemaps point to your verified custom domain so search engines prefer it.
Does connecting a domain affect my email?
It should not. Website DNS changes can be made without changing email records, and existing records should be captured before any change.
Related Posts
Brand Colors as Tokens: Keeping Every Customer's Brand Intact
Every organization on our platform has its own look. Here is how theme tokens let each site keep its brand while sharing the same building blocks underneath.
What We Do for AI Search Visibility, and What We Do Not
Everyone wants to be cited by AI assistants. Here is what genuinely helps, from crawlable pages to truthful structured data, and the tricks we refuse to use.
Background Jobs That Remember Whose Work They Are Doing
Slow work like sending email or resizing images happens in the background, long after the request ends. Here is how our jobs carry the right customer with them.
Letting Customers Get Paid Directly With Connected Accounts
When an organization sells through our platform, the money should land in its own account. Here is how connected accounts, platform fees, refunds and disputes work.
Why Our Website Importers Never Hotlink Your Files
When a website moves to our platform, every image, font and file comes with it. Here is why we never leave a page depending on the old host, and how we prove it.
Comments (0)
No comments yet. Be the first to share your thoughts!