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.
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.
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.
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 could be 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.
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.
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).
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).
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.
Have you experimented with RAG for website search? What was your experience?