Blog · Updated 2026-08-18 · 5 min
How to add a cited support widget to your docs site
Most teams paste a chatbot script and hope the crawl worked. A docs widget should do three things on day one: answer from pages you actually published, show the source, and send people to the help center when they want to read. This is the setup path we use with usedocs — crawl, test, embed, watch gaps. Skip any of those steps and you will launch a fluent bot on a thin index.
What you are installing
A cited support widget is not a site-wide search box and it is not a tab that only redirects. Visitors ask a question in chat. The answer streams with source links. If they want the full article, a header icon opens the published help center in a new tab.
That split matters. Chat is for synthesis (“why did my webhook retry?”). The help center is for reading. Mixing those into three empty tabs made the widget feel unfinished. Keep chat in the panel; keep docs one click away.
usedocs follows that shape: cited answers in the widget, a help-center link in the header, and a refusal when the docs do not contain the fact. Gaps from those refusals become drafts. A human still publishes.
Step 1 — Point the crawl at the right scope
Start with the public docs origin or sitemap, not the marketing homepage. If you only need a section (for example /docs/api), say so. Crawling the whole product site pulls login shells, pricing experiments, and blog posts that share keywords with the real reference.
Checklist:
- Prefer https://docs.example.com or /docs over the root domain.
- Confirm the sitemap lists the pages you care about (/tools/sitemap-finder).
- Skip app routes such as /login, /dashboard, and /admin — they are not customer answers.
- Upload PDF/Markdown only for policies that are not already HTML.
- Recrawl after a large docs rewrite so the index matches what you just shipped.
In usedocs, add the URL under Knowledge, wait for the index, and open Coverage if pages failed. A red crawl is cheaper to fix than a live bot quoting a 404.
Step 2 — Test before the script tag
Use the dashboard test chat with questions from real tickets. Inspect the citation. If the title is wrong, fix the source or the question set — do not embed yet.
Minimum set:
- Two “getting started” questions a new user would ask.
- Two technical questions (auth, webhook, rate limit, or SDK).
- One billing or plan question.
- Two questions you know are missing from the docs.
On the missing pair, the bot should decline. If it invents a path, you are not ready to go live. See /blog/why-docs-chatbots-hallucinate for the scoring rubric.
A first pass on public coverage is the gap-audit tool: /tools/gap-audit
Step 3 — Embed on the docs host only at first
Copy the snippet from Bot settings. Paste it before the closing body tag on the docs host. Set Allowed origins to that exact origin (https://docs.example.com), not *.
If you use a public bot key, put it on the script tag and rotate it if the snippet leaks. Keep usedocs branding on Free; remove it on Pro when the widget should look native.
Launch on docs first. Marketing-site chat attracts “what is this product?” questions your API reference cannot answer. Add the marketing origin later if you want, after the help center has a getting-started article.
Step 4 — Connect the help center link
Publish at least a thin help center so the header icon has somewhere to go. Categories, a getting-started article, and the pages you already crawled are enough. Business plans can map a custom domain; everyone else gets a /help/{slug} path on usedocs.app.
The widget does not try to be a docs reader. It chats, cites, and hands the visitor a clean exit to the article. That is the behavior you should show in a launch screenshot: one composer, one answer, one source chip, one external-link icon.
If you already have GitBook, Mintlify, or a custom portal, keep it. Crawl that origin. usedocs can host extra support articles or sit beside the portal you already maintain.
Step 5 — Watch gaps for a week, then write
After seven days, open Monitor → Content gaps. You will see the questions the bot refused or answered poorly, clustered. Draft those as help articles. A human still publishes. Then recrawl. The original question should now cite the new page.
That week is also when you decide office hours, Slack handoff, and lead capture. Do not turn every miss into a sales form on day one. Earn the right to interrupt after the answers are faithful.
Auto-publishing model text is how a fluent error becomes the official answer. Gaps become drafts, not live pages.
Start free (100 messages, no credit card) at /dashboard — or book 15 minutes if you want the crawl reviewed live: /book-a-demo
Plans if you outgrow Free
Free is 100 messages per month. That is enough to crawl, test ten questions, and watch a week of real traffic. When you need more volume or to drop branding:
- Pro is $29 for 5,000 messages.
- Growth is $79.
- Business is $299.
The product loop does not change by plan: cited answers, refuse when the docs are missing, draft the gap, human publish.
FAQ
How long does a first crawl take?
Small public docs sites usually index in minutes. Large portals or slow sitemaps take longer. Do not embed until the pages you tested are in Coverage.
Can I put the widget on my app and my docs site?
Yes. Add each origin to the allowlist. Start with docs so implementation questions hit the right index.
Does the widget include a docs search tab?
No. Chat is the only panel. Visitors open the published help center from a header link when they want to read.
What if we already have Mintlify, GitBook, or a custom portal?
Keep it. Crawl that origin. usedocs answers from those pages and can host extra help articles if you want a support-specific CMS.
Do we need a credit card to try this?
No. Free includes 100 messages each month. Paid plans raise message caps and can remove branding. Pro is $29 for 5,000 messages.
How do I keep the bot off staging?
Do not add staging origins to the allowlist. Use a separate bot if you need a preview embed.