How to add one search across multiple documentation sites
By the end of this guide you will have one search experience running across several documentation properties (say, a Docusaurus docs site, a Sphinx API reference, and a Zendesk knowledge base), without migrating any content. Every site carries the same widget, every widget searches all three sources, and you get one analytics view across all of them.
Time required: about 30 minutes, most of it waiting for the first crawl to finish.
Before you start
Make an inventory of everywhere your documentation actually lives. The point of unified search is that a reader on any one property finds answers from all of them, so the inventory is the spec for what to index. Typical setups include:
- The main docs site (Docusaurus, MkDocs, Sphinx, Starlight, Hugo, Antora)
- An API reference on its own subdomain
- A knowledge base (Zendesk, Freshdesk, Document360)
- Internal content (Confluence, Notion, GitHub repos: see the note in Step 2)
- Tutorials, an academy, or a technical blog
You will need a Biel.ai account (the 14-day trial needs no credit card) and edit access to each site you want the widget on. If you can paste a script tag into a theme or install an npm or pip package, you have enough access.
Step 1: Create one project, not one per site
Create a single project in the Biel.ai dashboard, and add every site to it as a source. This is the decision the whole setup hangs on: one project is one index, and one index is one set of answers everywhere. Per-site projects would recreate exactly the fragmentation you are trying to remove.
A project is the container for sources, the search and chat widget, and the analytics for one product. Sites are not separate projects; they are separate sources inside the same project. Name the project after the product, not after any single site.
Step 2: Add each documentation site as a source
Add each property as a source by pasting its URL: Biel.ai crawls the site, splits the pages into chunks, and indexes them. A source is one crawlable web property feeding the shared index. Repeat once per property, and they all land in the same index.
Search indexes any HTML site it can crawl: public docs sites, KB portals, marketing pages, and anything else served as web pages. You do not move or re-host the content; the original sites stay exactly where they are.
Private content behind a login? If part of your documentation lives behind authentication (Confluence, Notion, an internal wiki), contact support and we will look at your setup.
Two settings are worth attention while the first crawl runs:
- Exclusions. Exclude archived versions and legacy pages you do not want surfacing in results. Stale content is the single most common cause of bad results in multi-site setups, because an old page that still ranks will happily answer a question the new docs already corrected.
- Refresh schedule. Sources recrawl automatically; how often depends on your plan rather than a per-source toggle. If your docs change daily, check what your plan's refresh frequency includes before you rely on same-day updates.
The full list of source types and crawl options lives in the Biel.ai sources documentation.
Step 3: Install the widget on every site
Install the widget on each site using that platform's native method, and point every install at the same project ID. The project ID is what binds the widgets together: a widget carrying it searches the whole shared index, no matter which site it sits on.
| Platform | Install method |
|---|---|
| Docusaurus | The docusaurus-biel plugin (npm) |
| Sphinx | The sphinx-biel extension (pip) |
| MkDocs, Starlight, Hugo, Antora, Jekyll | A template override or embed snippet |
| Zendesk, Document360, ReadMe, hosted platforms | A script tag in the theme's custom-code slot |
Because every widget shares the project ID, a reader on the API reference who searches for a concept gets results from the main docs site, and the result link carries them straight across. The seam between two properties stops being a dead end.
Step 4: Test the seams, not the home turf
Test the cross-property paths, not searches for content that already lives on the site you are standing on. Per-site search handled those long before you arrived; the only thing unified search adds is answers that cross a property boundary, so that is what to verify.
- From the docs site, search for an error message documented only in the knowledge base.
- From the knowledge base, search for a concept covered only in the docs.
- From the API reference, search for a tutorial topic and confirm the result link carries you to the right site.
If a seam test returns nothing, the cause is almost always an indexing gap rather than a search bug. Check that source's crawl status and its exclusion rules: a page you meant to keep was probably excluded, or the crawl has not reached it yet.
Step 5: Turn on the cross-site extras
Once one index is in place, three capabilities come with little extra setup, because they all read from the same source pool.
- AI chatbot. The same index can power a chat assistant that takes full questions in plain language ("how do I authenticate, and what is the rate limit?") and answers from every source, citing the pages it drew on. If you are weighing search against chat, the two are complements: see why an Ask AI button bridges search and chat in documentation for how readers move between them.
- MCP server (Professional plan and up). MCP (Model Context Protocol) is the open standard that lets AI tools query an external source. With it, the multi-site index becomes queryable from Claude, Cursor, and Copilot, so your developers ask in their IDE and get answers drawn from every property.
- Content-gap analytics. One report shows what readers searched for and did not find, across all sites, including searches run on the "wrong" site that per-site analytics structurally never see. Those misses are the clearest signal of where to write next; for what to do with them, see how to improve the user experience of AI chatbots on a documentation site.
What this looks like at scale
The largest Biel.ai deployments run this exact architecture across as many as 22 documentation sites: one search experience, the same results no matter which property a reader starts from, and the same index serving developers over MCP. Adding a twenty-third site is one more source in the same project, not a new search to maintain.
Yours is probably smaller, and the shape is identical: one project, every site as a source, one widget everywhere. The setup does not change with the count; only the inventory in Step 1 grows.
Frequently asked questions
Do I need a separate Biel.ai project for each documentation site?
No. Use one project and add each site as a source inside it. One project is one index, which is what makes a single search return answers from every property. Separate projects would split the index and bring back the fragmentation you are removing.
Does unified search move or re-host my documentation?
No. Biel.ai crawls each site in place and indexes the content; the original sites stay where they are, on their own platforms and domains. You change nothing about how the docs are hosted or published.
How do I keep stale pages from appearing in results?
Use the exclusion rules on each source to drop archived versions and legacy pages. Old content that still ranks is the most common cause of wrong answers in multi-site setups, so excluding it is the highest-value cleanup you can do.
Can developers query the combined index from their IDE?
Yes, on the Professional plan and up, through the MCP server. The multi-site index becomes queryable from Claude, Cursor, and Copilot, so developers get answers drawn from every property without leaving their editor.
Get started
Set up one project, add your sites as sources, and run your own seam tests: those few minutes are what tell you whether unified search earns its place. Start a free 14-day trial and index your first two sites.