Chatbot Not Showing on Your Website? A Step-by-Step Troubleshooting Guide

When a chatbot is not showing on a website, start with a controlled check instead of changing several settings at once. Open the published page in a private browser window, confirm that the correct embed is present, and note whether the issue affects every visitor or only one browser, device, or page. Then inspect the browser console and network panel for blocked scripts or failed requests. Our full guide to adding an AI chatbot to your website explains the common installation paths; this troubleshooting checklist focuses on narrowing down a widget that appears to be missing.

Explore our full guide to adding an AI chatbot to your website.

For the complete guide, read How to Add an AI Chatbot to Your Website (5-Minute Guide).

First verify that the page actually contains the current embed code. A script may have been pasted into a draft rather than the published page, added to a page template that does not apply to the affected route, or removed during a theme or page-builder update. Compare the live HTML and the installation instructions from your chatbot account; do not copy a script from an old email or a different bot. Check that the bot is published, enabled, and configured for the website domain if the service uses domain restrictions. Exact account labels and allow-list controls depend on the product and should be checked in its current documentation.

Next look for a JavaScript error or a blocked network request. In the browser's developer tools, inspect the Console for a script syntax error, a failed initialization, or a content security policy message. In Network, filter for the widget script and related requests, reload the page, and examine status codes and blocked reasons. A 404 can indicate a wrong script URL; a blocked request may point to an extension, privacy setting, firewall, or site policy. Redact tokens and private customer data before sharing screenshots or logs with support.

A site's content security policy can prevent an external widget from loading even when the embed is correctly placed. Review the policy delivered by the server or hosting platform and the browser's exact violation message. Add only the required origins and directives documented by the chatbot vendor and your security owner; do not remove the policy or use a wildcard as a quick fix. Some widgets load scripts, frames, styles, or network connections from different origins, so verify the current integration requirements and test the narrow change on staging before publishing it.

Caching and optimization tools can serve an old page or change script execution order. Purge the relevant page, CDN, and browser caches, then test the exact published URL again. If the site combines, defers, delays, or minifies scripts, temporarily exclude the chatbot script from that transformation in a controlled test. Do not permanently disable site performance or security features without evidence. A reliable test changes one setting at a time, compares the same page before and after, and records whether the widget loads in a clean browser session.

If the widget is missing only on a platform-managed site or one page builder, review where that platform permits third-party scripts and whether the code was added to the correct site-wide or page-level area. Menu names and plan requirements vary by platform, so use the chatbot's verified installation guide and the platform's current documentation rather than following an old screenshot. Check whether a consent manager waits for a visitor choice before loading the script; if so, confirm the expected behavior after consent and ensure the configuration reflects the site's privacy choices.

Test responsive layout and page-specific visibility as separate causes. A widget might be present but behind a sticky banner, clipped by a container, hidden at a mobile breakpoint, or positioned outside the visible viewport. Use the browser inspector to see whether the widget element exists and whether CSS or an overlay obscures it. Verify the configured desktop and mobile behavior, z-index interactions, and any rules that show the chatbot only on selected URLs. Avoid adding broad CSS overrides until you identify the element and the intended positioning.

If the issue remains, reduce the page to a minimal reproducible test: the affected published URL, browser and device, time of test, whether consent was granted, and the relevant console or network error with secrets removed. Compare with another page where the widget works and identify differences in templates, policies, or script optimizations. Contact the product's support team with that evidence and the bot identifier if appropriate, but never post API keys, session tokens, or full visitor transcripts publicly.

Once it loads, verify more than visibility. Open the widget, send a test message that contains no personal information, confirm the expected response, check the close and reopen controls, and test keyboard access on desktop and mobile. Make sure a change to CSP, caching, or consent settings has not broken other site behavior. Add the test to the site's release checklist so theme, plugin, or security updates do not silently remove the embed. If a vendor-specific setting remains uncertain, verify it with current documentation rather than guessing.

Check that the widget is not being restricted by an environment or domain setting. A script that works on a preview domain may be blocked on the production hostname, or the widget may be configured to appear only on selected paths. Review the vendor's current account settings and compare the exact scheme, subdomain, and path of the failing page. Do not broaden an allow-list to every domain simply to make a test pass. Confirm the intended production domains with the website owner and keep the setting as narrow as the product supports.

Consent tools can affect when scripts are allowed to load. If the chatbot appears only after a visitor accepts a category, test the configured consent state and verify whether the vendor documents the script as essential or optional for your use. The correct classification depends on the site's purpose and applicable requirements, not on a developer's desire to make the widget visible. Coordinate any change with the privacy owner. Test both acceptance and rejection paths, and ensure the page still provides a workable non-chat contact method.

Check recent deployments and differences between affected pages before making a broad code change. A theme release, plugin update, content security header, tag-manager rule, or template-level optimization may have changed how scripts are inserted. Compare the page's source and network behavior with a known-good page, then test a minimal, reversible change on staging. Record the original settings so the site can be restored if the change affects another feature. If the vendor confirms a service issue, keep the support reference and avoid exposing private request headers when sharing diagnostics.

A useful troubleshooting record includes the live URL, timestamp and time zone, browser version, device type, consent state, and a short description of what you expected. Capture only the relevant console and network evidence, with private data removed. If the widget loads for one person but not another, compare extensions, browser protections, and network restrictions before changing shared site code. This focused evidence helps a developer or vendor distinguish a website configuration issue from a local browser or service problem.

Want the full picture? Read our guide on how to add an ai chatbot to your website (5-minute guide).