Each time your portal loads, Rhythm first identifies which association’s site the visitor opened. It then loads that site’s settings and pages, and gives each page an address the browser can visit.
Finding Your Site from the Domain Name
The portal is one shared application that serves every association’s site. When someone opens a domain, Rhythm looks for the identity file published for that exact host name. If that file is missing because the domain was never set up or was renamed, the visitor sees the portal error page instead of your site. The host name must match your site’s stored domain name exactly, so a similar address will not find it.
Rhythm does not remove the identity file for a domain you stopped using. If you renamed your site’s primary domain, the old address may still open your portal even though you no longer share it.
Changing your portal’s domain name involves more than one place, and those changes usually need to happen together. Update your sign-in provider’s login URI for the new host, create the DNS CNAME record that points the new host to your portal, and then update your site’s settings to use the new domain name. Put the DNS record in place before you rely on the new domain in your site settings, because Rhythm can find your site’s identity file only after the new host name resolves.
Tip
This article explains how Rhythm finds and serves a site it hosts directly. If your organization also shows Rhythm directory data through an externally built site, such as one built on a separate content platform, that site is separate from your Rhythm portal. The two are tested independently. If directory results look different there or come back empty, the external site is the more likely cause, not your underlying Rhythm directory data.
What Loads Before the First Page Appears
After Rhythm finds the identity file, it loads the pieces the rest of the visit depends on:
- Which association this is. Rhythm ties every later request from the visitor to the association named in the identity file, because the browser has no other source for that information.
- How sign-in works for this site. The identity file also includes the settings for your site’s sign-in client. The visitor’s browser keeps those settings by domain and replaces them on each ordinary visit, so a sign-in configuration change takes effect the next time someone visits, not necessarily during the same visit.
Warning
Because sign-in and site settings are tied to the exact domain the visitor opened, embedding a Rhythm portal or event microsite page in an iframe on another site is not supported. Browser privacy controls increasingly restrict cross-site cookies and storage, especially in Safari on desktop and iOS. Rhythm does not recommend embedding portal pages this way.
- The site map and the asset map. These files list every page, menu, and shared asset your site uses. Rhythm fetches them once when the portal first loads and always asks for a fresh copy. If someone is already browsing when you publish a page or menu, they will not see it until they reload.
- Your site's settings. Branding, header and footer markup, scripts, and similar site-wide options also load once per visit. If your site map names a settings file that no longer exists, the site cannot open.
- A route for every page. Rhythm gives every page in the site map its own address during start-up. If two pages use the same route, only the first one in the site map responds at that address.
- Your currency options and account's feature switches. Rhythm sets these up after it knows which Rhythm account the site belongs to and before the first page appears. See Currency Mapping Policies and Visitor Currency Explained for how a visitor’s starting currency is chosen.
- Your own custom portal components. If your association added custom portal web components, Rhythm loads them for your Rhythm account at this point. Components meant only for the Console never load into a portal page. If a component fails to load, nothing appears to the visitor.
Rhythm completes this start-up work before it shows the first portal page. It identifies the site, loads the settings and page list, and turns each page into an address the browser can use.
Finding Your Site from the Domain Name
The portal serves every association’s site from one shared application. When a visitor’s browser requests a domain, Rhythm looks for the identity file published for that exact host name. If that domain has no identity file because it was never set up or was renamed, the visitor sees the portal error page instead of site content. The host name must match your site’s stored domain name exactly, because a close but different address will not find it.
Rhythm does not remove the identity file for a domain you stopped using. If you renamed your site’s primary domain, the old address may still open your portal even though you no longer advertise it.
What Loads Before the First Page Appears
Once Rhythm finds the identity file, it uses that file to set up everything the rest of the visit depends on:
- Which association this is. Rhythm ties every later request from the visitor to the association named in the identity file, because the browser has no other source for this.
- How sign-in works for this site. The identity file also includes the settings for your site’s sign-in client. The visitor’s browser keeps those settings by domain and replaces them on each ordinary visit, so a sign-in configuration change takes effect the next time someone visits, not necessarily during the same visit.
- The site map and the asset map. These files list every page, menu, and shared asset your site uses. Rhythm fetches them once when the portal first loads and always asks for a fresh copy. If someone is already browsing when you publish a page or menu, they will not see it until they reload.
- Your site's settings. Branding, header and footer markup, scripts, and similar site-wide options also load once per visit. If your site map names a settings file that no longer exists, the site cannot open.
- A route for every page. Rhythm gives every page in the site map its own address during start-up. If two pages use the same route, only the first one in the site map responds at that address.
- Your currency options and account's feature switches. Rhythm sets these up after it knows which Rhythm account the site belongs to and before the first page appears. See Currency Mapping Policies and Visitor Currency Explained for how a visitor’s starting currency is chosen.
- Your own custom portal components. If your association added custom portal web components, Rhythm loads them for your Rhythm account at this point. Components meant only for the Console never load into a portal page. If a component fails to load, nothing appears to the visitor.
flowchart TD
A[Visitor opens your domain] --> B[Rhythm finds the identity file for that domain]
B --> C[Site map and asset map load]
C --> D[Site settings load]
D --> E[Routes registered for every page]
E --> F[Currency, feature switches, and custom components set up]
F --> G[First page is drawn]
B -- no identity file, or any step fails --> H[Portal error page]
Menus work the same way as pages. A menu loads only after it has been published and appears in the site map. If the menu your site uses as its default has never been published, that default menu will fail to load even when the rest of the site works. See How a Site Map Keeps Pages Reachable for how the site map stays in step with what staff publish, and Pages and Menus Explained and Assets, Kinds, and Folders Explained for what pages, menus, and shared assets are.
What Search Engines See
Search engines look for a small file at /robots.txt before they crawl a site, so they know which addresses they may index. Today, Portals has no setting for customizing this file for your site. That means there is no Console control for keeping specific pages, such as sign-in or account pages, out of search results.
When Start-Up Fails
If any start-up step fails, the visitor sees a generic error page instead of your site. That includes an unknown domain, a site that has been switched off, a missing site map, or missing settings. The error page gives very little detail. It shows only a plain heading saying an error occurred, with no link, no retry button, and no way to contact anyone from the page. If members report seeing a generic error page instead of your portal, check whether your site is switched on and whether its settings and site map are in place.
If a page with a defined address does not load correctly, even though the address and navigation look right, open the page in the page designer and save it again. In some cases, saving the page again has resolved the problem.
Menus work the same way as pages. A menu can load only after it has been published and is listed in the site map. If the menu your site names as its default has never been published, that default menu will fail to load even though everything else works. See How a Site Map Keeps Pages Reachable for how the site map stays in step with what staff publish, and Pages and Menus Explained and Assets, Kinds, and Folders Explained for what pages, menus, and shared assets are.
What Search Engines See
Search engines look for a small file at /robots.txt before crawling a site, so they know which addresses they may index. Today, Portals offers no setting that lets you customize this file for your site, so there is no Console control for keeping specific pages, such as sign-in or account pages, out of search results.
When Start-Up Fails
If any one of the steps above fails, the visitor goes to a generic error page instead of any part of your site. That includes an unknown domain, a site that has been switched off, a missing site map, or missing settings. The error page gives very little detail. It shows only a plain heading saying an error occurred, with no link, no retry button, and no way to contact anyone from the page itself. If your members report seeing a generic error page instead of your portal, treat it as a sign that one of the steps above could not complete. Then check whether your site is switched on and whether its settings and site map are in place.