An AI answer bar for your site or help center

A search box on your page, not a floating bubble

The chat widget floats a launcher in the corner and waits to be opened. The AI search bar is the opposite: a search box embedded directly in your page, sitting inline wherever a search field belongs rather than hovering above the content as an overlay. It's the same agent and the same knowledge, presented as a different surface for a different moment.

That moment is someone already reading. A person who opens a chat bubble expects a back-and-forth. A person who clicks into a search box expects to type a few words and read an answer. The intent is different, so the surface should be too. The AI search bar is built for the second person: someone already in your help center or docs who wants the answer to one specific question and would rather not start a conversation to get it.

That habit shows up most on pages where people arrive already looking for something. On a documentation site, a knowledge base, or a support portal, the visitor has a task in mind and a search box is the first thing they reach for. Meeting that habit with a real answer, instead of a ranked list of articles they still have to open and skim, is what the search bar is built to do.

What an inline answer actually means

Type a question and the bar returns one direct, written answer, composed from your own content and shown right there in the box. It streams in as it is generated, so the reader starts seeing the response within moments rather than waiting on a page of results. There is no list of blue links to work through and nothing to click before the answer arrives: the written answer is the whole response, and someone who only needed one paragraph has it without opening anything.

That is the core difference from ordinary site search. Traditional search hands back links ranked by relevance and leaves the reading to the visitor. The AI search bar does the reading for them and writes back the part that answers the question, grounded in the pages you have given it.

One knowledge base behind both surfaces

Because it reads from the same knowledge base as your chat agent, you keep one set of content, not two. Crawl your site, upload your PDFs, add your FAQs once, and both the search bar and the chat widget answer from it. When you correct an article, both surfaces reflect the correction. There is no separate search index to groom and no second copy of the truth to keep in step.

A docs page and a marketing page ask different things

Where you drop the bar changes the questions it gets. In a help center or docs site the visitor is usually mid-task and types like it: "rotate an API key," "set up SAML," "export to CSV." The queries are narrow and precise, a good answer is often a single step or a line of config, and the reader wants to stay on the page and get back to work. On a marketing or pricing page the visitor is still deciding. The queries run broader — "do you support inbound calls," "how does billing work" — the useful answer is shorter and points to the page that covers it, and it more often ends by handing the visitor to a person than by closing the question. Same bar, same knowledge base; the shape of a good answer shifts with where the reader is standing.

When to reach for search, and when for chat

Neither surface replaces the other; they fit different moments. Use the search bar where reading is already the mode, like a docs site, a help center, or a long knowledge article, and where the visitor wants a fast, self-serve answer. Use the website chat widget where the visitor is likely to have a follow-up, wants to be walked through something, or needs the agent to take an action for them.

Because both read from the same place, you are never deciding which questions get good answers, only which shape of interaction fits the page. Running both is a reasonable default: the search bar in the help center, the chat widget everywhere else, each drawing on the same content.

Add it with one script tag

The search bar embeds the same way the chat widget does — one script tag — but with data-mode="search" set, so the agent mounts inline instead of as a floating launcher:

<script
  src="https://app.evoriqa.com/widget.js"
  data-chatbot-id="YOUR_CHATBOT_ID"
  data-mode="search"
  data-target="#site-search"
  async
></script>

data-target is a CSS selector for the element the bar mounts into — point it at an empty container where you want the search box to appear, like a #site-search div in your help-center header. Leave data-target off and the bar mounts right where you place the script instead. Your data-chatbot-id comes from the Install tab with the value already filled in, and the bar takes its accent color and placeholder wording from the chatbot's settings, so it reads as part of your site rather than a bolted-on tool. If you don't have a workspace yet, create one free at app.evoriqa.com, no credit card needed, and the snippet is generated for you the moment your first agent exists.

When a lookup turns into a conversation

Some questions start as a lookup and become a request. Someone searches for your refund window, reads the answer, and then wants to actually start a return. The search bar is built for the lookup — a fast fact, then back to reading. When the moment turns into something the agent should discuss or do step by step, that is chat's job, and the agent there can act on the visitor's behalf. A common setup is to run both surfaces on the same pages: the search bar for the quick answer, the chat widget in the corner for the visitor who needs to keep going, each backed by the same knowledge.

When the answer isn't in your content

Sometimes the answer genuinely is not in what you have given it. A grounded agent handles that by saying so — telling the reader it doesn't have that answer — rather than padding a few loosely related passages into something that reads like one. That restraint is the point: a confident wrong answer in a search box costs more trust than an honest "I don't know."

Those misses are worth something, too. Because the search bar runs on the same knowledge base as every other channel, the questions it couldn't answer are recorded alongside the rest. Evoriqa's knowledge-gap detection turns recurring misses into candidate FAQs you can review and publish, so the questions your visitors type shape what the knowledge base covers next.

Putting it on your pages

Placement is a design choice you make; the answering is handled for you. The bar sits well in a help-center header, on a docs landing page, or anywhere a search box already belongs, and because it takes your brand it reads as native to the page rather than an add-on. You choose where it goes and set how it looks in the chatbot's settings.

Quiet support work happens here too. The search bar answers the routine "where do I find" and "how do I" questions on the page a visitor is already reading, before those questions turn into tickets. That makes it a natural part of the effort to deflect repetitive tickets: the answer someone would have emailed you for is right there in the box, drawn from the same content your agent uses on every other channel.