AI search for TYPO3 that answers what your visitors mean

TYPO3 is the CMS people choose when a site has to be large, multilingual, governed and long-lived. Councils run on it. So do universities, hospitals, ministries and the agencies that build for them. A ten-year-old TYPO3 site holds several hundred pages, written by a dozen editors across a dozen departments, each using the vocabulary of their own department. The information a visitor needs is nearly always on the site. The question is whether they can reach it.

The search box is supposed to be how they reach it, and on most of these sites it is the weakest part of the whole build. Indexed search, ke_search and Solr are all competent word engines, and every one of them rests on the same assumption: the visitor will type words that appear on your pages. That assumption is wrong for the people these sites exist to serve. A resident does not know the page is called "Waste and recycling collections". They type "my bin was not collected". A patient does not know the page is called "Outpatient appointment changes". They type "I need to move my appointment". The search finds no overlap and returns nothing.

An empty search result on a public sector site is expensive in a way that is easy to miss, because the cost does not land in the web team. It lands in the contact centre. The visitor who searched and found nothing does not try a second phrasing: they telephone, or they send an email, or they turn up at a counter. Every one of those is a staffed channel answering a question the website already answers. The search log shows a query that returned zero results, and almost nobody reads the search log.

The Asyntai AI Search Bar replaces the matching step with an understanding step. When a visitor types a question, the bar does not look for those words on your pages. It works out what the question means, then finds the pages that answer it. "The lift in the main building is broken" and "Report a building fault" share no words at all, and the bar connects them, because it is reasoning about the subject rather than comparing strings. That single change turns a large class of failed searches into answers, without anybody rewriting a page title or restructuring a page tree.

What visitors see is deliberately ordinary. They type into the search box in the place your site has always had one. Results appear underneath as they type, each with a title and a line of context, and each one a real link to a real page on your site. Arrow keys move through the list and Enter opens the highlighted result. There is no chat window to open and no new interface to learn. The only thing that changed is that the box now finds things.

That is also why the extension leaves your existing search in place. If a visitor ignores the suggestions and presses Enter, your usual search page opens, exactly as before. Your search plugin still works. Your search page still works. Any link or menu item pointing at it still works. On a site with a decade of internal links, printed leaflets and third-party references built around existing URLs, that matters more than it sounds: nothing anybody already depends on has to be unpicked before the bar can help.

Installation fits how TYPO3 teams actually work, which increasingly means Composer. Run composer require asyntai/typo3-ai-search and then vendor/bin/typo3 extension:setup, and the extension creates its single database table. Teams not in Composer mode install asyntai_search from the Extension Repository through Admin Tools, Extensions, in the ordinary way. Then open Admin Tools, Asyntai AI Search, and press Connect. There is no API key to generate, no site ID to paste and no template to edit. The module is for administrators only, and it shows the site address before you connect, so a multi-site installation connects the site you meant.

Placement is built around the fact that TYPO3 sites are built by agencies, and no two layouts are alike. If your site shows a search box, the bar finds it, hides it, and takes the same position, inheriting the layout and styling around it. That works with the search forms of indexed_search, ke_search, the Solr extension and any form somebody hand-built in Fluid five years ago. If your layout shows no search box at all, add the Asyntai AI Search bar content element to a page, or drop <div data-asyntai-search></div> into your own Fluid partial. The extension already loads the script on every page, so the container is all it needs.

Caching deserves its own sentence, because on a large TYPO3 site it is the first question an integrator asks. The bar is added to each page after TYPO3 has rendered it, outside the page cache. Your cached pages stay cached, and there is nothing to exclude, no USER_INT to introduce and no cache to clear when you change a setting. Connecting, disconnecting and editing a setting all take effect at once. The allowance check runs in the background on ordinary visitor traffic, so the extension does not need the scheduler, which is useful on the many installations where the scheduler is somebody else's responsibility.

The remaining settings are deliberately few, and each can be left empty. Leave the search box selector empty and we find the form ourselves; fill it in only if we pick the wrong one on a custom layout. Leave the placeholder empty and every visitor sees it in their own language, which matters on the multilingual sites TYPO3 is chosen for. Leave the accent colour empty to use the colour set in your Asyntai dashboard, or set a hex value to match the site. The extension is not trying to become another configuration surface to document and hand over.

Before any visitor sees it, the module has a Try your search bar button that opens your real bar, on your real content, in a new tab. Searches run there do not count against your monthly allowance. This is the honest way to judge whether it helps on your site: not on a demo, but on your own pages, with the questions your own contact centre answers every day. Type the five most common calls and look at what comes back.

The plan model suits institutions, where procurement is slow and pilots need to start before it finishes. The bar runs on every plan, including the free one, so an agency can demonstrate it on a client's staging site without a purchase order. Searches and chat replies draw on the same monthly reply allowance, and the module shows how much of the month remains. When the allowance runs out, the bar removes itself and the site's own search box comes straight back, so visitors keep being able to search, and the bar returns by itself when the allowance resets.

The search box on a big TYPO3 site is one of the least examined parts of it. It was specified in a tender, built once, and has returned something ever since. The queries it fails are invisible from the web team's side, because they surface as telephone calls in a different department's statistics. Putting a bar in that same spot that answers what people mean, rather than matching what they typed, is a small change to the page and a large change to how much of your own site your visitors can actually reach.