Install guide
Adding a chat assistant to a WordPress site
WordPress gives you a hook that fires just before the closing body tag on every front end page, which is exactly where this belongs. Using the hook instead of a template file is what keeps the widget alive through theme updates, and it is the only route that works at all on a block theme.
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 WordPress
A code snippets plugin, or a small plugin of your own, hooking wp_footer. Not Appearance, then the theme file editor.
Any WordPress install where you can add a plugin or drop a file into the plugins folder. On WordPress.com you need a plan that permits plugins or custom code; the entry tiers do not, and the theme editor is not an alternative there.
Step by step
- 1Install a code snippets plugin, or create a small plugin of your own with a header comment and one function if you would rather not add a dependency.
- 2Add a snippet that runs on the front end only, and have it echo the tag on the wp_footer hook so it prints immediately before the closing body tag.
- 3Save and activate it. Every correctly built theme calls wp_footer, so one snippet covers posts, pages, archives, the search results template and the 404 page in one go.
- 4If a caching or optimisation plugin is active, add the loader to its script exclusion list before you test anything, otherwise you will be debugging that plugin rather than the install.
- 5Purge the page cache, the object cache if you run one, and any content network sitting in front of the site.
- 6Open the front page in a private window. If the launcher is missing, view source and search for data-key before looking anywhere else: that tells you whether the problem is the snippet or the allowlist.
What goes wrong on WordPress
The theme file editor is a trap, and block themes do not even offer one
Pasting the tag into the parent theme's footer.php works until the theme updates, at which point that file is replaced wholesale and the tag goes with it. Nothing warns you, nothing logs it, and the symptom is a widget that ran for months and then stopped on a day you did not touch it. A child theme softens this but does not solve it, because you are still maintaining a template file to hold one line.
Block themes remove the option entirely. A block theme has no footer.php, because the footer is a template part rendered from the site editor rather than a PHP file. The hook still fires, so the snippet route works identically on classic and block themes, which is the real argument for using it.
Optimisation plugins rewrite or delay third-party tags
The popular caching and minification plugins all offer to combine scripts, defer them, or hold them until the first user interaction. Two things go wrong. A combine or rewrite pass can move the tag into a bundled file and drop the data-key attribute on the way, and the loader then logs a console warning and renders nothing. A delay until interaction rule means the launcher never appears for a visitor who reads the page and leaves without scrolling or clicking.
Both are fixed the same way: add the loader to the exclusion list in whichever plugin is doing it. If you run more than one optimisation plugin, and many sites do without realising, you have to exclude it in each of them.
On multisite, a snippet is per site, not per network
Network activating a snippets plugin makes the plugin available everywhere, but the snippets themselves live in each site's own tables. Adding one on the main site does nothing for the subsites, which is usually a surprise rather than a decision.
The reverse mistake is worse. Rolling the same key out across every site in the network points all those visitors at one assistant that indexed one site's material, so a visitor on a subsite gets confidently sourced answers about a different site. Give each site its own key, or install only on the sites whose content you actually indexed.
Origins to allowlist
These are the origins a WordPress site is typically served from. List every one you want the assistant to answer on, including the ones only you visit.
- https://yourdomain.com
- https://www.yourdomain.com
- https://staging.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.
| 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 WordPress 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 WordPress that depends on what kind of site this is. These go one level further than this guide.
- For a law firmFee tables hidden in page builder accordions, a client area the widget must stay out of, and costs documents published as files rather than pages.
- For a dental clinicThe booking software sits in a frame served from another origin, and the cancellation terms live inside it. What that leaves the assistant able to answer.
- For a medical practiceWho actually does the install when a supplier owns the site, keeping the launcher off the consultation form, and branch sites that need their own entry.
- For a restaurantMenus published as files, dishes marked with icons instead of words, and a reservation flow that finishes on a booking platform's own domain.
- For a plumbing and heating firmA page for every town you cover pulls answers to the wrong area, the rate card is a graphic, and a sticky call bar sits where the launcher does.
- For a estate agencyListings arrive from a feed into custom fields and tabs, so the particulars are not in the text a crawl reads. Point it at the process pages instead.
- For a private schoolThe fee schedule and prospectus are gated files, the parent portal is a separate origin, and safeguarding decides where the launcher may appear.
- For a universityNetwork activation puts the tag on every departmental site at once, including a conference microsite from years ago and a lecturer's personal blog.
- For a veterinary clinicA vet site on WordPress hangs half its material off other origins: the practice management form, the out of hours provider, and a fee list nothing links to.
- For a gymThe timetable block is filled in the browser, so a crawl of it reads an empty box. The notice period is in a PDF. Both decide what a gym assistant can say.
- For a garden centreWordPress keeps every seasonal post at its own address forever, so a crawl reads April's advice in November. In this trade that is not stale, it is wrong.
- For a accounting firmDeadline and threshold posts stay live at permanent addresses. In this trade an old figure quoted with a citation reads as advice, not as a stale tip.
- For a hotelRooms, the restaurant and the spa each book somewhere else with their own notice period. One footer hook covers all three and the terms are on none.
Taking it off again
Deactivate or delete the snippet, or deactivate the small plugin you wrote. Then purge every cache again, because a cached page still carries the old markup for as long as it lives.
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 to install a plugin from the directory to use this?
- No. The install is one script tag, and any route that prints it into the front end will do: a snippets plugin, a few lines in a plugin of your own, or a functions file in a child theme. A snippets plugin is recommended only because it survives theme changes and is easy for a colleague to find later.
- Why did the widget disappear after a theme update?
- Because the tag was in a theme file. An update replaces the theme's own templates, footer.php included, and takes anything you added by hand with it. Move the tag to a wp_footer snippet and the next update cannot touch it.
- Can I show it on some pages and not others?
- Yes. The snippet is ordinary PHP, so you can return early on the pages you want to skip using the usual conditional tags for a single post, a page, or an archive. Keep the logic in one place rather than adding a second snippet for the exceptions.
- What should a WordPress site index?
- Point it at your own site and let the crawl follow your links, then add the documents that never made it onto a page: the policy files, the price list, the onboarding notes people email out. The pages you already wrote to answer questions are the pages that answer them well.
Keep reading
- Install on GhostSettings, then Code injection, then the Site Footer box. The alternative is default.hbs in a custom theme.
- Install on DrupalA small custom module attaching a library, an asset injection contributed module, or html.html.twig in a custom theme. Not a custom block.
- Install on JoomlaThe Templates screen, under System in Joomla 4 and 5 and under Extensions in Joomla 3, editing index.php in a copy of your template. Or a Custom module in a footer position.
- 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.