How to Add a Chatbot Widget to Your Website

Adding a chatbot widget to a website is a two-line script tag, not a development project — but "just paste this snippet" glosses over the parts people actually get stuck on: where the code goes, how to test it before visitors see it, and what to configure so it doesn't look like a generic bolt-on. Here's the whole process, plus the WordPress-specific path if you don't want to touch template code at all.

Before you embed anything: train the bot first

A widget with nothing behind it just wastes a visitor's first message. Upload your FAQ, product pages, or policy docs and confirm the bot answers a handful of real questions correctly before you put it in front of traffic — see How to Train an AI Chatbot on Your Own Data for the full process. It takes a few minutes and saves you from shipping a chatbot that greets your first real visitor with "I don't know."

Method 1: the script tag (works on any site)

Every chatbot on BotBuild gets its own embed code from the dashboard's Embed & Test page. It's two lines: a config script that identifies your chatbot, and a script tag that loads the widget itself, asynchronously so it never blocks your page from rendering.

<script>window.BotBuildConfig = { chatbotId: YOUR_CHATBOT_ID };</script>
<script src="https://api.botbuild.co/widget.js" async></script>

Paste both lines right before the closing </body> tag of your site's HTML — or, on a site builder like Webflow or Squarespace, into whatever "custom code" or "footer code" section it provides for embeds. The async attribute means it loads independently of the rest of your page, so it won't slow down your Core Web Vitals; the widget renders itself as a small floating bubble once it's ready.

One config script, one bot. If you run the chatbot on multiple sites — say a main site and a landing page — each site just needs the same two lines with the same chatbot ID; there's nothing per-domain to configure unless you're on white label.

Method 2: the WordPress plugin (no code editing)

If your site runs on WordPress, the Embed & Test page also offers a one-click plugin download — a zip file you upload through Plugins → Add New → Upload Plugin in your WordPress admin. Activate it, and it inserts the embed script for you on every page. No theme files, no page builder "custom HTML" block, nothing to break on your next theme update.

Test it before it's live

The same Embed & Test page includes a live preview and a real chat pane connected to your actual bot and training data — so you can send it the exact questions a visitor would ask and see the real response before the widget ever touches your production site. Use it to catch two things: answers that are wrong (a training-data problem) and answers that never resolve to anything (a sign your confidence threshold is too strict, or the content just isn't there yet).

Make it look native, not bolted on

A default-styled widget is the fastest way for a chatbot to look like an afterthought. Before you announce it to visitors, set:

• Brand colors — match your site's palette instead of the default theme.
• Corner position — bottom-right is the convention, but all four corners are supported if your layout needs it (a bottom-right CTA button, a chat-support tab already in that corner, etc.).
• Auto-open delay — whether the widget stays closed until clicked, or opens itself after a delay to prompt engagement. Test both; an auto-open that fires the instant a page loads reads as aggressive, not helpful.

Decide whether to gate it with lead capture

If the goal is support deflection, let visitors chat immediately with no friction. If the goal is lead generation, a lead capture gate — collecting name, email, and phone before the first message — turns every conversation into a contact you can follow up with, with an instant email alert the moment someone starts. Which one's right depends on the page: a support-heavy help center page usually wants zero friction, while a pricing or contact page benefits from capturing the lead up front.

Common issues and quick fixes

• Widget doesn't appear at all. Confirm the script is actually in the rendered HTML (view page source, not just your editor) — some site builders strip custom code from certain page types by default.
• Widget appears but won't open. Check for a Content-Security-Policy header blocking the script's origin — this is common on sites with strict CSP rules and shows up as a silent console error, not a visible one.
• Widget shows on some pages but not others. The snippet needs to be on every page template, not just the homepage — a footer include (or the WordPress plugin, which handles this automatically) avoids the problem entirely.
• It looks off-brand. Revisit the widget customization settings — this is almost always a five-minute fix, not a rebuild.