Our public site and our client area are separate deployments on one domain. Where does the tag go?

In the public one, unless somebody has a reason for the other. They share an origin, so the allowlist is satisfied for both whatever you decide, and the choice therefore lives entirely in the templates. A client area is where somebody reads their own documents, and nearly every question typed there is one the assistant has to hand over.

How often does the material need re-reading after the site changes?

Whenever a release changes wording you would want quoted. The corpus is a copy of what was read, so a revised fee disclosure or a rewritten product page exists on the site and not in the material until a crawl runs again. Treat the re-index as part of shipping a wording change rather than as maintenance.

Somebody asks whether a loss is covered and the words are technically on our site. What then?

It refuses and hands over. Cover depends on the wording, the schedule, the endorsements and whether the conditions were met, none of which the assistant has and none of which belong in a corpus. Raise the caution setting so a coverage question falls below the threshold and returns your refusal instead of the nearest product page.

Spring Boot and insurance broker

When installing the widget is a release, and rolling back is an uninstall

A broking site built this way is not a site anybody edits. It is a set of templates in a repository, packaged into an artifact and deployed, which means the widget arrives by the same route as a change to the quote engine, under the same approval, and leaves again the moment somebody reverts a release for reasons that had nothing to do with it.

Why this pairing is its own job

The Spring Boot install guide covers the tag, and the insurance broker guide covers what the assistant has to know. What follows is the part that belongs to neither.

The tag is a line in a template compiled into the deployable artifact. Whether it is on the site is therefore a property of which build is running, and there is no admin screen anywhere that will tell you.
Regulated firms revert releases. A rollback to the previous artifact takes the previous templates with it, and the widget disappears from the site with no console message, no refused origin, and nothing in any log that mentions it.
A broker commonly runs more than one application behind one hostname: public pages on one path, the client area or the quote journey on another, deployed separately. They share an origin, so the allowlist tells you nothing at all about which of them carries the tag.
Published wording moves at release cadence and indexed material does not move until somebody runs a crawl again. On a site where a fee disclosure and a product description are approved documents, that gap is the thing that needs managing.

What changes about the install here

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

The tag is the same one on the Spring Boot guide. Everything below is about where it goes on a insurance broker site specifically.

The install is a change to a build, so run it as one

The template lives in the repository, the artifact is built from it, and a running instance serves the templates it was built with. Nothing done on a server changes the page, which surprises anybody whose last install was a paste into an admin screen.

The consequence is that the widget goes through review, testing and release like any other change. For a regulated firm that is the correct outcome, and it is worth saying out loud to whoever was expecting it to be live this afternoon.

A rollback is an uninstall that nobody writes down

Reverting to the previous artifact removes the template line along with everything else in that release. The site keeps working, the launcher is simply absent, and because the deployment was about something entirely different, nobody connects the two events.

The signal is in the page source: no tag at all, rather than a tag that was refused. A refused origin puts a line in the browser console naming the origin. A missing tag writes nothing anywhere, because nothing ran.

Put the check in the release checklist instead of in somebody's memory. One look at the served page source after a deploy is enough, and it costs less than the afternoon somebody will otherwise spend on an assistant that appears to have stopped working.

One hostname can be two applications

Public pages and the client area are frequently separate deployments sharing a domain and routed by path. To a browser that is one origin, so the allowlist question gets answered once and proves nothing about coverage.

Work out which application serves which path before deciding the tag is installed. The arrangement most brokers want, public pages carrying it and the client area not, happens for free here, provided nobody adds it to the second template out of tidiness.

Where the answerable material lives

Source material on a Spring Boot insurance broker site
Product descriptions by class of business, served from the public templates	What each type of cover is for, written in the words a customer uses. These are pages, they carry their own text, and they let the assistant match a trade to a product class without going anywhere near whether a particular loss would be covered.
The fee and remuneration disclosure, which changes when a release goes out	Whether you charge a broker fee, on what, and whether it is refundable. Disclosure duties make that wording deliberate, and on this stack it lives in a template that changes with a deploy. The corpus holds whatever the crawl last read, so a release that revises it needs a re-index attached to it.
Policy wordings, which are documents attached to pages rather than pages	The wording, the summary document, the schedule. A page crawl gets the link and the file name. Here that is the right outcome rather than an obstacle, because the wordings are exactly the material a broker should not have an assistant reasoning from.
Cancellation, cooling off and mid term change terms	Fixed process answers to high volume questions: what a cancellation costs, how a refund is calculated, what happens to a policy adjusted part way through a term. They change rarely, which makes them the part of the corpus that stays true between re-indexes, and they take up a real share of a broker's telephone time.

The first thing to get right

Do this first

Add a look at the served page source to the release checklist, beside whatever else is verified after a deploy.

Every other problem on this pairing announces itself somewhere. A missing tag after a rollback does not: the application is healthy, the pages are correct, and the only symptom is that something signed off two months ago is no longer on the website. A five second check inside a list that already exists is the whole of the remedy.

The failure that belongs to this combination

The assistant removed by a release about something else entirely

A defect somewhere unrelated gets a rollback on a Friday. The previous artifact contains the previous templates, and the previous templates predate the install, so the launcher is gone from every page on the site.

Nothing reports it. There is no refused origin to find, because a refusal requires a tag that ran and there is no tag. The assistant's own half is untouched: the key is valid, the material is indexed, the allowlist is correct, and none of that is visible from the website because nothing on the website is asking.

It surfaces weeks later as a question about why enquiries fell, by which time the release that caused it is several deploys back. Read the page source first, and when the tag is not there, look at what shipped rather than at the assistant.

Before you go live

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.
Open the site as a visitor would, on the pages a insurance broker visitor actually lands on, and ask it something only your own material could answer. A widget that renders is not the same as a widget that has read anything.

Questions

Our public site and our client area are separate deployments on one domain. Where does the tag go?: In the public one, unless somebody has a reason for the other. They share an origin, so the allowlist is satisfied for both whatever you decide, and the choice therefore lives entirely in the templates. A client area is where somebody reads their own documents, and nearly every question typed there is one the assistant has to hand over.
How often does the material need re-reading after the site changes?: Whenever a release changes wording you would want quoted. The corpus is a copy of what was read, so a revised fee disclosure or a rewritten product page exists on the site and not in the material until a crawl runs again. Treat the re-index as part of shipping a wording change rather than as maintenance.
Somebody asks whether a loss is covered and the words are technically on our site. What then?: It refuses and hands over. Cover depends on the wording, the schedule, the endorsements and whether the conditions were met, none of which the assistant has and none of which belong in a corpus. Raise the caution setting so a coverage question falls below the threshold and returns your refusal instead of the nearest product 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