Install guide
What is actually possible on Google Sites
This page is more caveat than instructions, because the honest answer for Google Sites is a compromise. New Google Sites does not let you add a script to the page itself on any account. What you can do is put an embed block on the page, and an embed block behaves very differently from a floating launcher.
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 Google Sites
Insert, then Embed, then the tab that takes embed code rather than a link.
There is nothing to buy that changes this. New Google Sites has no field for page level scripts on any account, business accounts included. An embed block is the entire set of options.
Step by step
- 1Open the page in the Google Sites editor and choose Insert, then Embed.
- 2Switch to the tab that accepts embed code rather than a link to another page.
- 3Paste the tag, with whatever minimal markup you want around it, since this block renders as its own small document rather than as part of your page.
- 4Insert it, then move the resulting block to where the assistant should live and size it on purpose. It occupies that space permanently, whether or not anyone uses it.
- 5Publish the site and open the published address.
- 6Read the browser console on that page. The embed runs from a Google content origin rather than from the address in the URL bar, and the console names the exact origin that has to be on the allowlist.
What goes wrong on Google Sites
It cannot float and it cannot overlay
An embed block is part of the page flow. The assistant is confined to the rectangle you gave it: no corner launcher, no panel opening over your content, no following the visitor as they scroll.
Say plainly whether that is acceptable before you build around it. If the experience you had in mind was a launcher in the corner of every page, Google Sites cannot produce it, and a site that needs one is better served by a host that allows a script tag.
The block costs you page space on every visit
Because the block is always rendered, you are permanently reserving layout for something most visitors will not use. On a narrow screen that reservation competes directly with the content people came for.
One embed on a support or contact page usually makes more sense here than an embed repeated on every page of the site.
The origin is not the one in the address bar
The embed is rendered inside its own frame served from a Google content domain, so the origin the browser reports is not sites.google.com and not your mapped domain. Allowlisting either of those and nothing else leaves you with an empty box.
The console names the refused origin exactly. Copy it from there rather than guessing at it.
Origins to allowlist
These are the origins a Google Sites site is typically served from. List every one you want the assistant to answer on, including the ones only you visit.
- https://sites.google.com
- https://yourdomain.com
- the exact embed frame origin the console names when it refuses, which is a Google content address rather than your site address
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.
| 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 Google Sites 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 Google Sites that depends on what kind of site this is. These go one level further than this guide.
Taking it off again
Select the embed block in the editor, delete it, and publish the site again.
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
- Is there really no way to add a script to the page itself?
- No. New Google Sites has no code injection field, no theme files and no setting that adds one, and no plan or account type unlocks it. Anyone telling you otherwise is describing a different product or a workaround that will not survive.
- Should I host the site here at all if I want an assistant?
- If Google Sites is right for you for other reasons, an embed block on a support page is a reasonable compromise. If the assistant is meant to catch questions anywhere on the site, be honest with yourself: you are choosing a host that cannot do that, and moving the pages is the cheaper fix.
- Can it still read my Google Sites content as source material?
- Yes, and this is worth separating from the install. If the site is publicly reachable, a crawl reads those pages the way a visitor would. You can have an assistant on another site answering from your Google Sites content even where the widget itself cannot be installed there.
- Will the box look like part of my page?
- Only as far as the space you give it. The panel inside the frame renders on its own terms and cannot inherit anything from your Google Sites theme, so budget for it looking like an embedded application rather than like a section of the page.
Keep reading
- Install on WebflowProject settings, then the Custom code section, then the field for code before the closing body tag.
- Install on SquarespaceSettings, then Advanced, then Code Injection, then the Footer field.
- Install on WixSettings, then Custom Code, then a new snippet applied to all pages and placed at Body end.
- Every install guideThe same one line of HTML, and where it goes on each platform.
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.