Docusaurus and SaaS company
One origin, two build systems, and a tag from each
The tidy version of a subscription business has the docs on their own subdomain, which is a separate origin and a separate install and gives everybody a clean line to work along. The common version does not. The docs are proxied under a path on the marketing domain so that search treats them as one property, which means one origin, one set of pages in the browser's eyes, and two entirely separate build systems each convinced it owns the layout. That is a pleasant arrangement for search and an awkward one for anything installed globally.
Why this pairing is its own job
The Docusaurus install guide covers the tag, and the SaaS company guide covers what the assistant has to know. What follows is the part that belongs to neither.
- A path proxy makes the allowlist question disappear and replaces it with a worse one. Docs and marketing pages answer on the same origin, so one entry covers both and nothing will ever be refused. What can happen instead is two tags on one page, one from the marketing layer that injects globally and one from the docs configuration.
- The loader installs once and ignores a second attempt, so two tags do not produce two launchers. They produce one, belonging to whichever loaded first, which means the docs pages may be running the marketing team's assistant with the marketing team's material and neither team has any reason to suspect it.
- Documentation is written to describe what the software does, not what a particular subscription entitles somebody to. That is correct editorial practice and it is also why a docs page will explain a capability in full without mentioning that it is not on the plan the reader is paying for.
- There is no ticket form, no login and no support widget on a documentation site, so the handover is the only route from the page to a person. On a subscription product the reader who has failed at the docs is frequently the reader with a billing problem, and this is the only door in the room.
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 Docusaurus guide. Everything below is about where it goes on a SaaS company site specifically.
Count the tags before you add one
Open a docs page on the live site and view the source rather than the inspector, then search it for the loader. Do the same on a marketing page. If the marketing layer injects globally at the edge or through a shared layout, the docs pages are already carrying a tag and adding an entry to the docs configuration produces a second one.
Two tags on a page is not an error and nothing will report it. The page loads, a launcher appears, and the only visible difference is which assistant answers, which nobody notices until somebody asks a docs question and gets a marketing answer.
If both are there, delete one deliberately rather than leaving the order of execution to decide. Which one you keep is the next question and it is a real one.
One assistant across both halves is usually the right answer
A reader on a documentation page asking what a feature costs does not know or care that they have crossed a build boundary, and neither does the browser. One assistant reading the docs and the pricing and trust pages together answers that question. Two assistants means the answer depends on which half of the site somebody happened to be standing on.
The reason this is worth stating is that the two halves usually have two owners, and the instinct is one each. On one origin that instinct cannot be satisfied anyway, because the loader will only install once per page, so the choice is not between one and two. It is between one that was chosen and one that won a race.
Hang the recrawl off the release, not off the calendar
Docs on this generator live in a repository and ship on merge, so the material changes whenever an engineer lands a pull request. That is a different rhythm from a marketing site, where somebody publishes deliberately and usually tells people.
A monthly recrawl on a calendar will therefore be wrong in both directions: idle for weeks, then several releases behind on the day a feature ships. Put the recrawl into whatever runs after a docs deploy, or at minimum into the release checklist beside the changelog entry.
It is also worth telling whoever owns support that the corpus moves this way. The assistant's answers change on an engineering cadence, and the first time somebody notices that usually involves an answer that was correct last week.
Where the answerable material lives
| A plan line in the page that documents the feature | One sentence on each feature page saying which subscriptions include it. Not only on the pricing page, because an answer is built from the passage that matched, and the passage that matched was about the feature. Putting the entitlement next to the capability is what stops the two being separated. |
|---|---|
| The trial rules in plain words | Whether a card is needed to start, what happens on the final day, whether data survives a lapsed trial, and who can extend one. The question underneath all of them is whether somebody is about to be charged, and an unanswered version of it produces a cancellation rather than a conversion. |
| Rate limits and quotas with the plan attached to each number | The figures as they are enforced, per subscription, and what actually happens when one is reached: blocked, throttled, queued or billed. A limit documented without its tier is a number that will be quoted to somebody it does not apply to. |
| The onboarding and migration guide | How data comes across from whatever they use now, what an administrator has to configure before inviting anybody, and what is realistically achievable on the first afternoon. This is the material that decides whether a new account goes quiet in week one, and it is usually the thinnest section of the docs. |
The first thing to get right
View the source of a docs page and count how many script tags on it carry a data key.
It takes ten seconds and it is the only way to find out whether the install you are about to do has already been done by another team. A launcher appears either way, so every other check passes, and the difference between the two states is which assistant and which material your documentation readers have been talking to. Nothing else on this pairing is hidden this well.
The failure that belongs to this combination
The documentation says yes and the subscription says no
A reader asks whether the product can do something. It can, and the docs describe it thoroughly, so the answer is a confident yes with a citation to a page that is entirely accurate about the software. What the page does not say, because documentation is not a price list, is that the capability is on a plan two tiers above the one the reader has.
The failure lands somewhere unusual. It is not a support ticket, it is a customer who follows the instructions, finds the option missing, and concludes either that the product is broken or that they have been misled. Both of those arrive angrier than an unanswered question would have.
This is not fixed by indexing the pricing page, although you should. The pricing page answers a pricing question, and this was a capability question that happened to have an entitlement inside it. The fix is in the docs: a line on the feature page naming the plans it belongs to, so the passage that gets retrieved carries the gate along with the capability.
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 SaaS company 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 docs are on a subdomain rather than a path. Does any of this apply?
- The duplicate tag problem goes away, because a subdomain is its own origin with its own pages and its own layout. Everything else stays: it needs its own allowlist entry, the entitlement gap in the docs is the same gap, and the recrawl still has to follow the release rather than the month.
- Two teams both want their own assistant. Can they have one each on the same domain?
- Not on the same page. The loader installs once and ignores anything after it, so a second tag is dead markup and the key that wins is whichever executed first. If the two really need separate material, split them by putting the docs on their own origin, which is a hosting decision rather than a widget one.
- Should we index the generated API reference?
- Usually not all of it. Reference pages generated from a specification are near identical by design, which gives retrieval hundreds of almost equal candidates and very little to choose between them. Index the guides, the limits and the concept pages, and let the reference do its job for readers who are already in it.
Keep reading
- Installing on DocusaurusAdd an object to the scripts array in docusaurus.config.js carrying the source, defer and the data key, then rebuild the site.
- Everything for a SaaS companyOne widget serves prospects, trialists and paying customers. What it can answer about plans and limits, and what has to reach a person.
- Indexing a versioned Docusaurus site without answering from the wrong releaseVersioned docs put several releases on separate paths. Which of them the crawl reads decides whether an answer is safe or an afternoon lost.
- A help centre on one domain and the commercial material on anotherThe help centre holds how-to articles. Plans, limits and trust pages live on your marketing site, a separate origin and a separate crawl.
- Keeping the widget on the marketing routes and out of the productThe root layout is the documented place for the tag, and on a subscription product it is also the signed in dashboard. Move it down a level.
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.