GUIDE

How to add an AI chatbot to your website, three ways, with the code

A plugin, a script tag or your own build. What each one asks of you, what it can and cannot do, and the code for the one most sites should use.

Published

There are three ways to put an AI chatbot on your website. Which one you want depends mostly on who can edit your site’s layout.

The code in this guide is ours. Deacon is an AI customer support agent that answers from the help pages you have already written, it goes on with one line of HTML, and the free plan takes no card. The rest of it applies whichever tool you pick.

The three ways, side by side

A platform plugin

What it asks of you
Install from your platform’s directory, configure in its admin
What it cannot do
Follow you off that platform, or reach a page the plugin does not render

A script tag

What it asks of you
Paste one line of HTML into your layout
What it cannot do
Appear on a page that does not load that layout

Your own build

What it asks of you
A backend, a model API key, a chat interface, and the time to keep all three running
What it cannot do
Run without someone maintaining it

A platform plugin

If your site is on Shopify, WordPress, Wix or Squarespace, whoever you buy from probably has a plugin in that platform’s directory. You install it, sign in, and the settings live in your platform’s admin rather than in the vendor’s dashboard.

The appeal is that you never open a template. A plugin is also one more thing to keep updated, it only covers the pages your platform renders, and if it does not support something you need, you wait for the vendor.

A lot of these plugins do nothing except add a script tag for you. Check that before you commit, because it is a job you can do yourself in one line.

A script tag

One line of HTML, before the closing body tag, on every page you want the widget on.

This is what most vendors hand you and what most sites should use. It works on any platform, it survives a redesign, and moving to a different stack is a copy and paste. The only thing it asks is that you can edit your site’s layout, or install something that can edit it for you.

Your own build

You call a model API from your own backend and store the conversation. You write the chat interface, and you handle rate limits and abuse. Then you decide what happens when the model has no answer. People underestimate that last part.

Build your own only if answering questions is the product you sell. For anything else you are spending engineering time on something a script tag does this afternoon.

The code for a script tag

Here is the whole install. This is Deacon’s real tag rather than a placeholder, and it is all the code there is.

<script src="https://heydeacon.com/widget/v1/loader.js" data-key="pk_your_widget_key" async></script>

It goes just before the closing </body> tag, on every page you want it on. Put it in your layout rather than on each page, so one edit covers the whole site. It loads in the background and never blocks the page.

The key identifies your site. You also list the domains the widget is allowed to run on, and it appears on every page of those and nowhere else. On a domain you have not listed, the loader stays silent, so somebody copying your tag onto their own site gets nothing.

In a framework the tag goes in the one layout every page uses. That is app/layout.tsx in Next.js, application.html.erb in Rails, app.blade.php in Laravel, and the single HTML file in a single-page app. Never load it twice.

Try Deacon for free

Install Deacon

Telling it who is asking

A widget that knows nothing has to ask the visitor everything, including the things your app already knows about them. Almost nobody sets this up.

Hand it what you have.

<script>
  window.deaconContext = {
    plan: 'Pro',
    state: 'active',
    role: 'owner',
    seats: 4,
  };
</script>

That block goes above the snippet, in the same layout, because the widget is built from it as the page loads. Up to twelve keys, and up to 1500 characters once it is JSON. Render it from the session your app already has rather than fetching anything again.

Send what helps answer a support question. Never send a password, a token, an API key or an internal id, because the whole block is written into the page’s HTML and the visitor can read every value in it. Anything arriving from a browser is a hint rather than proof, and Deacon treats it that way.

Opening it from your own button

Most widgets paint a button in the corner, and most let you turn that off and open the window from a control of your own. Do that if you already have a help menu. The call is one line.

<button onclick="Deacon.open()">Ask a question</button>

If you hide the vendor’s button and add nothing of your own, the install looks like it failed. Put yours where your users already look for help — the account menu, the footer, the bottom of an empty state.

Checking it actually went live

Do not trust a dashboard that says you are installed before a real page has loaded the tag.

Deacon’s install page tells you the origin your widget was last seen on and how long ago, so you can prove it rather than guess. Load a page of your own site in a browser, then go and look.

If nothing arrives, it is almost always one of four things. The page you loaded is not on a listed domain, the tag is not in a layout that page uses, the key is wrong, or your dev server is serving a cached build.

Adding Deacon to your site

Deacon is the script-tag route. One line, any platform, and the dashboard behind it is where you add your help pages and read what your customers asked.

Where the line goes differs by platform, so there is a page each for WordPress, Shopify, Webflow and Framer.

Every answer is written only from the material you gave it, and when the answer came from one of your pages it links to it. When nothing covers the question, Deacon says so, takes the visitor’s email and hands you the conversation to finish.

The same tag counts your page views, so you get visitors, sources, pages and countries without adding a second script. It sets no cookie and keeps no address, so there is nothing new for your cookie banner to mention.

The free plan is 50 answers a month on one seat, with no card and no time limit. That is enough to put it on a real page and find out what your customers actually ask. The install guide is the long version, with the theme settings and the knowledge base.

What to decide first

Work out who edits your site’s layout. If that is you, a script tag is fifteen minutes and you are done. If it is an agency with a ticket queue, a plugin may honestly be faster.

Then work out what the bot does when it has no answer, because that is the case your customers will actually meet. Ask whoever is selling it to show you that case working.

Then check what the meter counts before you compare prices. A message, a conversation and a resolution are three different amounts of work, and we put the numbers side by side in Chatbase alternatives. Deacon counts answers, and the free 50 take no card, so you can paste the line above into your own site today and see what comes back.

Try it on your own documentation

Add your help pages, ask it the question you know your docs cannot answer, and watch it say so.

The free plan covers 50 answers a month on one seat, and the paid plans are on the pricing page.

Start free

Free plan, no card.

READ NEXT