RAG: build smarter website search without rebuilding
Most website searches have a simple job: match the words entered by a visitor with the words appearing on a page. That works really well when someone knows exactly what they’re looking for. But it’s less useful when they ask a detailed question, use different terminology from your website, or want information spread across several pages.
RAG offers a different approach.
Instead of returning a list of pages containing matching keywords, a RAG-powered search tool can understand the meaning behind a visitor’s question, find the most relevant information within your website and use a large language model (LLM) to produce a useful, conversational answer.
More importantly, it can be built as a standalone service.
That means the RAG/search system can be kept separate from the website. If the website is rebuilt, moved to a different CMS or replaced with another technology, you only need to change the process that takes the website’s content and puts it into the search system.
What is RAG?
RAG stands for Retrieval-Augmented Generation and combines two processes:
- Retrieval finds information relevant to a user’s question.
- Generation uses an LLM to turn that information into a clear response.
The important point is that the LLM is not being asked to retrieve an answer from its general training data alone. Before it generates a response, the system retrieves relevant information from an approved source – in this case, the website’s own content.
A typical website search request might work like this:
- A visitor asks a question in natural language.
- The question is converted into a numerical representation called an embedding.
- The system searches a vector database (which finds content based on meaning rather than exact words) for website content with a similar meaning.
- The most relevant pieces of content are added to the LLM’s prompt.
- The model produces an answer based on that supplied context.
- The website displays the answer alongside links to the original pages.
The result is a search experience that feels more like asking a knowledgeable member of the team than using a traditional search box.
Why use RAG?
Traditional website search is usually based on keywords. For example, a user searching for ‘support for an existing website’ may receive poor results if the relevant page uses phrases such as ‘ongoing maintenance’, ‘technical consultancy’ or ‘managed digital services’.
A semantic search system looks beyond exact wording. It attempts to understand that these phrases may describe related needs.
This makes RAG particularly useful for websites containing:
- Large numbers of articles, services or product pages
- Complex technical information
- Multiple sectors or audience types
- Documentation and support content
- Information spread across several pages
- Specialist terminology and acronyms
- Content created by different teams over many years
RAG can also answer more detailed questions. Rather than searching for “cloud services”, a visitor could ask:
“Can you help us migrate an existing business application to the cloud without replacing the whole system?”
The search tool can retrieve relevant sections from several pages, combine the information and provide a concise answer with links for further reading.
Our approach
At Proctors, we deliberately design our RAG search as a separate service rather than building it into the website itself and only requires an interface capable of sending a question to an API endpoint (a way for the website to communicate with the RAG service) and displaying the response.
Our suggested architecture can be separated into two main processes:
- Content ingestion – getting the information from the website and preparing it for search.
- Search and answer – retrieving a question or prompt and returning with an answer.
A recommended technology setup (or stack) for RAG site search
There are many technologies capable of supporting a RAG application. A practical stack could use PostgreSQL, pgvector, n8n and AWS Lambda, combined with either Ollama or a commercial LLM service such as OpenAI or Anthropic. Here’s what we’d recommend.
PostgreSQL and pgvector for storing website and search data
PostgreSQL provides the main data store, while the pgvector extension adds support for storing embeddings and performing vector-similarity searches.
This means the system can store the original text, page metadata and vector representations together, rather than operating a completely separate specialist database.
n8n for content ingestion
n8n can provide the workflow used to receive, process and index website content. For example, an n8n workflow couldbe triggered by:
- A CMS webhook
- A scheduled website crawl
- An API request
- A sitemap import
- A content export
- A manual publishing process
The workflow can clean the content, divide it into chunks, create embeddings and insert the resulting records into PostgreSQL.
AWS Lambda for public API endpoint
AWS Lambda can provide the endpoint used by the website’s front end. When a visitor submits a question, the Lambda function can:
- Validate and sanitise the request
- Apply rate limits or security rules
- Generate the query embedding
- Search PostgreSQLl
- Select the most relevant content
- Construct the language-model prompt
- Send the prompt to the chosen language model or LLM API
- Return the answer and source links
Because the website communicates with a standard API, the same endpoint can be used by any flavour of website, application or custom-built platform.
LLM for understanding questions and generating answers
When it comes to choosing an LLM to go for, our solution can use a model hosted by the organisation through Ollama, or a managed commercial LLM accessed through an API.
Ollama is useful when an organisation wants to run supported generative and embedding models within infrastructure it controls. It can keep more of the processing in-house, but the organisation must provide enough computing power to run the models, as well as manage model updates, scaling, monitoring and security.
Alternatively, the search service can send the retrieved context to a commercial provider such as OpenAI, whose models power ChatGPT, Anthropic’s Claude, Google’s Gemini or another suitable LLM service. Managed services can reduce infrastructure work and provide access to high-performing models, but they introduce usage charges, provider-specific limits, data-processing terms and dependency on an external service.
Key benefits of a RAG search solution
- It is independent of the website platform.
- It supports natural-language questions.
- It is grounded in approved content (only the retrieved website data is referenced).
- It supports different levels of control over data and models (an LLM can be chosen to fit your needs).
- It can grow beyond website search (separate interfaces for more specialised searching of product documentation, case studies etc. can be added).
Limitations and risks of a RAG search solution
- Answers are only as good as the indexed content.
- Chunking affects retrieval quality.
- Content must stay synchronised.
- LLMs can still make mistakes.
- Security considerations (ensuring private data is not included in results).
Reusable search for changing websites
Websites change: they can be redesigned, migrated, replatformed and integrated with new systems. Search functionality that is built too deeply into one platform often needs replacing at the same time.
A standalone RAG architecture avoids much of that dependency.
When the website platform changes, the core service remains in place. Only the route used to bring content into the vector database needs to be adapted.
That turns RAG-powered search from a feature of one website into a reusable digital capability – one that can support future websites, applications and knowledge services without starting again from scratch.
Why should you consider using RAG site search?
Utilising RAG for site search allows visitors to ask complete questions and receive relevant, conversational answers grounded in your approved content. This can reduce friction, improve content discovery and help prospective customers understand your complex services more quickly.
Built as a standalone service, the same search capability can continue working as your website changes and can later be extended to support documentation, product information, customer service or internal knowledge.
Want to explore RAG search for your business?
Proctors are seasoned experts at turning the content you already have into a smarter, more useful search experience for your customers. To find out how we can help, get in touch at marketing@proctorsgroup.com
.webp)
