Hotjar will work best on websites that are publicly accessible. If a website is restricted in some way, Hotjar may be unable to access the CSS and other assets of the site. Some examples of sites that are not publicly accessible include:
- Testing server
- Staging server
- Development server
Tips for Running Hotjar on Publicly Inaccessible Servers
In order to have Hotjar run correctly on your publicly inaccessible server or intranet, we suggest that:
- Your site can be connected to from our servers. Having your site publicly available and not behind a firewall is best. If your site is restricted in some way, Hotjar’s IP addresses must be allowed and have access to assets (like images, fonts and CSS files) from the site.
- Your site needs to use valid HTTPS certificates if it uses HTTPS. We cannot guarantee self-certifications will allow our tracking code to work correctly.
- The computer you are using to view your data also needs to have access to your site. All elements will need to be accessible to the person viewing the Recording to show correctly.
It is important to mention again that even by following the above tips, Hotjar may not run on your intranet or private server.
A Few Exceptions
Heatmaps & Incoming Feedback
Heatmaps and Incoming Feedback rely on the images and CSS files being publicly available, while HTML is collected and sent back to Hotjar directly from the user's device.
When we take the screenshot for your Heatmap or Incoming Feedback screenshot, CSS and image files are loaded directly from your server.
When we collect a Recording, we attempt to store the CSS files on our side if they are accessible. If they are not accessible, we will attempt to load them directly from your server. This does mean that it is possible to view Recordings if the local device has access to these assets.
For example, if your assets are available locally at my-intranet.local, and you are using a device that is connected to your intranet, you will generally be able to playback a Recording without issue.