Binding a custom domain adds a branded hostname to the same published Buda Site. The current bind operation does not delete the original Buda public URL or automatically configure a 301 redirect from it. “Primary public URL” therefore does not mean that old links necessarily redirect. While the Site remains published, both addresses would normally reach it, but before announcing a switch, open the old and new homepages and a deep link in a private browser window and record whether each loads, redirects or fails.
For a site with login or forms, check OAuth/login callback and redirect URLs, cookie domains, allowed origins (CORS/CSRF), form actions, absolute asset links and old hostnames in emails. Browsers treat the two domains as different origins, so an old login session may not carry across. If you want one canonical branded address, configure and test an explicit old-to-new redirect at the site/routing layer; do not assume domain binding did it for you. Keep the old URL monitored during transition so already-shared links do not break unexpectedly.
The custom domain guide covers DNS and binding. Is your login built into the app or handled by a third-party identity provider? The Chinese discussion covers the same checks.