Chat Widget Not Showing on Your Website? Work These 11 Causes in Order

Before touching any setting, open DevTools with F12 (or Cmd+Option+I on Mac) and read the Console tab. A widget that fails to appear almost always leaves an error there, and the error normally names the exact cause.

Last verified: August 2026. The diagnostic sequence below applies to any embedded chat widget, not one product in particular.

Match what you see against this table and jump straight to the relevant section.

Then check the Network tab, filter for the widget domain, and note whether the request appears at all. "Request never made" and "request made and blocked" are entirely different problems, and this distinction saves the most time of any single check - it separates the loading-side sections of this guide from the CSS-side ones before you have read a single one of them, and it takes less time than reading this paragraph did.

The console message is unambiguous:

Refused to load the script 'https://widget.example.com/loader.js'
because it violates the following Content Security Policy directive:
"script-src 'self'"

CSP restricts which domains may serve scripts, styles, images and connections. It is a genuinely valuable security control, and it blocks third-party widgets by default unless you allow them explicitly.

The four directives a chat widget usually needs

A partial allowance produces the most confusing symptom of all: the launcher appears but the conversation never connects, because script-src was allowed and connect-src was not. If your widget opens and then sits loading forever, check connect-src first - and remember WebSocket URLs use the wss: scheme, which must be permitted explicitly.

The 'unsafe-inline' problem

Many widgets inject inline <style> tags at runtime. Under a strict policy without 'unsafe-inline' in style-src, the browser blocks those styles and you get an unstyled or invisible widget - the script loaded successfully, so the console shows no script error and the failure looks like a rendering bug.

Where a nonce-based policy is in place, most vendors document a way to pass the nonce to the widget. Check the integration docs before weakening the policy globally.

Where the CSP actually comes from

Look in three places, because teams often edit one and miss the others: a Content-Security-Policy HTTP response header from your server or framework config, a <meta http-equiv="Content-Security-Policy"> tag in the document head, and your CDN or WAF - Cloudflare, Vercel and similar platforms can inject or modify headers independently of your application.

If the widget uses an iframe, script-src is not enough

Some widgets render their conversation panel as a script-injected DOM tree; others load it inside an <iframe> pointed at the vendor's domain, which is a common way to sandbox the widget's styles and scripts away from the host page. An iframe is governed by a different directive entirely - frame-src, falling back to child-src and then default-src if neither is set. Allowing the widget's domain in script-src does nothing for its iframe: the outer loader script runs fine, requests the panel, and the browser silently refuses to create the frame. This produces a symptom easy to mistake for a CSS bug - the launcher button appears and is clickable, but nothing opens when you click it - so if connect-src checks out and the panel still never appears, check frame-src next.

Many blocklists include chat and support widgets under "tracking", so a widget that is entirely functional simply never loads for a meaningful share of visitors.

Test in a private window with all extensions disabled. If the widget appears there and not in your normal browser, an extension is the cause. Also try a second browser: Brave blocks aggressively by default, and Safari's Intelligent Tracking Prevention affects some third-party storage patterns even without an extension installed.

You cannot fix this for your visitors, and that is worth accepting rather than fighting. What you can do is make sure the widget is not your only contact route - a visible email address, phone number or contact page means a blocked widget costs you a convenience rather than a conversation.

Note also that corporate networks frequently block unknown third-party domains at the firewall. If the widget works everywhere except at one client's office, that is why, and it is resolved by their IT team allowlisting the domain rather than by anything on your side.

Storage partitioning is a quieter version of the same problem

Even when nothing blocks the script outright, browsers increasingly partition or restrict storage for third-party contexts by default - Safari's Intelligent Tracking Prevention caps or clears script-writable storage for classified trackers, and other browsers are moving toward partitioning cookies and storage per top-level site rather than sharing them across every site that embeds the same widget. The visible symptom is not a missing widget but a forgetful one: it loads and opens fine, yet a returning visitor's conversation history is gone, or a session that should persist across a page reload does not. If a widget worked identically to how it works now but the browser vendor tightened this policy, this is usually the explanation, and it is a platform trend rather than a one-time bug to patch.

If the Network tab shows no request for the widget at all, the script never executed. Common reasons, in order:

Pasted outside the document

The snippet must sit inside <head> or <body>. Pasted after </html> - which happens easily in a CMS footer field - browsers may ignore it entirely.

An earlier JavaScript error stopped execution

Scripts run in order, and an uncaught error in an earlier script halts the rest of that block. If the console shows a TypeError from an unrelated script above your widget snippet, fix that first - the widget is a victim, not the cause. This is why the widget sometimes "stops working" after an unrelated site change.

Installed in a template that does not render on every page

Placing the snippet in a specific page template rather than the global layout means it appears on some routes only. Check whether it is missing on all pages or just some - the answer localises the problem immediately.

Single-page apps and route changes

In React, Vue, Next.js and similar frameworks, a widget initialised once on mount may not survive client-side navigation, or may double-initialise. The symptom is a widget present on first load that disappears after navigating. Initialise it at the application root rather than inside a page component, and guard against double-initialisation. Our guides on embedding a chatbot in React, Next.js, Vue and Angular cover the framework-specific patterns.

A tag manager that is not firing

If you installed via Google Tag Manager, the tag may be unpublished, restricted by a trigger condition, or blocked by consent mode. Check in GTM Preview whether the tag actually fires on the page you are testing - an unpublished container is the single most common GTM cause.

You installed the widget, the code is correct, and the live site still shows the previous version. Between you and your HTML there may be several caches, and clearing one is rarely enough.

• Browser cache. Hard reload with Ctrl+Shift+R (Cmd+Shift+R on Mac), or test in a private window.
• CDN cache. Cloudflare, Fastly and similar hold HTML at the edge. Purge the cache from the provider dashboard.
• Platform or plugin cache. WordPress caching plugins, Shopify's theme cache, and static site builds all serve pre-rendered HTML. Clear the plugin cache and, for static sites, trigger a fresh build - editing the template is not enough if nothing rebuilt.
• Service worker. A PWA service worker can serve a cached shell indefinitely. Check Application -> Service Workers in DevTools and unregister it to test.

The fastest way to confirm caching is the culprit: view page source (Ctrl+U) and search for your widget's domain. If the snippet is not in the source, the browser never had a chance - the problem is upstream in your build or cache, not in the widget.

This one is easy to miss because everything about the installation is correct.

Consent platforms such as OneTrust, Cookiebot, Osano and Usercentrics work by holding back third-party scripts until the visitor consents. If your widget is categorised as "marketing" or "functional" and the visitor has not accepted that category, the script is deliberately never executed.

Two things to check:

• The category assigned to the widget. A support chat widget is usually genuinely necessary or functional rather than marketing, but consent scanners often auto-classify unknown third-party domains as marketing by default. Reclassifying it - where your legal position supports doing so - restores it for most visitors.
• Script blocking attributes. Consent managers frequently rewrite <script> tags to type="text/plain" with a data-cookieconsent attribute until consent is given. Check the rendered HTML: if your widget tag has type="text/plain", the consent manager is holding it and no browser will execute it.

Test by accepting all cookies in a fresh private window. If the widget appears only after acceptance, this is your cause. Treat the categorisation as a decision for whoever owns your privacy compliance rather than something to override quietly.

The script returns 200, no console errors, and still nothing. The widget is on the page and something in your CSS is hiding it. Confirm by searching the Elements panel for the widget's container element - if it exists in the DOM, this section is your answer.

z-index

The most common cause. A sticky header, a promotional banner, a cookie bar or a full-page overlay with a higher z-index renders on top. Widgets typically use a high value such as 999999, so a competing element needs an absurd one - and site-wide overlays often have exactly that.

Inspect the element sitting where the widget should be. If it is not your widget, that element is covering it.

A parent with overflow: hidden

A widget injected inside a container with overflow: hidden gets clipped out of view. Widgets are normally appended to <body> to avoid this, but a script that runs inside a component tree can end up nested. Check where the widget's element actually sits in the DOM.

Aggressive global CSS resets

Rules such as div { position: static !important; } or blanket * { } selectors carrying !important can override the widget's positioning. Third-party widgets normally scope their styles, but a sufficiently aggressive global rule wins anyway.

Mobile-specific hiding

If the widget shows on desktop and not on mobile, check for a media query hiding it - some themes hide floating elements below a breakpoint deliberately to protect the viewport. Also check the widget's own settings, since most offer a mobile visibility toggle that is easy to leave off.

Positioned off-screen

Custom offset settings that place the launcher 200px from the bottom work on a tall desktop viewport and push it out of a short mobile one. If the element exists with sensible dimensions but is not visible, check its computed bottom and right values against the viewport size.

Shadow DOM changes where these rules apply

Many widgets attach their markup inside a shadow root - an isolated DOM subtree created with element.attachShadow() - specifically to avoid the global-reset and z-index problems above: styles inside a shadow root do not leak in either direction across its boundary by default. That isolation is also why some general-purpose CSS debugging habits stop working. Selecting the widget in the Elements panel shows a #shadow-root node rather than the widget's markup directly under <body>, and a browser extension or site script that walks the DOM with document.querySelector will not find elements inside it unless it explicitly pierces the shadow boundary. If you are trying to style or debug a shadow-DOM widget from outside its own settings panel, most of the CSS overrides in this section simply cannot reach it - which is by design, not a bug to work around.

Finally, a category that is not a bug at all. Check these in the widget's own dashboard before spending more time in DevTools.

• Domain allowlist. Most widgets restrict which domains may load them. A widget configured for example.com will not load on staging.example.com, on www.example.com if only the bare domain was added, or on a preview deployment URL. This is by far the most common configuration cause.
• Business hours. A widget set to appear only during business hours is invisible outside them, exactly as intended - and this is a favourite cause of "it works for me but not for our overseas team".
• Page targeting rules. Show/hide rules based on URL patterns can exclude more than intended, particularly when a rule was written for a path that has since changed.
• Bot paused or unpublished. A flow in draft, or paused during editing, may stop the widget rendering at all rather than showing an empty one.
• Time or scroll delay. A launcher configured to appear after 30 seconds or 50% scroll is not missing during the first few seconds of testing.

The domain allowlist deserves a specific test: compare the domain in the browser address bar, character for character, against the allowlist entry. www versus bare domain accounts for a surprising share of these, and so does a preview or staging subdomain that nobody thought to add because it did not exist when the allowlist was first configured.

Worked in this order, the cause is normally identified within a few minutes.

Step 1 is the highest-value check in the list. If the snippet is not in the page source, nothing about the widget itself can be the cause, and you have eliminated six of the seven sections instantly.

Some widgets are present and functional but appear late enough that a quick check concludes they are missing. Worth ruling out before deeper debugging.

Deferred loading

Many widgets deliberately delay initialisation until after the page's main content, to protect Core Web Vitals. On a slow connection that can be several seconds. Watch the Network tab rather than the viewport - if the request fires eventually, the widget is working and the question is whether the delay is acceptable.

Lazy-loading tied to interaction

Some installations only load the widget after first scroll, mouse movement or a timer. If you load the page and immediately screenshot it, you will conclude it is broken. Scroll, wait, and move the mouse before judging.

Slow third-party responses

If the widget request is pending for many seconds, the vendor's edge may be slow or degraded from your region. Check the vendor status page. This is also worth measuring: a widget that consistently takes 4 seconds to appear is costing you conversations even though it technically works.

The performance trade to be aware of

Widgets are third-party JavaScript and they have a cost - typically some main-thread work and a WebSocket connection. If Lighthouse flags your chat widget, the answer is usually to defer it rather than remove it, but check that your deferral is not so aggressive that visitors leave before it appears. Measure the actual time-to-launcher on a throttled connection and decide deliberately. The Core Web Vitals metric most relevant here is INP (Interaction to Next Paint), which replaced FID as Google's responsiveness metric - it measures the delay on every click and tap across the page's lifetime, not just the first one. A widget that parses a large bundle on the main thread right as a visitor clicks something else can show up as an INP regression even though the widget itself looks and works fine; the fix is the same deferral and chunking discipline as any other non-critical third-party script, not something specific to chat widgets.

Hosted platforms each have a characteristic way of losing your script.

Shopify

Code added to theme.liquid is lost when the theme is updated or replaced, which is the classic "the widget disappeared and nobody changed anything" report. Prefer a theme app extension or the script tag API where available. Also note that the checkout pages are separate and generally do not run theme code - a widget present on product pages and absent at checkout is expected behaviour, not a bug.

WordPress

Three things interfere routinely. Caching plugins serve stale HTML, so purge after installing. JavaScript minification and combination features in performance plugins can mangle third-party snippets - exclude the widget script from optimisation. And theme updates overwrite edits made directly to header.php or footer.php; use a child theme or a code-insertion plugin so the snippet survives.

Wix

Custom code is added through Settings rather than by editing pages, and each snippet has an explicit page-scope setting - "all pages" is not always the default. Wix also loads custom code inside a sandboxed context in some configurations, which can affect widgets expecting direct DOM access.

Squarespace and Webflow

Both distinguish site-wide code injection from per-page code, and both require a republish for changes to reach the live site. Editing the injection field and not publishing is the single most common cause of a widget that is "installed" and absent. On Webflow, also check that you added the code to the correct project and to the published domain rather than only the staging subdomain.

A general rule

On every one of these platforms, the definitive test is the same: load the live URL, view source, and search for the widget domain. If it is not there, the platform did not publish it, and no amount of widget-side configuration will change that. Platform-specific installation steps are covered in our guides for Shopify, WordPress, Wix, Squarespace and Webflow.

Most of the failures above are environmental rather than product-specific - CSP policies, consent managers, caching layers and z-index wars affect every embedded widget equally. What differs between products is how much they help you diagnose them.

Conferbot's website widget is available on the free plan and installs with a single script tag on Shopify, WordPress, Wix, Squarespace, Webflow and plain HTML, with framework guides for React and Next.js and a native mobile SDK for iOS, Android, React Native and Flutter when a web widget is not the right surface - a native app has no DOM, no CSP and no ad blockers to work around, so most of this guide simply does not apply there. The same conversation flow also runs on WhatsApp and Telegram, which matters more than it sounds: a visitor whose browser blocks third-party widgets can still reach the same bot on a channel their browser has no opinion about.

Start free with Conferbot - 600 conversations a month, no credit card required.

Debugging right now? Start with step 1. Whether the snippet appears in view-source decides which half of this guide you need, and it takes ten seconds.