A practical checklist for embedding a chatbot without breaking your site

Adding a chatbot to a website is, mechanically, one script tag pasted before a closing body tag. That simplicity is real, but it also means the parts most likely to go wrong aren't the install itself — they're the handful of things around it that are easy to skip because the widget appears to be working the moment the tag is in place.

Start with where the tag actually lives. A single paste into a shared footer template covers every page built from that template, but sites with multiple templates — a marketing site built on one system and a docs site or app on another — need the tag in each one separately. It's a common gap: the widget shows up everywhere the marketing team's pages render and is quietly missing from a support or docs subdomain that uses a different template entirely.

Domain restrictions are worth setting before launch, not after. Anyone who views page source can see the embed snippet, and without an allowed-domains restriction, that snippet works exactly the same wherever it's pasted — including somewhere you didn't put it. Setting the allow-list to the exact domains and subdomains the site is actually served from closes that off with no ongoing effort once it's configured.

Test the actual conversation, not just that the bubble renders. A widget that loads and opens is only step one — the real test is asking it a handful of the exact questions customers ask most, and checking that the answers are accurate and current. This is also the moment to test lead capture, if it's enabled: send a message that should trigger the ask, and confirm the resulting lead actually shows up where it's supposed to a few seconds later.

Check appearance in both light and dark mode if your site supports both, and at the mobile breakpoint specifically — a floating bubble that sits comfortably in a corner on desktop can end up overlapping a sticky mobile nav bar or a cookie-consent banner if nobody checked that combination. This is a five-minute check that catches a surprising number of real launch-day issues.

Finally, decide who owns the widget's settings going forward — the greeting message, the color, the knowledge base — before launch, not during an incident. Because none of this requires a redeploy (widget settings and knowledge sources are read live), it's tempting to leave ownership vague. In practice, that just means the first time something needs fixing, several people independently discover they can do it and none of them knew that going in. A five-minute conversation about who's the primary owner avoids that.

None of these steps are hard individually, and skipping all of them still usually results in a widget that technically works. The difference they make is in whether it works well from day one instead of needing a round of fixes after a customer or teammate notices something off.

Want the full picture? Read our guide on how to add an ai chatbot to your website in minutes.