Table of contents
- The limits of classic navigation and the “trust paradox”
- What does the blueprint for an AI-supported website search look like?
- The strategic shift: from editor to curator
- Conclusion: Courage for new infrastructure
In many companies and blogs, it is often the top 10 to top 20 pages that attract the majority of visitors. The rest only generate a fraction of the traffic.
An analysis by Ahrefs confirms this observation. According to this, around 33% of all search traffic on the company's blog is accounted for by just five articles.
Website managers of large organizations are familiar with this phenomenon as the Pareto principle: 20% of the pages generate 80% of the traffic. But what happens to the remaining 80% – the countless subpages, PDFs and service descriptions? They form a “long tail” which, without a powerful AI search, becomes outdated over time, disappears in the information and navigation structure and ultimately becomes an invisible cost center.
An example of the Swiss Post shows the dimensions: 10,000 pages in four languages plus 5,500 images. Depending on the average text volume per page, at least 6 full-time positions are required to maintain such a volume manually. To make this mass of information usable, we need to rethink the “website” concept – away from manual maintenance and towards an intelligent, AI-supported website search.
The limits of classic navigation and the “trust paradox”
Before an AI-powered website search can be implemented, it is important to understand why the status quo is failing.
- The navigation trap is a central problem of classic CMS and website structures. While CMS usually organize content hierarchically, human questions are associative, i.e. based on links between ideas. If the answer to a customer question is spread across several pages, a classic search bar will never put them together satisfactorily – a task that only a modern AI search function can accomplish.
- The “trust paradox”: A key learning from large-scale implementations (such as our case study) is user psychology. Users often trust a pure chatbot response less than a cleanly formatted website. A static page exudes “official validity”, while a chat window is often perceived as non-committal.
The solution lies in an architecture that combines the flexibility of an LLM (Large Language Model) with the authority and UX of a classic website.
What does the blueprint for an AI-supported website search look like?
In order to realize such a solution, an architecture structured over four levels has proven itself for us:
Level 1: Semantic vectorization (from text to context)
The foundation of an AI-supported website search is the move away from keyword matching towards semantic vectorization of all content (HTML, PDFs, images). These are converted into vectors (embeddings) and stored in a vector database.
The effect: an on-site search with AI can understand the semantic proximity, i.e. the meaning. Terms such as “parcel stamp” and “letter postage” are mathematically close to each other. If a user asks for “costs for shipping”, the system finds the relevant sections, even if the word “costs” does not appear there at all. The rigid CMS becomes a fluid knowledge network. It is irrelevant where the information is located; only its context is important.
Stage 2: The modular multi-LLM architecture of the AI search function
To solve the “Trust Paradox”, we rely on a modular multi-LLM architecture instead of a simple OpenAI wrapper. This approach offers several strategic advantages:
- Flexibility and independence: Reduced dependence on a single provider. It is possible to switch between models or combine them according to requirements.
- Cost control and scalability: Costs can be saved by using local models for specific tasks and limiting API calls to specialized requirements.
- Transparency and reproducibility: Critical or sensitive processes can be carried out using transparent models, while external LLMs are used for other tasks.
- Optimization for specific use cases: The functionalities of LLMs can be improved by providing your own data and specialized prompts.
How exactly does this AI-supported website search work technically?
It is based on a multi-stage pipeline that strategically orchestrates several LLM calls:
Intent recognition and query expansion
The user input is first analyzed by an LLM to extract the intent (keyword/topic). Five semantically different search queries are then generated from the user prompt. This increases the hit rate and covers different formulations of the same question.
Multi-Source Vector Search
The generated queries search the vector database for relevant content from various sources (websites, PDFs, images). The best results are filtered and provided as context for the next stage.
Component selection through LLM
An LLM receives the filtered search results and selects the appropriate UI components from the design system to answer a question optimally. The system takes three important aspects into account when making this selection: Content complementarity, page layout and positioning, and content diversity.
Component mapping and prompt assignment
Each selected component is mapped with a specific prompt that describes the requirements of this component.
Parallel property generation
Now comes the decisive step. Each component runs through an individual LLM call. The following are transferred:
- The React component definition (available properties)
- The component-specific prompt
- The relevant content context
The LLM generates the specific properties and children for the React component. The advantages are
- Granular control over each component
- Optimized, component-specific prompts
- Better error handling and debugging
- More efficient token usage
JSON assembly and client-side rendering
The validated component properties are sent to the client as structured JSON.
Stage 3: Generative hybrid UX for intuitive AI search
The result for users is not a chat dialog, but a dynamically generated landing page. For example, if users ask for “insurance cover abroad”, the AI search generates a coherent, complete page in the corporate design on the fly that answers this exact question – including links and filter options. Users often don’t even notice that this page didn’t exist seconds ago.
Stage 4: Automated quality assurance (evals)
In the corporate context, “AI hallucinations” are unacceptable. As manual approvals are impossible for dynamic content, we recommend “unit tests” (evals) for content. These work as follows:
- A checker (often a stronger model) compares the generated answer with the “ground truth” (the vectorized original documents).
- If the response deviates in fact or violates the tonality guidelines, for example, it is blocked or corrected before it reaches the user. This guarantees brand safety without manual effort.
The strategic shift: from editor to curator
The implementation of this blueprint changes an organization in the long term:
- Single source of truth: The content team no longer maintains finished pages. They maintain tidbits of information and data. The AI takes care of the composition.
- Scalability: Whether you add 100 or 10,000 documents does not affect performance or findability. The system grows organically.
- Future-proof: Because all data is available in vectorized form, the front end works completely and independently.
Conclusion: Courage for new infrastructure
An efficient AI-supported website search has long since become an IT architecture problem – not primarily an SEO problem. But beware: while AI systems remain dependent on traditional search engines, their integration requires complex technical requirements. Those who still manage floods of information manually will quickly be left behind – but those who implement an AI search function without creating solid foundations will also fail.
Do you have your own AI project in mind or would you like to find out how a customized AI solution can help your company? Contact us now.
