Why is there no launcher while I am building the page?

Because the Designer does not run custom code, by design. The field is applied when Webflow generates the published pages, so the only place the launcher can appear is on a published address. This is not a fault and there is no setting that changes it.

Do I have to add it to every page separately?

No. The project level footer field is emitted on every published page of that site, so one paste covers the whole thing. Webflow also has a per page custom code field, but you do not need it here, and putting the tag in both would just make the loader ignore the second copy.

Can it answer from my CMS collection pages?

Yes, if they are published. A crawl of your site follows your own links and reads a published collection page exactly as a visitor would. Items still in draft are not served to anyone, so they are not read either.

Will it inherit or break my Webflow styles?

Neither. The launcher sits in a closed shadow root and the conversation panel is a separate frame, so your typography and resets do not reach it and its styles cannot leak into your page.

Install guide

Adding a chat assistant to a Webflow project

Webflow keeps the Designer and the published site strictly apart, and that single fact explains almost every install problem on this platform. The tag goes into a settings field rather than onto a page, it never runs while you are editing, and it reaches visitors only after the next publish.

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 Webflow

Project settings, then the Custom code section, then the field for code before the closing body tag.

Webflow puts published custom code behind a paid site plan. Without one, the code does not reach anything you publish, which reads like a broken widget rather than a billing question.

Step by step

1Open the project settings for the site, then the Custom code section.
2Find the field for code that belongs before the closing body tag, rather than the head field above it.
3Paste the tag on its own line and replace the placeholder with your own key.
4Save. Saving stores the code in the project. It does not put it in front of anybody.
5Publish the project, and tick every domain you want it on, including the staging subdomain if that is where you test.
6Open the published address in a private window, not the Designer, and confirm the launcher appears once the page settles.

What goes wrong on Webflow

The canvas is not the site

Custom code does not execute inside the Designer, and the Designer's own preview toggle is still the Designer. Nothing you put in that field will ever render while you are building.

The symptom is predictable: somebody saves the field, stares at the canvas, sees no launcher, and pastes the tag a second time somewhere else. Judge the install only from a published address.

Staging and your domain are two origins

A published Webflow project answers on the webflow.io subdomain as well as on any domain you connected, and a browser treats those as unrelated origins. Allowlist only the custom domain and every staging check you run will render nothing and name the refused origin in the console.

Apex and www count separately too, so a site that redirects www to apex still needs whichever one the browser sees first.

Edits sit in the project until the next publish

Changing the key, or removing the tag, changes the saved project and nothing else. The live site keeps serving the previous build until somebody publishes, and Webflow gives no warning that unpublished custom code is waiting.

This bites hardest when you fix an install at the end of a day and assume it is fixed. If the publish did not run, it is not.

Origins to allowlist

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

https://your-site.webflow.io
https://yourdomain.com
https://www.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 Webflow 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 Webflow that depends on what kind of site this is. These go one level further than this guide.

Taking it off again

Clear the tag out of the footer custom code field in project settings, save, then publish again. The old markup stays live until that publish finishes.

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

Why is there no launcher while I am building the page?: Because the Designer does not run custom code, by design. The field is applied when Webflow generates the published pages, so the only place the launcher can appear is on a published address. This is not a fault and there is no setting that changes it.
Do I have to add it to every page separately?: No. The project level footer field is emitted on every published page of that site, so one paste covers the whole thing. Webflow also has a per page custom code field, but you do not need it here, and putting the tag in both would just make the loader ignore the second copy.
Can it answer from my CMS collection pages?: Yes, if they are published. A crawl of your site follows your own links and reads a published collection page exactly as a visitor would. Items still in draft are not served to anyone, so they are not read either.
Will it inherit or break my Webflow styles?: Neither. The launcher sits in a closed shadow root and the conversation panel is a separate frame, so your typography and resets do not reach it and its styles cannot leak into your page.

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