Which sites are controlled, and which pages are not controlled at all

The launcher appears during checkout, on an internal page, on a staging copy, or on a site you did not knowingly install it on.

In rough order of how often each one turns out to be the answer. Work down rather than across: each carries a way to tell whether it is yours before you change anything.

• 1

  The allowlist is empty, which permits every site

  Why

  An assistant with no origins listed accepts all of them, so that a new install works the moment the tag is pasted and nobody has to configure their way to a first launcher. The cost of that is that a tag copied off your page works anywhere it is pasted, for as long as the list stays empty.

  How to confirm it is this one

  Open the Install tab and look at Allowed origins. An empty list is shown with a warning badge saying the widget will refuse to load, which is the opposite of what actually happens, so read the list rather than the badge.

  Fix

  Add the sites it belongs on. The moment there is one entry the check starts biting and everything not listed is refused, which is why adding the first entry is worth doing on the day you install rather than later.

• 2

  The tag is in a template that renders on more pages than you meant

  Why

  A footer partial or a base layout renders on every page built from it, and that usually includes the pages nobody thinks about: checkout, account, order confirmation, the print stylesheet version. The tag is doing exactly what it was put there to do.

  How to confirm it is this one

  View source on a page it should not be on and search the delivered document for w.js. Finding it there tells you the template rendered it, and where in the document it sits usually tells you which template.

  Fix

  Move the tag to a template covering only the pages you want, or wrap it in whatever condition your platform offers. This is work on your side and there is no setting here that can do it for you.

• 3

  A tag manager is firing it with no page condition

  Why

  A tag placed in a manager runs wherever the manager's container runs, and the container is usually on every page. Nothing about the widget knows it arrived that way, and it behaves identically.

  How to confirm it is this one

  View source and the tag will not be in the delivered document, because the manager writes it in after the page loads. Look in the inspector instead, where it will be present, and then look in the manager for the trigger. A tag firing on all pages is the answer.

  Fix

  Give it a page condition in the manager, or move it into the template where the condition is easier to reason about. Do not do both, because two copies of the tag on one page produce one launcher and a great deal of confusion later.

• 4

  A staging or preview origin is still on the list from setup

  Why

  Preview deployments and staging hosts are separate origins and get added during setup so that testing works. They then stay on the list, and the widget keeps loading in front of everyone who uses those environments.

  How to confirm it is this one

  Read the Allowed origins list against the addresses you actually publish. Anything on it that is not a public address of yours is this cause, and it is usually obvious at a glance.

  Fix

  Remove them, and accept that the widget will not render on staging afterwards. If you need it there permanently, a separate assistant with its own key keeps staging conversations out of your real ones.

• 5

  It is the other assistant's key

  Why

  Two assistants means two keys, and a key pasted into the wrong template puts the wrong assistant, with the wrong material and the wrong greeting, in front of the wrong visitors. It renders perfectly, which is what makes it hard to spot.

  How to confirm it is this one

  View source, read the data-key, and compare it against the Install tab of each assistant in turn. The one that matches is the one answering there.

  Fix

  Swap the key. Worth checking every site you run at the same time, because this mistake tends to come in pairs.

There is one page level lever and it lives on your side rather than in the settings. The loader leaves a small control on the page under the name ChatWidget, carrying open, close, toggle and destroy, and calling destroy removes the widget for the rest of that page load. Running that on the pages you want it gone from is the only path aware answer there is, and it is what the dashboard's own preview uses to tidy up after itself.

Can I allow a site but exclude one section of it?

Not from the allowlist, because a path is not part of what it compares and adding one would be silently ignored rather than honoured. Exclude it where the tag is rendered, or remove the widget on those pages with the control above.

Somebody has our tag on their own site. What stops them?

The allowlist, once it has an entry. The key in the tag is an identifier rather than a credential and is public by design, so the list is what stops it working somewhere its owner does not control. An empty list is the only state where nothing stops it.

Does the widget load on my dashboard without being listed?

Yes, deliberately. Previewing your own assistant in your own console is not what the list is guarding against, and making people allowlist the dashboard before they could try the thing they had just built would be a tax with no benefit.