Do I need Liquid raw tags around the script?

No. Liquid acts only on its own delimiters and a script tag contains none of them. Wrapping it in raw is harmless but pointless, and it leaves the next reader wondering what you were working around.

_layouts or _includes?

Either. If your default layout already ends by pulling in a footer include, adding the line there keeps the change in one small file. If it does not, the layout is the right place and you should not create an include just for this.

Will it appear on posts as well as pages?

Yes, provided both resolve to the layout you edited. Post layouts commonly declare the default layout in their own front matter, so the tag reaches them through that inheritance rather than needing a second paste.

Should I index the source files or the published site?

The published site. A crawl reads rendered pages, so it sees your content after Liquid has run and after includes have expanded, which is what a reader actually gets.

Install guide

Installing a chat assistant on a Jekyll site

A Jekyll theme distributed as a gem keeps its layouts outside your repository, which is why the file you want to edit often is not there to open. Copying it into your own _layouts folder is both the fix and the thing that keeps your change through the next theme bump.

The tag

<script src="https://cdn.askably.xyz/w.js" data-key="pk_live_YOUR_KEY" defer></script>

Your own key replaces the placeholder. You will find it on the install tab of the assistant.

The origin the page is served from has to be on the allowlist for that assistant, or nothing renders and the browser console says which origin was refused. An apex domain and its www are two different origins to a browser, so list both, along with any staging or preview host you want it to work on.

Where it goes on Jekyll

_layouts/default.html in your site root, or an include in _includes that the layout pulls in, immediately before the closing body tag.

Any Jekyll site, whether you build it yourself or let your host build on push. Nothing here needs a plugin, which matters on hosts that only run an approved plugin set.

Step by step

1Check whether _layouts/default.html exists in your repository. With a gem based theme it usually does not, because the layout ships inside the gem.
2If it is missing, print the gem's path with bundle info and the theme name, then copy _layouts/default.html out of that directory into your own _layouts folder.
3Paste the tag on its own line immediately before the closing body tag. Liquid interprets only its own brace delimiters, so a plain script tag passes through unchanged and needs no raw wrapper.
4Look at your other layouts and check which of them set the default layout in their front matter. Those inherit the tag. Any that do not are pages without a launcher.
5Commit and push. If your host builds the site, wait for that build to report success before testing anything, and read the failure notice if it does not.
6Load the published page and confirm the launcher appears.

What goes wrong on Jekyll

The layout you want to edit lives inside a gem

A gem based theme keeps _layouts, _includes and _sass out of your repository entirely, so the obvious file to open simply does not exist. Editing the copy inside the installed gem does work, right up until the next bundle update quietly replaces it.

Copy the file into your own _layouts folder instead. Jekyll prefers a local file over the gem's version of the same path, and the copy is then yours to keep.

Do not prefix the loader with the site baseurl

A project site is published under a subpath, and the habit on such a site is to prefix every asset reference with the baseurl variable. Doing that here produces a broken relative address, because the loader is an absolute URL on another host.

The baseurl exists to fix paths on your own site. It has no business in front of a third party address, and the symptom is a request to a path on your own domain that returns your 404 page.

Pushing is not publishing

If the build fails, and a single stray Liquid brace anywhere in the commit is enough to fail it, the previously built site keeps serving and your change is simply not present. The page looks untouched and the tag is missing from the source.

Check the build status, not the commit. That is the first thing to look at whenever a Jekyll change appears to have done nothing.

Origins to allowlist

These are the origins a Jekyll site is typically served from. List every one you want the assistant to answer on, including the ones only you visit.

http://localhost:4000
https://yourname.github.io
https://yourdomain.com

How the tag behaves, wherever you put it

The rest of this is the same on every platform, so it is worth reading once rather than on each guide.

Loader behaviour
One tag, nothing else	There is no second file, no stylesheet and no package to install. The tag is the whole install.
Where it goes	Immediately before the closing body tag. It works in the head too, because it defers, but the body keeps it out of the way of anything that measures render order.
data-key is required	Without it the loader stops and writes a warning to the browser console rather than rendering anything.
It finds itself	The loader reads the tag it was loaded from, and falls back to the first tag on the page carrying a data-key. Platforms that move or re-inject the tag do not break it.
It installs once	A second copy of the tag on the same page is ignored, so a template that renders twice does not produce two launchers.
Assets follow the tag	Everything else it needs is fetched from the same origin the tag was served from, so a proxy or a private domain needs no extra configuration.
The panel loads late	Only the small launcher is on the page at first. The conversation panel is fetched the first time a visitor opens it, in its own frame.
Styles cannot collide	The launcher renders inside a closed shadow root and the panel inside a frame, so nothing on the host page can restyle either, and neither can restyle the host page.

Set up on Jekyll for a particular trade

The tag is the same everywhere. What is not the same is which of your pages the assistant can read once it is running, and on Jekyll that depends on what kind of site this is. These go one level further than this guide.

For a online courseLaunch posts accumulate. Old cohort dates and old prices stay live, sit in the sitemap, and read to a crawl exactly like the current ones.

Taking it off again

Delete the line from your copy of the layout and push. If that copy exists only to carry the tag, deleting the file returns you to the theme's own layout.

Before you remove it

Removing the tag stops the widget on that site. It does not delete the assistant, its material, or the enquiries it has already collected.
If you are moving the widget to a different host rather than retiring it, add the new origin to the allowlist before you remove the old tag, or there is a window where neither works.

Questions

Do I need Liquid raw tags around the script?: No. Liquid acts only on its own delimiters and a script tag contains none of them. Wrapping it in raw is harmless but pointless, and it leaves the next reader wondering what you were working around.
_layouts or _includes?: Either. If your default layout already ends by pulling in a footer include, adding the line there keeps the change in one small file. If it does not, the layout is the right place and you should not create an include just for this.
Will it appear on posts as well as pages?: Yes, provided both resolve to the layout you edited. Post layouts commonly declare the default layout in their own front matter, so the tag reaches them through that inheritance rather than needing a second paste.
Should I index the source files or the published site?: The published site. A crawl reads rendered pages, so it sees your content after Liquid has run and after includes have expanded, which is what a reader actually gets.

Keep reading

Try it on your own material

Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.

Start free See what it does