Bubble and healthtech app
A Bubble health app has no page the widget can be kept off
Bubble puts third party tags in one field that applies to the app. A health product built on Bubble usually has its marketing pages and its signed in product inside that same app, so the field installs the launcher on both and there is no template layer to route around it. The second half is that a crawl of a Bubble app reads very little, because the pages are assembled in the browser.
Why this pairing is its own job
The Bubble install guide covers the tag, and the healthtech app guide covers what the assistant has to know. What follows is the part that belongs to neither.
- The script field is app wide. There is no per page footer and no template inheritance, so the same tag is on the landing page and on whatever a signed in user is currently looking at.
- The app does not reload the document as somebody moves around it, so the boundary between the public pages and the product is not a page load at all. Whatever installed at the start of the session is still installed after they sign in.
- Pages are assembled in the browser from data fetched after load. A crawl receives a shell rather than your copy, so the marketing material you expected the assistant to answer from may never reach the material.
- Health data is a special category, and a chat box sitting on a screen showing somebody their own information invites precisely the message it must not receive.
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 Bubble guide. Everything below is about where it goes on a healthtech app site specifically.
There is no route off the signed in pages from that field
Say this plainly before planning around it. Settings, then the SEO and metatags tab, then the body script field: that is the entire surface. It takes no conditions, it does not vary by page, and there is no layout file underneath it to branch on.
So the options are structural. Keep the marketing site as a separate app or on its own address and install only there. Or accept the launcher inside the product and write the refusal on the assumption that the person typing is signed in and looking at their own data.
The second option is defensible where the signed in area holds nothing clinical. It is not defensible where it does, and that judgement belongs to whoever owns your clinical safety case rather than to whoever pastes the tag.
A crawl of a Bubble app is not a crawl of your copy
The page is built in the browser from data fetched after load. A crawl asks for the address and reads what comes back, which is a document that does not yet contain your headings, your explanation of what the product does, or your privacy summary.
The result is an assistant with almost no material and a very high refusal rate, which reads as a broken product and is not one. The answer is not to argue with the crawl. Upload the documents instead: the scope statement, the privacy notice, the governance pack, the access and eligibility page. Those are the real answers anyway and they arrive intact as uploads.
Where you do want pages read as pages, publish the ones that matter on something that serves them as HTML and point the crawl at that address, adding it to the allowlist alongside the app.
Two versions, one address, one deploy
The development version is served under a version test path on the same address as the live app, so one allowlist entry covers both and the widget behaves identically on each. Convenient, and the reason people believe a change is live when it is not.
Editing the field changes the development version only. The live app keeps the previous field until you deploy, and a missing tag looks exactly like a refused origin. Check the live page source before you check the key or the allowlist.
Where the answerable material lives
| The scope statement, uploaded | What the product is for and what it does not claim. Uploaded rather than crawled, because on this platform the crawl is the unreliable route and this is the document every other answer inherits from. |
|---|---|
| Privacy notice and governance pack | Who sees what, retention, whether an employer or insurer receives anything, plus the assessment documents an organisation buyer asks for. Documents you already maintain, uploaded as they stand. |
| Access and eligibility | Countries, age ranges, whether access arrives through an employer or directly, and what somebody does when their organisation is not signed up. Purely administrative and completely safe to automate. |
| Anything inside the app | Out of reach entirely. The assistant cannot read your app's data, and the screens a user sees after signing in are built from that data, so there is nothing for a crawl to read and nothing to connect it to. |
The first thing to get right
Write the crisis and emergency wording into the refusal message before you paste the tag into the field.
One save and one deploy installs the launcher across the whole app, including the screens a signed in user reaches, and there is no way to stage that on this platform. The refusal is the only part of the first reply you get to author in advance, and on a health product the first reply is the one that has to be right.
The failure that belongs to this combination
The launcher arrived on the product screens the moment it was deployed
On a platform with templates you can stage this: public layout first, the signed in area later, once somebody senior has thought about it. Bubble gives you one field and one deploy, so the decision about the product screens is made by the same click that installs the marketing launcher.
The visible result is a chat box on a screen where somebody is looking at their own health information. What they type into it is a health disclosure into a channel that is not part of your product, does not reach a clinician, and answers from marketing pages.
Decide first and install second. If the conclusion is that the marketing site should be a separate app, make it separate before the tag exists rather than after somebody has already typed a symptom into the panel.
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 healthtech app 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
- Can we show it only to signed out visitors?
- Not from that field, which is the whole point of this page. Anything conditional would have to be built as page logic that inserts the tag, at which point you are maintaining install logic inside the app. Separating the marketing site is the cleaner answer and usually the cheaper one.
- Our marketing pages are in the app and the crawl found nothing. What now?
- That is expected rather than a fault, because those pages are assembled in the browser. Upload the same content as documents, or publish the marketing pages somewhere that serves HTML. Either way the assistant ends up with better material than a crawl of an app would have given it.
- Can it look up whether somebody has an account?
- No, and it must not appear to. It has no access to your app's data and cannot confirm or deny anything about a named person. In this trade even a denial can disclose, so write the refusal to decline discussing individuals as a category rather than to report that it could not find them.
Keep reading
- Installing on BubbleBubble takes the tag in its SEO and metatags settings. Put it in the body field, deploy to live, and allowlist both app addresses.
- Everything for a healthtech appHealth data is a special category and clinical claims carry device rules. What a healthtech assistant answers for patients, and for buyers.
- Where the widget has to stop on a Django health productThe base template is shared with the signed in area, and the content security policy decides whether any third party script runs.
- Where the message goes once somebody has described their symptomsA help centre is where somebody describes their symptoms to explain a problem, and the handover emails that description to whichever inbox you nominated.
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.