Adding an AI chatbot to a Drupal site is not the same as embedding a widget. A widget sits on top of your site and knows nothing about it. A chatbot that is worth having reads your content through Drupal itself, which is the difference between something that answers questions and something that guesses.
Why Drupal makes this easier than most CMSs
Drupal already holds structured information that a chatbot needs and would otherwise have to invent. Content types tell you what kind of thing each page is. Taxonomy tells you how your organisation groups knowledge. Revision timestamps tell you what is current. The node access system tells you exactly who may read what. On a site built from scraped HTML, none of this exists.
This is also why crawling your own site is the wrong approach even when it is technically possible. A crawler sees rendered pages and throws away everything Drupal knew about them.
How content gets indexed
The chatbot reads content through Drupal's entity API, either through a custom module or through JSON:API. You choose which content types belong in the knowledge base, which fields carry the actual answer, and which sections stay out.
Each article is then split into chunks. This is where quality is won or lost. Splitting blindly every thousand characters cuts sentences in half and separates a rule from its exception. Splitting on your heading structure keeps each chunk self contained, and carrying the article title and taxonomy terms into every chunk means a passage still makes sense when it is retrieved on its own.
Every chunk is stored with metadata: node ID, URL, title, language, last revision date, and the access information attached to it. That metadata is what makes source links, freshness ranking, and permission filtering possible later.
How permissions are applied
When a logged in user asks a question, the module reads their roles and access grants from the current session, builds a filter, and applies that filter to the vector search. Only passages that survive the filter are given to the language model.
The order is the whole point. The model never receives content the user could not open in a browser, so it cannot reveal it even if someone asks cleverly. Any design where the model is told which content to ignore is a design that leaks eventually.
Staying in sync
Content changes constantly, and an index that drifts out of date becomes actively harmful. Drupal makes this easy: entity hooks fire when a node is saved, unpublished, or deleted, so the index can be updated in the same moment rather than on a nightly crawl.
The detail that catches people out is deletion. If you index an updated article without first removing the old chunks, both versions stay in the index and the chatbot will happily quote the outdated one. Removing before inserting is not optional.
Multilingual sites
Many Belgian and European Drupal sites publish in two or three languages, and translation coverage is rarely complete. A multilingual embedding model can retrieve a French article in response to a Dutch question, which is genuinely useful when the Dutch translation was never made. The answer should be written in the language of the question, with the source shown in its original language so nobody is misled about what they are citing.
What actually decides whether it works
In our experience the technical setup is rarely the problem. Three things about your site matter more:
- Content hygiene. Superseded articles that were never unpublished are the main cause of wrong answers. Archive them before you index.
- Content depth. A few hundred short pages will not produce better answers than good navigation would. This starts paying off in the thousands.
- How you handle the gaps. The chatbot must say when your content does not cover something. A system that always produces an answer is a system that sometimes invents one.
For the deeper security question of gated content specifically, see AI chatbots for content behind a login.