{"id":1954,"date":"2026-02-11T10:28:13","date_gmt":"2026-02-11T10:28:13","guid":{"rendered":"https:\/\/paoloronco.it\/?p=1954"},"modified":"2026-02-11T10:28:14","modified_gmt":"2026-02-11T10:28:14","slug":"wordpress-ai-chatbot-trasformare-contenuti-in-un-sistema-interrogabile-n8n-qdrant-mongodb-vector-store","status":"publish","type":"post","link":"https:\/\/paoloronco.it\/en\/wordpress-ai-chatbot-trasformare-contenuti-in-un-sistema-interrogabile-n8n-qdrant-mongodb-vector-store\/","title":{"rendered":"WordPress AI Chatbot: Transforming Content into a Queryable System | n8n, Qdrant, MongoDB Vector Store"},"content":{"rendered":"

The WordPress AI Chatbot<\/strong> that I built was born from a very concrete question:
Can I turn a site into something that can be queried?<\/em><\/p>\n\n\n\n

\n

Don't look. To question<\/strong>.
The difference is subtle but fundamental.<\/em><\/p>\n<\/blockquote>\n\n\n\n

When someone lands on a technical website and wants to understand what you've done, they have to piece together the story by reading articles, connecting skills, and drawing on experience. It's a manual process. The chatbot takes action exactly here: it makes it possible to ask direct questions about what's been published and get answers based solely on that content.<\/p>\n\n\n\n

It's not a generic helper. It's a semantic layer on top of WordPress.<\/p>\n\n\n\n

\n\n\n\n

Indexing; data preparation<\/h2>\n\n\n\n

The Posts; Inexing and preparation on Qdrant<\/h3>\n\n\n\n

Operation is divided into two completely separate moments: data preparation and querying.<\/p>\n\n\n\n

There preparation phase<\/span> It happens through a dedicated workflow on n8n. This workflow doesn't manage users. It doesn't answer to anyone. It only takes care of building the site's semantic index.<\/p>\n\n\n\n

When run, it queries WordPress via REST API<\/span>, recover the published posts<\/span>, extracts the title, content, and excerpts, strips out the HTML markup, and creates a clean version of the text. This text isn't saved as is; it's broken into smaller chunks to allow for more precise searching.<\/p>\n\n\n\n

Each block is transformed into a embedding <\/span>through OpenAI<\/span>. The result is a numeric vector representing the meaning of the text. Those vectors are then saved in a optimized database <\/span>For semantic search<\/span>.<\/p>\n\n\n\n

Two possibilities come into play here. For lean and direct configurations<\/span> can be used Qdrant<\/span>. For more structured configurations, especially when you want to manage multiple separate data sets, it is used MongoDB Atlas <\/span>with Vector Search<\/span>.<\/p>\n\n\n\n

But the really interesting part isn't the post indexing. It's the fact that the system isn't limited to posts.<\/p>\n\n\n\n

Skills and Profile: Structured Indexing on MongoDB Atlas<\/h3>\n\n\n\n

Skills and profile sections aren't classic WordPress content. They're not articles. They're not narrative pages. They're structured data.<\/p>\n\n\n\n

To make them interrogable, I have foreseen a different process.<\/p>\n\n\n\n

The skills <\/span>they come organized <\/span>in file JSON <\/span>And CSV <\/span>structured by domain, category, level and description. These files are imported <\/span>in MongoDB <\/span>in dedicated collections. At that point one comes into play Node.js script<\/span> included in the project.<\/p>\n\n\n\n

The script <\/span>reads each document, builds a unified textual representation (skill, domain, description, level), calls the embeddings API <\/span>Of OpenAI<\/span>, generates <\/span>The vector <\/span>And update <\/span>the document with the field embedding<\/span>. Subsequently a index <\/span>of type vector search <\/span>on that collection.<\/p>\n\n\n\n

The result is that the skills <\/span>they are not simply listed on a page. They are semantically queriable<\/span>.<\/p>\n\n\n\n

If someone asks, "Do you have experience in cloud security?", the system doesn't look for the exact word. It compares the meaning of the question with the meaning of the vectorized documents.<\/p>\n\n\n\n

The same mechanism applies to the profile, organized into separate sections and indexed in the same way.<\/p>\n\n\n\n

This way, the chatbot works on three distinct domains: posts, skills, and profile. It doesn't mix them together. It treats them as separate sets of information.<\/p>\n\n\n\n

\n\n\n\n

The Chatbot: What Happens When a Question Comes in<\/h2>\n\n\n\n

The second workflow on n8n is the one that handles requests in real time.<\/p>\n\n\n\n

The request arrives via a webhook, protected by header authentication. Before even querying the database, the system must understand the type of request.<\/p>\n\n\n\n

This is where an LLM-based intent router comes in. It doesn't generate responses. It classifies. It decides whether the question is about:<\/p>\n\n\n\n