Case Study: n8n RAG AI Assistant for Websites

How We Made Years of Website Content Instantly Accessible Through an AI Assistant

Step 7 Consulting’s website is more than a marketing site — it’s a deep knowledge base. Years of case studies, service descriptions, process documentation, and capability content are published across dozens of pages. The challenge was making that knowledge instantly accessible to visitors without requiring them to navigate, search, or read through multiple pages to find what they need.

RAG is the technology framework organizations use to make large knowledge bases conversational. Companies deploy it against internal wikis, documentation, support libraries, and product catalogs. We applied the same approach to our own website — building an AI-powered assistant that can answer any question about our services, capabilities, and work, grounded exclusively in our published content.

This case study documents how we built the Step 7 AI Assistant using n8n, OpenAI, Supabase, Firecrawl, and WordPress — and the architectural decisions that make it applicable to virtually any organization looking to incorporate an AI assistant.

The Problem We Solved

We needed a website assistant that could do more than answer FAQs from a static script. Specifically, it needed to:

• Answer questions accurately using only our published content — no hallucination, no outside knowledge
• Handle natural language queries conceptually (“how do you help with workflow automation?”) AND exact keyword queries (“do you work with Salesforce?”)
• Remember context across a conversation so follow-up questions work naturally
• Stay current automatically — any page update on our website should reflect in the assistant without manual intervention
• Enforce strict confidentiality rules around client names, pricing, and staff

No off-the-shelf AI assistant product could meet all of these requirements — so we built it from scratch.

How We Built It

We designed a three-workflow architecture with a RAG-based data ingestion and retrieval framework on a stack including n8n, OpenAI, Supabase, Firecrawl and WordPress.

Workflow 1 — Webhook

Real-Time Change Detection – Whenever a page is added, updated, removed from our website a webhook fires and delivers a message to n8n.

• • A WordPress webhook fires and sends a payload for every page added, updated, deleted event
  • The webhook payload is authenticated, validated, and formatted for the queue
  • The payload is written to an n8n Data Table queue — new / updated pages queue for ingestion, deleted pages queue for removal.

Workflow 2 — RAG Ingestion

Automated Content Pipeline – A scheduled workflow processes the queue to ingest new / updated pages and remove deleted pages:

• • Get Queue — get all pages in the queue and loop through each one
  • Delete Existing Chunks / Vectors — delete all current Supabase chunks / vectors from the database
  • Scrape Page — scrape the live page from the website with Firecrawl and returns clean markdown
  • Prepare Chunks / Vectors — strip page noise (css, js, …) and prepare the content for chunking / embedding vectors
  • OpenAI Embeddings — generates vector embeddings per chunk
  • Supabase Vector Store — inserts chunks with embeddings and metadata tags (URL, post ID, tags)
  • Delete row from Queue — remove the processed record from the queue and repeat for next queue record

Workflow 3 — RAG Retrieval

Three-Signal Hybrid Search – When a visitor opens the AI Assistant and starts a chat their questions are sent as a message which starts the search:

• • Conversation history is pulled from Postgres for session memory
  • A Supabase Edge Function generates a query embedding via OpenAI and executes a custom hybrid search PostgreSQL function
  • The SQL function scores results across three independent signals using Reciprocal Rank Fusion (RRF):
    • Full-text search (FTS) — keyword matching via tsvector
    • Semantic search (Vector) — conceptual similarity via pgvector
    • Tag match — exact match against keyword tags with a weighted boost, guaranteeing exact matches always surface
  • A Code node consolidates retrieved chunks into a context block and builds the OpenAI message array with system prompt, history, and user input
  • OpenAI generates a response grounded strictly in retrieved context and presents it in the chat window
  • The response and updated history are saved back to Postgres to maintain conversation history

What Makes This Architecture Different

Most RAG implementations use two signals — vector search plus maybe FTS. The third signal, tag-based exact match, is what separates our AI assistant system.

When a prospect types “do you work with HubSpot?” or “have you built anything with n8n?”, vector search often fails — the query is too short and too specific for semantic similarity to work reliably. FTS helps but struggles with product names, acronyms, and tool names that don’t stem well. The tag match signal solves this definitively: keyword tags defined per page act as guaranteed retrieval triggers, regardless of how the query is phrased.  This approach would be especially critical in businesses where part numbers are used extensively in search.

Results

• Accurate, grounded responses using only Step 7 website content
• Exact keyword retrieval for tool names, service categories, and proper nouns
• Automatic content freshness — page updates trigger re-ingestion, no manual work required
• Session memory — follow-up questions work naturally across a conversation
• Full auditability via n8n execution history

If your organization has a content-rich website, internal documentation, a product catalog, or a support library, you already have the raw material for an AI-powered assistant. We can design and build a RAG system that makes that knowledge instantly accessible — without hallucination, without manual updates, and without replacing your existing content infrastructure.

→ Schedule a Consultation to talk through your use case.