A CLEAR PUBLIC ADDRESS
Give your public website one clear home
Use the configured site address consistently and treat a custom domain as a verified release with working routing and certificates.
An address is part of the visitor experience
The domain in a search result, navigation link and shared page should lead to the same company website. Tsumira resolves one preferred public origin for a tenant and uses it in supported public metadata and links. A domain is operational infrastructure as well as branding. Registering it or adding a DNS record alone does not prove that the public website is already reachable at that address.
Keep one preferred public origin
The public host resolution selects the supported tenant address and can prefer a configured custom domain only when the relevant conditions are met. That origin informs canonical references and other generated public URLs. A consistent origin reduces contradictory signals between pages and their metadata. It does not by itself create redirects for every previous address, repair a misspelled external link or establish that a migration is complete.
- One preferred public origin
- Consistent canonical references
- Public links use the configured host
Verify the actual custom-domain release
A configured custom domain needs verified ownership, a ready certificate and an edge configuration that actually serves custom domains. These are distinct readiness conditions. Until they are satisfied, the domain must not be treated as an already working public replacement. Availability depends on the deployment and its supported provisioning. Check the real HTTPS response, the intended company site and relevant public pages before announcing a new address.
- Verified domain ownership
- Certificate and routing readiness
- Real HTTPS acceptance check
Plan a change as a route migration
When replacing an address, inventory important pages and the places that link to them. Check the new destinations, planned server redirects and canonical metadata as separate parts of the release. Include service pages, contact routes and supported public content families, rather than testing only the homepage. Keep operational app addresses and private capability links within their own routing and security requirements. A public website canonical is not authority to redirect every private application URL.
- Important public paths inventoried
- Redirects checked independently
- Private routing handled separately
A concrete workflow
Choose the intended address
Confirm the public origin and who controls the required domain configuration.
Prepare domain readiness
Complete the supported ownership, certificate and serving configuration.
Check representative routes
Verify the actual HTTPS site, links and supported public metadata.
Release and monitor
Announce the address after acceptance and check the migration’s intended redirects.
An illustrative working example
Example: moving an established website
A company prepares its new domain and keeps a list of high-value service and contact URLs. The release team verifies ownership, HTTPS serving and the company identity on the new host. It checks the old-to-new server redirects separately from canonical tags. Only after representative deep links work does the company update external profiles. This treats the migration as a concrete set of routes instead of assuming that a DNS change proves every destination works.
Questions about this topic
Does a DNS record make the custom domain live?
No. Ownership verification, certificate readiness and actual serving configuration also matter. Test the real HTTPS result.
Does a canonical tag redirect visitors?
No. A canonical reference and an HTTP redirect serve different purposes. Check the required redirect behavior separately.
Can every tenant enable a custom domain immediately?
Custom-domain availability depends on supported deployment and provisioning conditions. Do not assume a verified database entry alone establishes live service.
Should a domain migration include deep pages?
Yes. Test important service, contact and supported public content routes as well as the homepage, including their intended previous addresses.
Explore connections around this workflow.
Ideas for intended connections. Check the actual availability, permissions and supported data for each app before using a scenario.
Google Sheets
Workflow concept: Maintain old-to-new public URL mappings and record actual HTTPS and redirect acceptance results.
GitHub (App)
Workflow concept: Coordinate a reviewed infrastructure change for the intended host, certificate and redirect rules.
Microsoft Teams
Workflow concept: Run the domain release checklist with the people responsible for DNS, publication and customer communication.