AI search for Moodle that answers what your students mean
A Moodle site holds years of course material, and students rarely know what any of it is called. They know their question. Moodle's global search matches the words they type against an index of the words in your content, so a student who asks "where do I go when the fire alarm goes off" gets nothing. Asyntai's AI Search Bar reads the meaning and finds your Assembly points page, even though the title says nothing about fire alarms. One plugin, no code, and it reads only the courses you tick.
See the AI search your Moodle content
Enter your Moodle site URL and watch the bar find real answers in your own course material
Students ask in their own words, and the bar finds the right page
Moodle's global search builds a word index from your course content and returns the items that contain the words a student typed. It works when the student already knows your vocabulary. It fails for everybody else, and in a learning site almost nobody has your vocabulary yet, because learning it is why they are there. Students ask about a situation, not a topic. They ask "I missed the deadline because I was ill", not "extenuating circumstances". They ask "where do I go when the fire alarm goes off", not "evacuation assembly points". Global search finds no overlap and returns an empty page, so the student assumes the answer is not on the site and emails a tutor instead. The Asyntai AI Search Bar reads the whole question, works out what the student is trying to do, and returns the course pages that answer it.
- Meaning, not matchingA student types "I missed the deadline because I was ill" and the bar returns your extensions policy, even though the page is called "Mitigating circumstances". The words do not overlap. The meaning does. That gap is the reason most searches on a learning site come back empty, and closing it is what the bar is for.
- Every book chapter is its own resultA Moodle book can run to forty chapters, and a student who lands on the front page still has to hunt. Each chapter is read as its own searchable item, so a question about week nine lands on the week nine chapter. The same is true of pages, labels and activity descriptions.
- Results while the student typesResults appear under the bar as the question is typed, as a short ranked list with a title and a line of context. Arrow keys move through the list and Enter opens the highlighted result. Nothing loads a separate results page, and nothing sends the student away from the activity they were in.
You tick the courses, and student data is never read
Nothing is read until you tick a course. That is the whole model, and it is deliberate. In the plugin screen you switch course reading on, tick the courses the bar may read, and press Save. Untick a course at any time and it stops being read. Switch reading off entirely and the read key is deleted and the content is removed from Asyntai. What we read is the material you wrote: course names and descriptions, pages, book chapters, labels, activity descriptions and the names of attached files. What we never read is anything belonging to a student. Grades, submissions, forum posts, quiz answers and personal details all stay inside Moodle.
- A read key that can reach one functionSaving switches on Moodle web services and the REST protocol and creates one token. That token belongs to a service holding a single read-only function, so it cannot reach anything else in Moodle. You can see it under Site administration, Server, Web services, Manage tokens. Disconnecting the plugin deletes it.
- Three places the bar can goBy default the bar sits in the top navigation bar on every page, next to the user menu, which works with Boost, Classic and the themes built on them. Or it takes the place of the search box your theme already shows. Or you give a CSS selector, for example
#page-header .header-actions, and the bar renders inside every element that matches. - Signed in by default, visitors by choiceOnly signed-in users see the bar, because it searches the course material you ticked. If your front page and public courses should be searchable too, tick "Show the bar to visitors who are not signed in". The decision stays yours, and it is one checkbox either way.
Add AI search to your Moodle site without touching code
There is no API key to create and nothing to paste. Upload the plugin, press one button to connect your account, and tick the courses the bar may read. We read them and tell you on the plugin screen when the bar is live.
- In Site administration, open Plugins, then Install plugins, and upload the plugin ZIP file. Moodle asks you to confirm the upgrade.
- Open Site administration, then Plugins, then Local plugins, then Asyntai AI Search.
- Press Connect Asyntai. A window opens where you sign in or create a free account.
- Under Course content, tick Let Asyntai read the ticked courses, tick the courses, and press Save course content.
# Site administration > Plugins > Install plugins
Plugin local_asyntaisearch
Moodle 4.2 to 5.1
PHP 8.1 or later
# No API key, no code, no theme edits.
See the bar answer a student
This is the AI Search Bar itself. Students type a question, and the bar finds the page.
Not one of these titles contains the words the student typed. That is the difference between matching words and reading meaning.
AI search for Moodle — FAQs
Common questions from Moodle administrators, learning technologists and teaching staff looking at AI-powered course search.
How is this different from Moodle's global search?
Global search builds a word index from your course content and returns the items containing the words a student typed. It works when the student already knows your vocabulary. The Asyntai AI Search Bar works on meaning instead. It reads the whole question, works out what the student is trying to do, and returns the pages that answer it, even when the student's words and your words do not overlap. A student asking "where do I go when the fire alarm goes off" finds your Assembly points page. Global search finds nothing for that query, because none of those words is in it.
Does it read student data?
No. We read the material you wrote: course names and descriptions, pages, book chapters, labels, activity descriptions and the names of attached files. Grades, submissions, forum posts, quiz answers and personal details all stay inside Moodle and are never read. The read key the plugin creates belongs to a web service holding a single read-only function, so there is nothing else in Moodle it could reach even if something went wrong.
Which courses does it read?
Only the ones you tick. Nothing is read until you switch course reading on, tick the courses and press Save. Untick a course at any time and it stops being read. Switch reading off entirely and the read key is deleted and the content is removed from Asyntai. This is the opposite of the usual default: a plugin that reads everything until you stop it. Here it reads nothing until you say which.
Which Moodle versions does it support?
Moodle 4.2 or later, up to 5.1, on PHP 8.1 or later. Your server also needs to be able to make outgoing HTTPS requests to asyntai.com, because the plugin talks to us directly. Most hosts allow this, and the plugin screen says plainly if yours does not.
Will it work with my theme?
Yes, and there are three ways to place it. The default puts the bar in the top navigation bar on every page, next to the user menu, which works with Boost, Classic and the themes built on them. That is nearly every Moodle theme. The second takes the place of a search box your theme already shows, whether that is global search in the navigation bar or the course search box. The third takes a CSS selector, for example #page-header .header-actions, and renders the bar inside every element that matches. That covers a heavily customised theme with no usual navigation bar.
Who can see the bar?
By default only signed-in users, because the bar searches the course material you ticked. If your front page and public courses should be searchable by anybody, tick "Show the bar to visitors who are not signed in". The bar still only ever returns content from the courses you ticked, so making it public does not make anything else public.
Does Moodle's own search stop working?
No, and you should keep it. If a student presses Enter without picking one of the results, your usual Moodle search page opens exactly as before. Global search, the search block and any link you have to a search page all keep working. Students who know how your search works keep that route. Students who describe what they want in a sentence get an answer instead of an empty page.
What plan do I need?
A site connected through this plugin runs the bar on any plan, including the free one. Your monthly reply allowance applies, and searches and chat replies share it. The plugin screen shows how much of the month is left. When the allowance runs out the bar removes itself until the month resets, and the plugin checks every ten minutes in the background so it comes back by itself. There is nothing to update or reinstall.
Can I try it before my students do?
Yes. The plugin screen has a Try your search bar button. It opens your real search bar, on your real course content, in a new tab. Searches you run there do not count against your monthly allowance, so you can check the results on your own material before you show it to a single student.
Why students stop searching your Moodle site, and what an AI search bar changes
A Moodle site that has run for a few years is an archive. Course pages, books, labels, activity descriptions, handbooks, policies, induction material, past assessment briefs, all written by different people at different times, organised into a structure that made sense to whoever built each course. The answer a student needs is nearly always in there. The problem is that finding it requires knowing what it was called, and a student is by definition someone who has not learned your vocabulary yet.
Moodle's global search is a competent word index. It crawls your content through search areas, supports filtering by course and by time, and returns results quickly. Every one of those strengths rests on one assumption: that the student will type words that appear in your material. In a learning site that assumption fails harder than anywhere else. A student does not know that the extensions policy is filed as "mitigating circumstances". They type "I missed the deadline because I was ill". They do not know the evacuation page is called "Assembly points". They type "where do I go when the fire alarm goes off". Global search does what it was built to do, finds no word overlap, and returns nothing.
An empty result page is not a neutral outcome in a learning site. It teaches the student that the information is not there, which is almost always false. They do not try a second phrasing. They email a tutor, or they post in a forum, or they ask a friend who is also guessing. Every one of those routes costs staff time that the search was supposed to save, and the worst of them, asking a friend, quietly spreads a wrong answer through a cohort.
The Asyntai AI Search Bar replaces the matching step with an understanding step. When a student types a question, the bar does not look for those words in your course content. It works out what the question means, then finds the pages that answer it. "I missed the deadline because I was ill" and "Mitigating circumstances" share no words at all, and the bar connects them, because it is reasoning about the subject rather than comparing strings. That single change turns a large class of failed searches into answers, and it does it without anybody rewriting a single page title.
The behaviour students see is deliberately ordinary. They type into a search box in the navigation bar, where Moodle has always had one. Results appear underneath as they type, each with a title and a line of context, and each one a real link to a real page in a course they are enrolled on. Arrow keys move through the list and Enter opens the highlighted result. There is no chat window to open and no new interface to learn. The only thing that changed is that the box now finds things.
Books deserve their own mention, because they are where Moodle search disappoints most. A course book can run to forty chapters of genuinely useful material, and a search that returns the book's front page has answered nothing: the student still has to hunt. The plugin reads each chapter as its own searchable item, so a question about the week nine reading lands on the week nine chapter. The same treatment applies to pages, labels and activity descriptions, which are the places course teams actually write their instructions.
What the plugin reads is the part most administrators want settled before anything else, so it is settled by design rather than by policy. Nothing is read until you tick a course. You switch course reading on, tick the courses the bar may read, and press Save. Untick a course and it stops being read. Switch reading off and the read key is deleted and the content is removed from Asyntai. There is no default that quietly includes everything, because in an institution that default is the one nobody notices until it matters.
Student data is never read at all. The material we read is the material your staff wrote: course names and descriptions, pages, book chapters, labels, activity descriptions and the names of attached files. Grades, submissions, forum posts, quiz answers and personal details stay inside Moodle. This is enforced by the shape of the connection, not by a promise. Saving creates one token belonging to a web service that holds a single read-only function, so there is nothing else in Moodle that the token can reach. You can see it under Site administration, Server, Web services, Manage tokens, and disconnecting the plugin deletes it.
Installation is the ordinary Moodle route. Upload the plugin ZIP under Site administration, Plugins, Install plugins, and confirm the upgrade. Open the plugin under Local plugins, press Connect Asyntai, and sign in or create a free account in the window that opens. Then tick your courses. There is no API key to generate, no site ID to copy into a settings field and no theme file to edit. Moodle 4.2 to 5.1 on PHP 8.1 or later are supported, and the server needs to be able to make outgoing HTTPS requests, which most hosts allow.
Placement is built around the fact that Moodle themes vary more than they look. The default puts the bar in the top navigation bar next to the user menu, which covers Boost, Classic and the many themes built on them. If your theme shows its own search box, the bar can take that box's place instead, inheriting the surrounding layout. If your theme is heavily customised and has neither, a CSS selector renders the bar inside whichever element you name. Three options sounds like a lot until you have supported a university theme that was forked in 2019.
Visibility follows the content. Only signed-in users see the bar by default, because it searches the courses you ticked, and that is the right default for a site whose material is for enrolled students. Institutions with public front pages and open courses can tick one box to show the bar to visitors too. The bar still only ever returns content from the ticked courses, so opening it to visitors does not open anything else.
Before any student sees it, the plugin screen has a Try your search bar button that opens your real bar, on your real course content, in a new tab. Searches run there do not count against your monthly allowance. This is the honest way to judge whether the bar helps at your institution: not on a demo course, but on your own material, with the questions your own support inbox receives every September. Type the three questions your student services team answers most often and look at what comes back.
The plan model suits education, where budget conversations are slow and pilots need to start before them. The bar runs on every plan, including the free one, so a department can try it on a handful of courses without a purchase order. Searches and chat replies draw on the same monthly reply allowance, and the plugin screen shows how much of the month remains. When the allowance runs out the bar removes itself until the month resets, and the plugin checks every ten minutes in the background, so it returns by itself with nothing to reinstall.
The search box on a Moodle site is one of the least examined parts of it. It was there when the site was installed, it has always returned something, and nobody checks what. The searches it fails are invisible, because a student who finds nothing does not file a ticket saying so: they email a tutor, and that email looks like a tutoring question rather than a search failure. Putting a bar in the same place that answers what students mean, rather than matching what they typed, is a small change to the page and a large change to how much of your own material your students can actually reach.