Troubleshooting Widget Not Loading or Displaying
Last updated: September 29, 2026
If the Docket widget is not showing up, the fastest way to narrow it down is to answer one question first: has it ever worked on this page?
A widget that has never appeared is almost always a setup step that has not happened yet. A widget that used to work and then stopped is usually something on the page or the network blocking the script. The two need different checks, so start in the right place.
The widget has never worked here. What should you check?
Work through these in order. Most first-time deployments are solved by the first three.
1. Is the script actually on the page?
Open the page, view the source or the browser's Elements panel, and search for AISellerSettings. If it is missing, the script has not been installed or your CMS has not published the change.
A quicker check: open the browser console and type window.AISeller. If it is undefined, the script is not loading, and nothing in Docket will fix that until it does.
2. Is the exact domain whitelisted?
Open the agent's Widget tab and expand Whitelist Domains. Check the host you are actually testing, character for character.
| You are testing | The entry must be |
|---|---|
| https://www.example.com/pricing | www.example.com |
| https://example.com/pricing | example.com |
| https://staging.example.com | staging.example.com |
There is no wildcard, so example.com does not cover www.example.com and a parent domain does not cover its subdomains. When the domain is missing, the agent refuses to start and the browser's network panel typically shows a 403 on a request to Docket.
3. Is the agent Active?
Open the agents list and check the status on the agent's card. An agent can be Active, Disabled or Draft, and only an Active agent serves the widget. A paused agent sits in Disabled, which is easy to miss because the configuration still looks complete.
4. Does Widget Behaviour allow this page?
Expand Widget Behaviour and find the card for your domain.
| Setting | What to expect |
|---|---|
| All Pages | The widget can appear anywhere on that domain. |
| Selected Pages | Only the listed pages show it. |
| On Click (Function Call) | Nothing appears until your own button calls it. This is working as configured, not a fault. |
5. Are Work Hours limiting it?
On the Agent tab, expand Work Hours. Check the configured days, hours and time zone, and note the Enable widget post working hours only switch, which makes the widget run outside your schedule rather than during it.
Outside the hours it is allowed to run, the agent declines to start, which can look like an outage rather than a schedule.
The widget used to work and has stopped. What changed?
When a deployment was live and went quiet, the whitelist is rarely the cause. These are the things that actually change underneath a working widget.
Your cookie banner is blocking the script
This is the most common cause of a widget that silently disappears for many visitors at once, and it is worth checking first.
If your consent platform classifies the Docket script and holds it until a visitor accepts, then every visitor who declines or ignores the banner sees no widget at all. Because most banners only appear in certain regions, the effect can look random until you test from the right location.
Fix it in your consent platform, not in Docket: map the Docket script to the category you intend, or allow it to load independently of consent. This is separate from Docket's own Consent Management setting, which never stops the widget loading and only controls whether a returning visitor is remembered. Privacy and Consent for Docket Marketing Agent explains the difference.
A security policy or network is blocking Docket's own domains
A content security policy, corporate firewall, proxy or SSL-inspecting gateway can block the script or the connections it needs, which shows up as a widget that loads nothing or connects and immediately fails.
Docket's script and its runtime connections must be allowed in your CSP script-src and connect-src, in any consent tool that blocks scripts, and in firewall or proxy rules. Ask your Docket contact for the current list of hosts before your security team starts, because more than one host is involved and the list changes as infrastructure moves.
A page-optimisation plugin has neutralised the script
Performance plugins can rewrite third-party scripts so they never execute. The script is present in the page source, which makes this confusing, but it never runs and the widget file is never requested.
Check whether your site uses a caching or optimisation plugin, and exclude the Docket script from its script handling, then clear the cache.
There are two copies of the script
When a snippet is added twice, often once by hand and once through a tag manager, an older copy can point at an agent that no longer exists. The page then makes failing requests while the widget rarely renders.
Search the page source for AISellerSettings and confirm it appears once, with the agent ID from the current Deploy tab.
An IP Access Rule is blocking the visitor
If IP Access Rules are configured on the Deploy tab, visitors from a restricted address, range or country are refused, which also returns a 403. Review the rules if the widget works for some people and not others.
How do you read what the browser is telling you?
Open developer tools and check both panels.
- Console: JavaScript errors from your own page can stop the script running before it loads.
- Network: look for the widget script and for red statuses. A 403 points at the domain whitelist or an IP rule. A blocked or cancelled request points at consent tooling, CSP, an ad-blocker or the network.
Then rule out your own browser: test in a private window, disable extensions, and try a different network. Ad-blockers do sometimes drop the request silently.
How do you tell a Docket problem from a website problem?
Open the agent's standalone page from the Deploy tab. If the agent works there but not on your site, the agent itself is healthy and the problem is in the deployment: the script, the domain, the behaviour rule, consent tooling or the network.
See How to Validate a Widget Deployment for a full pre-launch check.
What should you send when you ask for help?
- The agent name and the exact URL where the widget should appear.
- The domain as it is entered in Whitelist Domains.
- The Show Widget on setting for that domain.
- Whether Work Hours or IP Access Rules are in use.
- Whether your site uses a consent banner, a tag manager, a CSP, or an optimisation plugin.
- Console errors and failed network requests, ideally as a saved HAR file.
Frequently asked questions
What does a 403 from Docket mean?
The agent refused to start for that request. The usual cause is that the domain is not whitelisted, and the other is an IP Access Rule blocking the visitor. Check the exact host first.
Our widget vanished for most visitors overnight. Where do we look?
Start with your cookie banner. If a consent change reclassified the Docket script, every visitor who has not accepted stops seeing the widget, which can remove most of your traffic at once.
The script is in the page source but the widget never appears. Why?
Being present is not the same as running. A page-optimisation plugin can convert it to an inert script, and a consent tool can hold it. Check whether the widget file is actually requested in the Network panel.
Why does the widget work on staging but not production?
They are separate hosts and need separate whitelist entries. Confirm the production host is listed on the same agent.
It works for me but not for a colleague. What is different?
Look at the things that vary by person: consent choice, region, corporate network, VPN, browser extensions and ad-blockers. IP Access Rules also apply per visitor.
Does declining cookies stop the agent working?
Not on Docket's side. Docket's Consent Management only decides whether a returning visitor is remembered. But if your consent platform is holding the Docket script, declining will stop it loading. That is a setting in your platform.
Is the clock icon next to a domain telling me the widget is broken?
No. That indicator reports whether Docket could find your script on the domain when it last checked. It is useful information, but it does not control whether the widget runs.
Nothing happens when visitors click our own button. Is that this problem?
That is usually the On Click setup rather than a loading fault. Check Setting up OnClick Trigger for the widget, and confirm window.AISeller is defined in the console.