Notion and developer tools company
Documentation you cannot put a launcher on, and two public copies of it
A workspace makes a comfortable documentation site and an awkward place to stand a widget, because a page published straight from it serves markup you do not control and takes no script on any plan. The consequence for this trade is specific and unkind. The reader an assistant exists for on a documentation site is the one who has already failed the search box, and on this platform that reader is inside the docs, where there is nothing to open.
Why this pairing is its own job
The Notion install guide covers the tag, and the developer tools company guide covers what the assistant has to know. What follows is the part that belongs to neither.
- The launcher can only exist where something else serves your content on your own domain. Where the documentation is published directly, the assistant ends up on the marketing site, answering documentation questions for the people who have not opened the documentation.
- The search that reader just failed is weaker here than the one shipped with a documentation generator, so the failure that creates the demand happens more often, at precisely the address the widget cannot reach.
- Two public copies of the same tree exist the moment a domain goes in front. Only one of them can carry a launcher, both are readable by a crawl, and developers pin whichever link they were handed rather than whichever one you now prefer.
- There are no version paths to filter on. Every other toolchain this trade uses puts a release into the address, which is what makes a crawl exclusion writable at all. A workspace offers a tree of pages instead, so scoping the corpus becomes a question about what is published and what links to what.
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 Notion guide. Everything below is about where it goes on a developer tools company site specifically.
The install is a question about how the documentation is served
There is nowhere in a published workspace page to put a script, on any plan, so the real decision is whether the documentation goes out through something that has a code field. That is a decision about your documentation stack and it deserves to be taken on its own merits rather than to accommodate a launcher.
If the answer is no, be explicit about what you are buying: an assistant on the marketing and product pages, reading the documentation, answering people who have not opened it yet. That is worth something. It is not what a documentation assistant is usually for.
If the answer is yes, the origins to list are your domain, the www form of it, and whatever preview address that layer served on before the domain was attached.
Retire one of the two public copies before the first crawl
Once your own domain serves the tree, the address the workspace publishes on is a complete second copy of your documentation with no launcher on it. It is still served, still crawlable, still linkable, and every link to it you have ever handed out still resolves.
Decide which of the two you support, stop giving out the other, and keep the retired one out of the material. A citation is a link the reader will open, so a corpus containing the copy you do not maintain quietly hands readers back to it.
Scope the corpus by what is published, not by a path pattern
A crawl follows links from where you point it, so the corpus is whatever your published root reaches. There is no release segment in the address to exclude, which means the usual move on a documentation site is simply unavailable and the equivalent work is structural.
Unshipped material is the sharpest case. A page describing a signature nobody can call yet, sitting as a sibling of the reference, reads exactly like the reference. Keep it out of the published tree rather than out of the crawl, because a filter you cannot express in an address is a filter somebody has to maintain by hand every week.
Then check what an anonymous reader reaches, in a private window, before pointing anything at it. What they can open is what the crawl reads, and the two lists are never quite the one you expected.
Where the answerable material lives
| The reference tree for the release you support | And an explicit note of which sibling pages are not it. With no version segment in the address there is nothing structural keeping an older reference out, so the separation has to survive as a decision about which pages exist under the published root at all. |
|---|---|
| Release notes held as a database, where a row is a page | Every published row is a page a crawl can reach, including the entries for work that has not shipped. This is the highest value support material a developer tools company owns and the place where the released and the unreleased sit closest together. |
| The error and status code reference | Developers paste the error rather than searching for the concept behind it. The code, the plain explanation and the usual causes on one page is what lets the assistant beat a search box that has already failed the reader once. |
| The pages that are in the workspace and not on the site | Runbooks, on call notes, the design discussions. They are not published, so they are not read, and the right thing to do about that is nothing. Uploading them makes them answerable and citable to anybody who opens the widget, which includes everybody. |
The first thing to get right
Open the address the workspace publishes on in a private window, read what a stranger gets, and decide which of your two public copies you support.
Both are indexable and only one can ever carry a launcher, so this settles where the assistant lives, which addresses your citations point at, and which copy a reader lands on when they follow one. It is also the cheapest item here, because the work is deciding rather than building.
The failure that belongs to this combination
A citation that sends the reader to the copy with no launcher
The assistant answers a question about a method and cites the page it read, and the citation is the address the workspace publishes on rather than the documentation on your domain, because that is what the crawl was pointed at or what a link led it to.
The reader follows it, which is what a citation is for on a documentation site. They land on a page that looks right, has no launcher, and may not have been refreshed since the last time that layer synchronised. Where the two copies have drifted, the answer they were given and the page they are now reading disagree, and nothing tells them which is current.
Point the crawl at the domain you support, leave the other out, and read the citations on three test questions before believing any of it. The address inside a citation is the only observable evidence of which copy the corpus is holding.
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 developer tools 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
- Can we put the tag on the published workspace page itself?
- No. Those pages are served as the platform's own markup, and a script pasted into a page is treated as content rather than run. No plan, block type or setting changes it, and any route that appears to work is one that stops at the next platform update.
- Can it read our documentation even though it cannot appear on it?
- Yes, where the pages are public, and that is the arrangement worth planning around. Keep the writing where your team writes, put the assistant where your visitors are, and let it answer from the tree. What you lose is the reader already inside the documentation, who on this trade is the reader who needed it most.
- How do we stop it answering from an older release?
- Not with a path filter, because there is no version in the address to filter on. What you have is which pages exist under the published root, what your navigation links to, and a threshold high enough that a weak match refuses. Then test it: ask about something you removed and read which page the citation names.
Keep reading
- Installing on NotionPages published straight from Notion cannot run a script tag. The install belongs to the hosting layer serving your content on your domain.
- Everything for a developer tools companyOn a docs site an assistant competes with search, not a phone line. Version skew, deprecations and error strings decide whether it earns its place.
- Sharing settings decide what a course assistant is able to quotePublishing a page publishes what sits beneath it. For a course provider that can turn the lessons people paid for into readable material.
- 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.
- What happens to the assistant when each release is its own MkDocs buildEvery release is deployed as its own static copy. Older ones were built before you added the override, so they carry no tag and cannot get one.
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.