How website projects work
When you create a website project, Huddlekit loads your site so your team can browse it and leave feedback, with nothing to install. This works well for most public websites, but a few sites can't be loaded this way.
When a site can't be loaded, you won't just get a blank screen. Instead, a short message appears where the site would be, telling you what happened and offering a Retry button.
Common reasons a site may not load
The site is temporarily unreachable
Sometimes a site's own server is slow, overloaded, or briefly down, or it returns an error of its own. This is usually temporary — wait a moment and use Retry.
The site is busy or limiting traffic
Very busy sites sometimes limit how often they respond to requests. If that happens, wait a minute and try again.
The site's security turned the request away
Some sites use security that mistakes Huddlekit for automated traffic and refuses the request. Nothing is wrong with the address. Huddlekit retries these automatically. If it keeps failing, ask whoever manages the site to allow traffic from Huddlekit — email support@huddlekit.com and we will send you the address to give them.
The site is behind a coming soon or maintenance page
If a maintenance or coming soon plugin is switched on, every page answers with the splash screen instead of the site. Huddlekit recognises the common plugins and tells you rather than letting people comment on the splash page. Use the plugin's bypass link or a site password — see Reviewing password-protected and pre-launch sites.
The site is password-protected
A site password is usually fine: enter it in the review view and Huddlekit remembers it, and basic auth credentials can go straight in the project URL, where anyone with access to the project, and any tool it's connected to, can see them. Reviewing password-protected and pre-launch sites covers which platforms this works on.
The site is behind a private login
Website projects work with pages that are publicly reachable. A site-wide password page is fine, as described above. A user account is not: Huddlekit does not keep an ordinary sign-in session between pages, so if a whole site or deployment sits behind a private account (for example, a staging deployment set to private), or the content you need to review only exists once a user is signed in, Huddlekit can't reach it. Publish it publicly, or use a Web App project instead — you install a small widget directly on your site, so it works inside authenticated areas.
The address is wrong
If you see a "page not found" message, double-check the address, or try reaching the page from the site's homepage.
What to try
- Use the Retry button on the message — many load problems are momentary.
- Check the address, or navigate to the page from the site's homepage.
- Wait a minute and retry if the site looks busy.
- Ask whoever manages the site to allow Huddlekit if its security is blocking the request.
- Switch to a Web App project for anything behind a private login. See Website vs. Web App.
If the site loads but looks wrong or out of date, that is a different problem — see The site looks wrong or out of date.
When website projects work best
Website projects are ideal for:
- Public marketing sites and landing pages
- Staging and preview URLs, including ones behind a site password or basic auth
- Sites you built yourself or control
If your site falls outside these cases, a Web App project is the right choice.