A visitor opens your site's domain and sees a generic error page instead of your content. Use this article to check the most likely causes before you contact Support.
Scope
Use this article when visitors open your site's own domain and see a plain error page instead of your pages. It does not apply when a visitor reaches a specific page but cannot continue because the page requires sign-in or has an access policy; for that, see the articles on access denied pages and portal sign-in. It also does not apply when the Pages list in the Portals & Microsites console will not load for you as an administrator. That issue affects the console's page-management screen, and your published site can keep working normally for visitors while it happens.
1. The Site Is New and Has Not Been Set Up Fully Yet
A brand-new site does not automatically have a working map of its pages. Until you build that map, the site's domain has nothing to show visitors, so they land on the error page.
Check. Confirm whether the site was created recently, and whether someone has built its pages, menus, and site map.
Fix. Finish setting up the site. Create at least one page, then build or rebuild the site's map from the Maintenance screen. Ask a Portals administrator if you do not see that option.
Tip
Creating the site's domain is not enough on its own. Each page must also be published before visitors can see it, including pages that a feature installs automatically. On an event microsite, for example, the View My Registration page must be published before a registrant can open or change their own registration from the portal. If self-service changes seem to fail or hang, check whether that page, and the rest of the microsite's registration-related pages, have been published. A blank white page during event registration or email verification usually has the same cause: the specific portal or microsite page involved has not been published yet, including a page a visitor reaches only partway through impersonation.
If you just added a new domain to the site, give the change time to take effect before you test it. After you add the DNS record for a new portal domain, it can take hours to begin propagating and longer to reach every location. Testing right away can make a correctly configured domain look broken when it is simply still catching up.
2. The Site Has Been Taken Out of Service
When a site's Status is inactive, visitors are refused and sent to the error page. They do not see a separate message explaining that the site is off. A site also needs the correct domain pattern to load as expected. An event microsite, in particular, needs a public URL that uses its expected subdomain pattern, so an active microsite with the wrong domain pattern can still fail to open normally.
Check. Open the site's record under Setup › Sites and check its status and domain name.
Fix. Switch the site back to active if visitors should be able to reach it, and correct the domain if it does not match the expected pattern for that kind of site. The change publishes automatically, so there is no separate step to bring the domain back online.
Warning
Changing a site's status affects every visitor as soon as the change is published, and Rhythm does not ask for confirmation before taking a site offline. Double-check that you selected the right site before you change its status.
Tip
If you want visitors to see a maintenance message instead of the generic error page while you work on a site, you do not have to take the site offline. You can temporarily change the route of your current home page, create or duplicate a page at that address to use as an under-construction notice, and assign a new, blank menu as the site's default menu. Visitors then land on the maintenance page without navigable menu items.
If visitors still reach the site on a custom domain after you deactivate it or end your Rhythm account, the cause is usually outside Rhythm. Rhythm refuses to serve a site once it is inactive, but a custom domain you set up yourself still depends on your own DNS records. After your account relationship ends, Rhythm no longer controls that domain or any separate hosting behind it. If visitors should stop reaching a portal on a custom domain for good, work with your domain registrar or hosting provider to remove the DNS records or site files for that address.
If you recently restored a site that had been disabled, some visitors may keep seeing the disabled-site error for a short time even though the site is active again. Their browser is still showing cached content from before the change. A private or incognito window, or clearing the browser's cache, usually clears it.
3. Something Else Went Wrong While the Site Was Loading
The same error page also appears when another step fails while the site is loading, such as when the site's basic identity information cannot be read. The page does not give visitors, or you, a specific reason to act on; it is a general "something failed" screen. The wording on the error page is fixed, so you cannot edit it from your account's settings. If you notice incorrect text on the page, contact Support. That change is an internal correction, not a self-service one, the same as any other fixed, template-managed portal text.
Check. Try reloading the page after a few minutes. Then open the domain in a private or incognito browser window, in case your browser has saved an out-of-date version. Clearing the browser's cache and testing in a supported browser such as Chrome or Firefox resolves many one-off loading problems, including a registration page that fails partway through instead of never loading at all.
Fix. If reloading does not help, and the site is active with pages and a site map, there is nothing else to check from the Console. Contact Support.
Tip
If the portal opens slowly rather than failing outright, the delay has sometimes been traced to a background lookup the portal makes to an external location-detection service during start-up. That lookup runs without blocking the rest of the page, so it should not stop the site from loading. It should only affect how quickly the site feels ready.
If the error page, or a similar loading failure, appears in more than one place at once, the cause is more likely to be portal-wide than tied to one form or page. For example, a failure during sign-in, during impersonation, and on an unrelated registration form points to a broader problem. Treat a problem seen in several unrelated areas as more likely to need Support's help than something you can fix by editing one page. Similarly, broad loading errors across many parts of a portal at once have sometimes been traced to a problem in a script used for bot protection on the site, rather than to anything in your own setup.
A page that stays on a loading message and never finishes can also be caused by the page's own customization rather than a site-wide failure. Mismatched conditional tags in a page's template code, such as an extra closing brace or a missing closing tag for each conditional block, can leave a page stuck loading indefinitely. Check any custom template logic on the specific page before assuming the whole site is affected. Similarly, if you install a feature such as Presenter Center on an event microsite without also installing the feature it depends on, Abstracts, on that event, the affected page can stay on a loading message and show an error instead of telling you the dependency is missing. Installing the missing dependency is the fix.
Occasionally, a loading failure appears as a technical parsing error in the browser instead of the plain error page. For example, a request for one of the site's internal configuration files may unexpectedly return page content instead of the data it expected. This points to the same kind of start-up or configuration problem as the rest of this section, so the checks above still apply. A similar technical error can also appear when the address of a microsite itself is misconfigured. Correcting the site's configuration, not its content, resolves it.
On an event microsite, if the Schedule page stays in a loading loop instead of showing sessions, check whether the site's public schedule address is returning an access error from its data source. That points to the same page needing attention, rather than a site-wide problem.
If you cannot reproduce a loading problem yourself, but it happens consistently for certain visitors, ask which browser and version they are using. Comparing browser versions between someone who can load the site and someone who cannot is a useful way to narrow down an inconsistent loading problem before you contact Support.
A browser's saved state explains more loading problems than it gets credit for. If a visitor's sign-in fails with no clear reason, have them try a different browser, clear their browser's cache, or sign in from an incognito or private window. That often works immediately, even before you identify the underlying cause. The same incognito check helps when content on a page does not appear for one visitor. A browser extension or cached browser state can be responsible, and testing in a private window with extensions disabled helps confirm it. If you, or Support, can open a site without trouble while a visitor or customer cannot, from the same browser and account, cached browser content or the timing of a recent change reaching different locations is a likely explanation. Ask the affected person to clear their cache and try again after a short wait before escalating further. As temporary checks only, disconnecting from a VPN, making sure cookies and JavaScript are both allowed, and retrying in an incognito window can all reduce how often a visitor is blocked by the portal's automated security checks while loading a page. None of these steps fixes the underlying cause, so keep troubleshooting if the problem returns.
4. The Domain Itself Will Not Resolve
A browser message such as "this site can't be reached" is different from the Rhythm error page described above. It means the visitor's browser could not find an address to connect to. That points to a domain name system (DNS) problem outside Rhythm, not to anything inside the site or its microsite setup.
Check. Before you recreate or clone the affected site or event, confirm whether the domain's DNS is actually set up and resolving. Cloning or recreating a site does not help when the real problem is a missing or incorrect DNS mapping for the domain.
Fix. Correct or add the missing DNS record with whoever manages your domain, then allow time for it to propagate before testing again.
Tip
If a portal is live and correctly configured but fails to open only on one specific office or home network, the likely cause is stale DNS data cached on that device, its router, or a local network resolver, not a missing DNS record. Flushing the local DNS cache on the affected computer, temporarily switching that device to a public DNS resolver such as Google's or Cloudflare's, or rebooting the router if you control it, can confirm and work around the issue without waiting for every network to catch up.
5. The Wrong Site Loads, or a Custom Domain Points Somewhere Unexpected
Sometimes a domain resolves and a site loads, but it is not the site you expected. A few different causes produce this symptom:
- You may be testing the wrong address. Before you assume a microsite is broken, confirm that you are opening the exact generated microsite domain and not a similar-looking address. A blank or unreachable page is sometimes simply the result of testing the wrong URL.
- A domain can keep pointing at the wrong site even when your records look correct. The step that turns a visitor's domain into the right published site is separate from the site's own record, so the two can fall out of sync. A custom domain shared across events from year to year can keep resolving to a prior year's deactivated microsite instead of the current one, even after you update the domain on the current site's record and everything else about the site — its event, settings, and menus — is correct. If updating the domain in the site's own settings does not change what visitors see, contact Support. This can require a correction on Rhythm's side that is not available through the normal site or hosting settings.
- The site's domain configuration can simply be wrong, even when every page on the intended site is published. If a microsite seems broken, check its domain setting before assuming the problem is with its pages.
- Browser or cached content can show the previous site for a while. After you reassign which event a microsite's domain points to, visitors, including you, may keep seeing the previous event until cached content clears. A private or incognito window, or clearing the browser's cache, usually resolves it.
6. A VPN or Network Connection Is Interfering
Some loading and submission failures have been linked to the visitor's network connection rather than to the site itself. This includes a web form that fails to initialize with a message such as "Unable to Initialize Web Form" (sometimes shown as an HTTP 0, "Unknown Error") or a similar generic communication error during checkout, event registration, or membership renewal. A visitor connecting through a VPN, or through a network that shares a public address with many other users, such as a large shared NAT connection, is more likely to see this kind of error. A stale browser cache can produce the same symptom on its own, without any VPN involved.
Check. Ask the affected visitor whether they are using a VPN. Have them disconnect it, sign out and back in, and try again. If that does not help, ask them to clear their browser's cache and try a different device that has not been connected to the same VPN, since network conditions can be remembered for a session.
Fix. There is no account setting that resolves this; it is tied to the visitor's network path or browser state. Disconnecting from a VPN, clearing the browser's cache, or trying a different network or device is the most reliable workaround. Some generic initialization and communication errors like these have also been traced to a defect on Rhythm's side rather than to anything in your account's configuration. If VPN, cache, and network checks do not explain the problem, it is reasonable to ask Support to investigate instead of trying to fix it locally.
When to Contact Support
Contact Support when the site is active, has at least one published page and a rebuilt site map, and visitors still land on the error page. Include:
- the site's domain name and the specific site record;
- whether the problem happens for every visitor or only some;
- the approximate time a visitor saw the error page.
Whether the problem affects every visitor or just one is useful information, not only something to report. A problem that affects every visitor points more toward the site's setup or a broader platform issue. A problem that affects only one visitor makes that visitor's account, device, or network more likely, so start your own checks there.
If your site appears to be down, contact Support before you make website maintenance changes on your own. Support can confirm whether a maintenance step is the right response before you make changes that may not address the real cause.
If other things are also failing around the same time, such as signing in, making purchases, event registration, or specific areas of the Console, that pattern suggests a broader, temporary service issue rather than a problem limited to your site. Mention that pattern when you contact Support.
Related
See also Create, Edit, and Delete a Site, Rebuild a Site Map, and Portal Hosting Explained, listed under this application's other articles.