This is one of the more disorienting support tickets a website owner can raise, because everything on their side is correct. The snippet is in the template. It works on their laptop, on their phone, and for everyone in the office. And yet a customer emails to say there is no chat button on the page, sends a screenshot proving it, and no amount of re-pasting the code changes anything.
The install is not the problem. Something between your page and the visitor is stopping the widget from loading, and it is almost always one of four things: an extension in the visitor's browser, the browser's own tracking protection, a network that filters by domain, or a security header on your own site. Each has a different fix, and one of them is not fixable at all. Knowing which you are looking at saves a great deal of wasted effort.
A chat widget is third-party JavaScript. It is fetched from the vendor's domain rather than yours, which is exactly the shape that content blockers are built to stop. Filter lists do not evaluate whether a script is useful or invasive; they match patterns, and a script served from a chat vendor's host matches a great many of them.
Ad blockers and privacy extensions are the largest single cause. The popular lists include categories for widgets, live chat and customer-support tooling, and a visitor who enabled a broad list years ago has no idea they are blocking anything. Browsers with tracking protection turned up to its strictest setting do something similar without any extension installed. In both cases the request for the widget script never leaves the browser, so nothing appears and nothing errors in a way the visitor would notice.
The second cause is the network rather than the browser. Corporate proxies, school filters and some public wifi block whole domains by category, and support or chat tooling is a common category to block. A visitor on a locked-down work laptop can load your site perfectly and still never reach the widget host.
The third cause is on your side, and it is the only one you fully control.
Content Security Policy is the one you control
If your site sends a Content-Security-Policy header, it decides which hosts the browser is allowed to fetch from. A policy written before you added chat will block the widget for absolutely everyone, which at least makes it easy to spot. The subtler failure is a policy that allows the script but not the styling, so the widget loads, mounts, and renders as a stack of unstyled elements or nothing visible at all.
The rule worth remembering is that a chat widget usually needs more than one directive. It needs to be allowed as a script source so the code can run, and as a style source so it can present itself. Allowing only the first produces a bug report that reads like a layout problem rather than a security one, which sends people looking in the wrong place for a long time.
Two related mistakes belong here. If your page is served over HTTPS and your snippet references the widget over plain HTTP, the browser will refuse the request as mixed content and the button will simply not appear. And if the widget renders inline on your page rather than inside an isolated frame, your own stylesheet can reach it, so a broad rule in your CSS can restyle or hide parts of it without anything being blocked at all.
How to tell whether this is happening to you
The awkward part of this problem is that the visitors it affects are invisible. They never open a conversation, so they never appear in your chat reporting, and no error is logged anywhere you would look. You cannot count them directly. You can, however, get close enough to act.
Start by reproducing it rather than theorising. Open your site in a browser with a mainstream content blocker enabled and see whether the button appears. Repeat in a browser with tracking protection set to its strictest mode. If either kills the widget, you have your answer, and you now know it applies to a real share of the general public rather than a handful of unusual people.
Next, check the browser console and the network panel on a page where the widget is missing. A blocked request looks different from a failed one: the request is refused before it is made, and a Content Security Policy refusal names the directive it violated, which tells you exactly what to add. That single line is usually the whole diagnosis.
Finally, compare orders of magnitude. If your analytics say a page gets several thousand sessions a week and your chat has produced a handful of conversations from it since launch, the gap is worth investigating rather than accepting.
What to do about it, in order
Fix your own header first, because it is the only cause with a complete fix. Add the widget host to the script and style directives, deploy, and confirm on a page you know was failing. This one change resolves the majority of reports that reach a vendor as the widget does not load.
Then make sure the snippet is served over the same scheme as your site, and that nothing in your own stylesheet is hiding or resizing the widget. These are quick to check and account for most of what remains.
After that, accept the limit. You cannot defeat a visitor's content blocker, and it would be a bad idea to try. Techniques that exist to evade filter lists get the vendor added to more filter lists, break for everyone, and treat a deliberate choice by the visitor as an obstacle. The honest response is to make sure a blocked visitor still has a way to reach you.
That means a plain contact route that does not depend on any third-party script: a real email address in your footer, or a form served from your own domain. It costs nothing, it works for the visitors you cannot see, and it is worth having regardless of whether anyone is blocking anything.
How MyLiveChat fits
The MyLiveChat snippet is a single script tag that loads asynchronously and sits at the end of the page, so it is off the critical path for rendering. That is a property of the snippet itself rather than a claim about your page speed, and you can read it in the code you paste.
Because it is served from a MyLiveChat host, everything above applies: a Content Security Policy on your site needs that host permitted as both a script source and a style source, and a visitor running a content blocker may filter it exactly as they would filter any third-party widget. The appearance settings control how the widget looks once it has loaded, which is a different question from whether it loaded at all, and the two get confused often enough to be worth separating.
If you are checking a fresh install rather than chasing a partial one, the setup guide below covers the ordinary reasons a widget does not appear on any browser, which is a different diagnosis from the one on this page.
What to measure
- Chat opens as a share of sessions on your highest-traffic page. You are not looking for a benchmark, you are looking for a number that is implausibly low for the traffic, which is the only signal a blocked widget leaves behind.
- Whether the widget survives a strict-privacy browser. Check it after every redesign, not once at launch. This is a two-minute test that catches a header change nobody told you about.
- Console errors on a page where the button is missing. A policy refusal names the directive it blocked, which converts a vague report into a one-line fix.
- Contacts arriving by your non-script route. If the email address in your footer is producing a steady trickle of questions that read like chat questions, some of your visitors are working around something.