// stack · schnittstelle
Meilisearch ist eine quelloffene Suchmaschine — ein eigener Suchserver, den du selbst hosten kannst; als Cloud-Dienst gibt es sie ebenfalls. Für siteway ist das der Weg, wenn eine Suche Filter, Facetten und Tippfehler-Toleranz können muss und trotzdem in der eigenen Infrastruktur bleiben soll. Diese Seite beschreibt, wie wir Meilisearch anbinden — und was der eigene Betrieb dafür verlangt.
// definition
quelloffen · eigener suchserver
Meilisearch ist eine quelloffene Suchmaschine. Sie läuft als eigenständiger Dienst — auf einem Server, den du bestimmst. Der Quelltext liegt öffentlich einsehbar vor, der Kern steht unter der MIT-Lizenz, und wer den Betrieb nicht selbst übernehmen will, kann stattdessen den Cloud-Dienst des Herstellers nutzen. Beides ist derselbe Baukasten, nur mit anderer Adresse.
Technisch ist das Bild schnell erzählt: Inhalte werden als Dokumente in einen Index geschrieben, ein Dokument ist ein Objekt aus benannten Feldern, und die Suchanfrage geht an genau den Server, auf dem dieser Index liegt. Was der Index kann, hängt an seinen Einstellungen: Welche Felder durchsucht werden, welche sich filtern lassen, wonach sortiert wird und in welcher Reihenfolge Treffer erscheinen.
Der entscheidende Satz steht aber woanders: Steht der Suchserver in deiner Infrastruktur, bleiben Inhalte und Suchanfragen dort. Keine Anfrage nach draußen, kein Index bei einem Dritten. Das ist kein Nebeneffekt, sondern der Grund, aus dem wir Meilisearch überhaupt in den Werkzeugkasten gelegt haben. Wie wir Suche insgesamt angehen, steht im Hub Suche.
// praxis
indexieren serverseitig · suchen im frontend
Der erste Schritt ist eine Frage, keine Zeile Code: Was ist ein Treffer? Eine Seite, ein Produkt, ein Datenblatt, ein Kapitel? Daraus folgt der Zuschnitt eines Dokuments — und damit alles Weitere. Wir schneiden so, dass ein Treffer eine Antwort ist und nicht der Beginn einer zweiten Suche.
Danach steht das Mapping: Welches Feld aus dem CMS wird welches Attribut im Dokument, was ist durchsuchbar, was filterbar, was sortierbar, was nur Anzeige. Diese Liste ist bei Meilisearch mehr als Dokumentation — Filter und Sortierung funktionieren erst, wenn die zugehörigen Attribute in den Einstellungen des Index stehen. Und hier fällt die zweite Entscheidung: was den Index gar nicht erst erreicht. Interne Notizen, Entwürfe, geschützte Bereiche. In den Index geht, was für die Suche gebraucht wird.
Indexiert wird serverseitig, in zwei Stufen. Zur Einrichtung läuft eine Voll-Indexierung über den gesamten Bestand, gebündelt statt Dokument für Dokument — Meilisearch nimmt Dokumente ohnehin als Liste entgegen und arbeitet Aufgaben in einer Warteschlange ab. Danach laufen nur noch Änderungen: angelegt, geändert, gelöscht. Weil die Verarbeitung asynchron ist, prüfen wir den Status der Aufgabe, statt anzunehmen, ein Dokument sei in derselben Millisekunde suchbar. Für eine Redaktion ist das unkritisch, für einen automatisierten Test nicht.
Der Rückweg ist der Praxisstolperstein. Ein Inhalt, der im CMS gelöscht oder auf Entwurf zurückgesetzt wird, verschwindet nicht von allein aus dem Index — er muss aktiv entfernt werden. Sonst zeigt die Suche eine Überschrift, die noch niemand sehen sollte, oder verlinkt eine Seite, die es nicht mehr gibt. Wir behandeln „löschen“ und „depublizieren“ deshalb als eigene Ereignisse mit eigenem Code. Dasselbe gilt für alles, was hinter einem Login liegt: Entweder es wird gar nicht indexiert, oder es landet in einem getrennten Index mit eigenem Zugriffsweg.
Gesucht wird im Frontend — mit einem Schlüssel, der nur lesen darf, und einer Oberfläche, die wir selbst bauen: Eingabefeld, Treffer während des Tippens, Filter daneben, ein Zustand für null Treffer. Und wie bei jeder Anbindung planen wir den Fehlerfall mit: Antwortet der Suchserver nicht, bleibt die Seite bedienbar. Die buchbare Leistung dahinter ist die Komponente Suche, die Anbindung selbst gehört zur Schnittstellenentwicklung.
// technik · 6 details
belegt aus der doku
Was hier steht, stammt aus der öffentlichen Dokumentation von Meilisearch — Begriffe, Voreinstellungen und Reihenfolgen im Original. Preise, Versionsnummern und harte Grenzwerte lassen wir bewusst weg: Sie ändern sich, und was für dein Projekt gilt, steht in deiner Konfiguration und nicht auf einer Agenturseite.
// d-01datenmodell
Ein Index ist der Behälter, ein Dokument ein Objekt aus benannten Feldern darin. Zwischen zwei Indizes wird nichts geteilt, auch bei gleichem Inhalt nicht. Jedes Dokument braucht ein Primärfeld mit eindeutigem Schlüssel; fehlt es oder passt es nicht zum Index, übernimmt Meilisearch keine Dokumente.
zweck: struktur der daten
// d-02relevanz
Ab Werk sind alle Felder durchsuchbar und werden alle ausgegeben. Das ist ein guter Start und selten das Ziel: Über die durchsuchbaren Attribute legst du fest, worin gesucht wird und in welcher Rangfolge — ein Titel wiegt anders als ein Fließtext. Über die angezeigten Attribute steuerst du, was zurückkommt.
zweck: worin gesucht wird
// d-03filter
Der häufigste Stolperstein: Gefiltert werden kann nur, was vorher als filterbares Attribut eingetragen wurde — die Liste ist im Auslieferungszustand leer. Die Dokumentation nennt den Schritt verpflichtend und nicht zur Suchzeit nachholbar, weil eine Änderung neu indexiert. Für Sortierung gilt dasselbe über die sortierbaren Attribute.
zweck: eingrenzen
// d-04reihenfolge
Die Regeln greifen nacheinander: Die erste sortiert in Gruppen, jede weitere entscheidet nur noch innerhalb einer Gruppe. Standard sind getroffene Suchwörter, Tippfehler, Wortnähe, Rangfolge der Attribute, Sortierung zur Suchzeit, Position im Text und Genauigkeit. Darunter hängen eigene Regeln nach einem Feld deiner Daten.
zweck: was oben steht
// d-05toleranz
Tippfehler-Toleranz ist eingeschaltet, ohne dass jemand etwas tun muss — abschaltbar bleibt sie trotzdem. Erlaubt sind höchstens zwei Tippfehler je Wort, abhängig von der Wortlänge; kurze Wörter werden streng behandelt, ein Fehler im ersten Buchstaben zählt doppelt. Synonyme setzen Begriffe gleich, in eine oder beide Richtungen.
zweck: trotzdem finden
// d-06schlüssel
Der Master-Schlüssel schützt die gesamte Instanz, ist im Produktivbetrieb vorgeschrieben und bleibt auf dem Server. Aus ihm leiten sich API-Schlüssel mit begrenzten Rechten ab — einer für administrative Aufgaben, einer nur zum Suchen. Die Dokumentation sagt klar: Administrative Schlüssel gehören nicht in ein öffentliches Frontend.
zweck: trennung der rechte
Selbstbestimmung hat einen Preis, und der ist Betrieb. Ein eigener Suchserver ist ein zusätzlicher Dienst neben der Website: Er braucht Arbeitsspeicher und Plattenplatz für den Index, eine Absicherung nach außen — der Suchserver gehört nicht ungeschützt ins offene Netz —, regelmäßige Aktualisierungen und eine Sicherung, die jemand einmal zurückgespielt hat. Das ist keine Warnung, sondern eine Position im Angebot.
Für die Sicherung unterscheidet Meilisearch zwei Wege, und die Unterscheidung ist nützlich: Snapshots sind eine exakte Kopie der Datenbank, schnell wiederhergestellt, aber an dieselbe Programmversion gebunden. Dumps sind ein portables Abbild, das beim Import neu indexiert wird — langsamer, dafür der dokumentierte Weg beim Wechsel auf eine neue Version. Wer beides kennt, plant eine Aktualisierung als Vorgang und nicht als Überraschung.
Beim Datenschutz ist die Rechnung dafür angenehm kurz: Inhalte und Suchanfragen bleiben in der eigenen Infrastruktur, es geht keine Anfrage an einen Dritten, und für die Suche braucht es keine Auftragsverarbeitung. Wer stattdessen den Cloud-Dienst nutzt, klärt dieselben Fragen wie bei jedem gehosteten Dienst. Wie wir das einordnen, steht im Stack unter Sicherheit & Datenschutz; wo der Dienst läuft und wer ihn betreut, gehört zu Deployment & Betrieb. Eine Rechtsberatung ist das ausdrücklich nicht.
// integration
drei systeme · ein muster
Der Weg ist in jedem System derselbe, weil er sich aus der Aufgabe ergibt und nicht aus dem CMS. Die eine Hälfte ist die Indexierung — und die läuft serverseitig: Der Inhalt wird dort gelesen, wo er redaktionell gepflegt wird, in Dokumente übersetzt und an den Suchserver geschickt. Zur Einrichtung einmal komplett, danach nur noch das, was sich ändert. Dafür braucht es zwei Auslöser: ein Ereignis beim Speichern, damit eine Änderung sofort ankommt, und einen geplanten Lauf als Grundsicherung, falls ein Ereignis einmal ausfällt. Und es braucht die Gegenrichtung — gelöschte und depublizierte Inhalte müssen aktiv aus dem Index entfernt werden, sonst bleiben Treffer stehen, deren Seite es nicht mehr gibt.
Die andere Hälfte ist die Suche im Frontend. Sie fragt den Suchserver direkt aus dem Browser — und zwar über einen Schlüssel mit reiner Leseberechtigung, der nur suchen darf. Das ist die Stelle, an der Anbindungen scheitern, deshalb steht sie hier so deutlich: Der Master-Schlüssel gehört nie ins Frontend — und ein administrativer Schlüssel ebenso wenig. Sie liegen ausschließlich auf dem Server, in der Umgebungskonfiguration, und tauchen weder im Quelltext einer Seite noch in einem JavaScript-Bundle auf. Wo der Suchserver selbst läuft — auf derselben Maschine wie die Website, in einem eigenen Container oder beim Cloud-Dienst des Herstellers —, ist keine Frage des CMS, sondern eine Betriebsentscheidung; sie gehört zu Deployment & Betrieb und wird vorher getroffen, nicht nachträglich. Was das CMS darunter unterscheidet, ist nur, wo Ereignis, geplanter Lauf und Schlüssel jeweils hingehören.
// cms-01typo3
Wir bauen die Anbindung als eigene Extension. Die Voll-Indexierung läuft als Scheduler-Task über die Seiten und Datensätze, die im Mapping stehen; dazu kommt ein Hook, der beim Speichern genau diesen einen Datensatz nachzieht — und beim Löschen oder Verstecken wieder aus dem Index nimmt. Die Schlüssel liegen in der Extension-Konfiguration; der administrative Schlüssel bleibt dort und wird nie ins Template gereicht. Sucheingabefeld, Filter und Trefferliste rendern wir in Fluid, damit die Suche im Design der Website steht. Mehrsprachigkeit bildet sich über einen eigenen Index je Sprache ab.
// cms-02wordpress
Die Anbindung entsteht als eigenes Plugin und nicht als Theme-Code — so überlebt sie einen Theme-Wechsel. Indexiert wird beim Speichern eines Beitrags oder Produkts und zusätzlich als geplanter Lauf über den Gesamtbestand. Statuswechsel behandeln wir mit: Was von veröffentlicht auf Entwurf, privat oder Papierkorb wechselt, fliegt aus dem Index. Die Schlüssel stehen in der wp-config.php oder als Umgebungsvariable, nicht in der Datenbank und nicht im Frontend-Skript. Für die Oberfläche kommen Template-Dateien und ein Block für den Editor dazu, damit die Redaktion Suchfeld und Filter selbst platzieren kann.
// cms-03statamic
Unter Statamic liegt Laravel, und das macht die Anbindung geradlinig. Ein Artisan-Command baut den Index über die Collections auf und läuft im Scheduler als Grundsicherung. Daneben hängt ein Ereignis beim Speichern eines Entries, das genau dieses eine Dokument aktualisiert; das Gegenstück beim Löschen nimmt es wieder heraus. Der Blueprint gibt vor, welche Felder ins Dokument wandern und welche im Control Panel bleiben. Die Schlüssel liegen in der .env, ins gerenderte Frontend geht ausschließlich der Suchschlüssel. Antlers oder Blade rendern Suchfeld, Filter und Trefferliste.
// entscheidung
zuordnung statt rangliste
Die nützliche Frage lautet nicht „welche Suche ist die beste“, sondern „was wird durchsucht, wie oft ändert es sich, und wo soll es liegen“. Drei Antworten, drei Zuordnungen — alle drei sind bei siteway im Werkzeugkasten.
// e-01pagefind
Überschaubare Inhaltsmengen aus Text, die sich mit dem Deploy ändern: Unternehmensseite, Magazin, Handbuch. Dafür ist Pagefind gemacht — Index beim Build, Suche im Browser, kein Dienst, der betrieben werden muss.
index beim build
// e-02meilisearch
Ein eigener Suchserver mit Filtern, Facetten und Toleranz — und Inhalte wie Suchanfragen, die die eigene Infrastruktur nicht verlassen. Das ist Meilisearch: selbst hostbar, dafür mit Betrieb, Aktualisierung und Sicherung im Plan.
eigener suchserver
// e-03algolia
Dieselbe Aufgabe, andere Betriebsform: Algolia ist ein gehosteter Dienst. Passt, wenn niemand im Haus einen Suchserver betreuen soll und die Fragen zu Region und Auftragsverarbeitung geklärt sind.
gehosteter dienst
Fünf Fragen entscheiden die Richtung, und sie lassen sich in einem Gespräch beantworten. Wie viele Einträge sind es, und wie oft ändern sie sich? Wonach soll gefiltert werden — und stehen diese Merkmale sauber in den Daten? Wonach wird bei Gleichstand sortiert? Wo dürfen Inhalte und Suchanfragen liegen? Und wer betreibt den Suchserver im Alltag, wenn Aktualisierungen anstehen?
Danach steht das Mapping als Dokument, bevor gebaut wird. Die Kategorie darüber beschreibt der Hub Suche, die buchbare Komponente liegt in der Expertise unter Suche. Wo ein Katalog mit Attributen und Filtern das eigentliche Thema ist, führt der Weg über Produktkatalog — dort geht es um die Datenpflege, hier um die Technik darunter. Welche Suche ein Projekt bekommt, klären wir im Konzept — vor dem Bauen, mit Begründung.
// faq
Meilisearch ist eine quelloffene Suchmaschine, die du auf deiner eigenen Infrastruktur betreiben kannst — alternativ gibt es sie als Cloud-Dienst des Herstellers. Inhalte werden als Dokumente in einen Index geschrieben, und die Suchanfrage geht an genau den Server, auf dem dieser Index liegt. Steht dieser Server bei dir, verlassen weder die indexierten Inhalte noch die Suchbegriffe deiner Besucher deine Infrastruktur. Der Kern des Projekts steht unter der MIT-Lizenz und liegt öffentlich einsehbar vor; einzelne Zusatzfunktionen stellt der Hersteller unter eine eigene Lizenz.
Kontrolle und Verantwortung im selben Paket. Der Suchserver läuft als eigener Dienst neben der Website und braucht Arbeitsspeicher und Plattenplatz für den Index, eine Absicherung nach außen, regelmäßige Aktualisierungen und eine Sicherung. Meilisearch unterscheidet dafür zwei Wege: Snapshots sind eine exakte Kopie der Datenbank und dienen der schnellen Wiederherstellung, Dumps sind ein portables Abbild und der dokumentierte Weg beim Wechsel auf eine neue Version. Wo dieser Dienst läuft und wer ihn im Alltag betreut, ist eine Betriebsentscheidung und gehört ins Konzept, nicht ans Ende des Projekts.
In zwei Stufen. Zur Einrichtung läuft eine Voll-Indexierung über den kompletten Bestand, gebündelt statt Dokument für Dokument; danach werden nur noch Änderungen nachgezogen. Jedes Dokument trägt dafür einen Primärschlüssel, über den derselbe Inhalt beim zweiten Lauf wiedererkannt und aktualisiert statt doppelt angelegt wird. Fehlt dieser Schlüssel oder passt er nicht zum Index, meldet Meilisearch einen Fehler und übernimmt keine Dokumente. Der Rückweg wird leicht vergessen: Was im CMS gelöscht oder auf Entwurf gesetzt wird, muss aktiv aus dem Index entfernt werden — sonst steht der Treffer weiter in der Suche, obwohl die Seite nicht mehr existiert. Entwürfe und geschützte Inhalte halten wir deshalb von vornherein aus dem Index heraus.
Weil Meilisearch dafür anders indexieren muss. Ein Attribut lässt sich erst filtern, wenn es in den Einstellungen des Index als filterbares Attribut hinterlegt ist; diese Liste ist im Auslieferungszustand leer. Die Dokumentation ist an der Stelle eindeutig: Der Schritt ist verpflichtend und lässt sich nicht zur Suchzeit nachholen, weil eine Änderung an dieser Liste eine erneute Indexierung auslöst. Genauso verhält es sich mit den sortierbaren Attributen. Das ist der häufigste Stolperstein bei der ersten Anbindung — die Suche antwortet, aber der Filter bleibt leer. Wir legen deshalb schon im Mapping fest, welche Attribute durchsuchbar, welche filterbar und welche sortierbar sein sollen.
Über eine Reihe von Regeln, die nacheinander greifen. Die erste Regel sortiert alle Treffer in Gruppen, die nächste entscheidet nur noch innerhalb einer Gruppe, und so weiter. In der dokumentierten Standardreihenfolge sind das die Anzahl der getroffenen Suchwörter, die Zahl der Tippfehler, die Nähe der Wörter zueinander, die Rangfolge der Attribute, eine zur Suchzeit gewählte Sortierung, die Position im Text und die Genauigkeit der Übereinstimmung. Darunter lassen sich eigene Regeln hängen, die bei Gleichstand nach einem Feld aus deinen Daten entscheiden, etwa nach einem Beliebtheitswert oder einem Datum. Genau dort steckt die Arbeit an einer Suche, die zur Sache passt.
Meilisearch trennt die Schlüssel nach Rechten. Ganz oben steht der Master-Schlüssel: Er schützt die gesamte Instanz, ist im Produktivbetrieb vorgeschrieben und bleibt ausschließlich auf dem Server. Aus ihm leiten sich API-Schlüssel mit begrenzten Rechten ab, darunter ein Schlüssel für administrative Aufgaben wie Einstellungen und Dokumente und ein Suchschlüssel mit reiner Leseberechtigung. Ins Frontend gehört ausschließlich der Suchschlüssel. Die Dokumentation sagt es unmissverständlich: Administrative Schlüssel haben in einem öffentlichen Frontend nichts verloren. Wir legen sie deshalb in der Umgebungskonfiguration ab, nie im Quelltext einer Seite und nie in einem JavaScript-Bundle.
Beim Selbsthosting ist die Antwort angenehm kurz: Inhalte und Suchanfragen bleiben in deiner eigenen Infrastruktur, es geht keine Anfrage an einen Dritten, und für die Suche braucht es keine Auftragsverarbeitung. Dafür trägst du die Verantwortung für den Betrieb — Zugriffsschutz, Aktualisierungen, Sicherung. Nutzt du stattdessen den Cloud-Dienst des Herstellers, gelten dieselben Fragen wie bei jedem gehosteten Dienst: Wo wird betrieben, wer verarbeitet im Auftrag, was muss überhaupt in den Index. In beiden Fällen gilt für uns Datensparsamkeit: In den Index geht der Ausschnitt, der für die Suche gebraucht wird. Wie wir das im Projekt einordnen, steht im Stack unter Sicherheit und Datenschutz. Eine Rechtsberatung ist das nicht.
Ja, in allen drei Systemen — und wir bauen die Anbindung jeweils selbst mit den Bordmitteln des Systems. Die Kette ist überall dieselbe: Der Inhalt wird serverseitig in Dokumente übersetzt und an den Suchserver geschickt, ein Ereignis beim Speichern zieht Änderungen sofort nach, ein geplanter Lauf hält den Bestand als Grundsicherung nach, und das Frontend fragt mit einem Schlüssel, der nur lesen darf. In TYPO3 entsteht dafür eine eigene Extension mit der Indexierung als Scheduler-Task, einem Hook beim Speichern und der Oberfläche in Fluid. In WordPress bauen wir ein eigenes Plugin statt Theme-Code, mit Indexierung beim Speichern und als geplantem Lauf; die Schlüssel stehen in der wp-config.php oder als Umgebungsvariable. In Statamic liegt Laravel darunter: ein Artisan-Command im Scheduler, ein Ereignis beim Speichern eines Entries und die Schlüssel in der .env.
// womit das zusammenhängt
hub, technik & leistung
// stack · hub
Die Kategorie über diesem Dienst: wie wir pro Projekt zwischen statischer Suche und Suchserver auswählen — und was das im Betrieb bedeutet.
zum hub →
// stack · statisch
Der Weg für überschaubare Textbestände: Index beim Build, Suche im Browser, ohne Suchserver. Diese Website sucht damit.
zur technik →
// stack · gehostet
Dieselbe Aufgabe als gehosteter Dienst: Facetten und Ranking ohne eigenen Suchserver — dafür mit Region und Auftragsverarbeitung als Thema.
zur technik →
// stack · betrieb
Wo der Suchserver läuft, wie er aktualisiert und gesichert wird: die Betriebsentscheidung hinter einer selbst gehosteten Suche.
zur technik →
// leistung · buchbar
Die fertige Suchfunktion für deine Website: Index, Gewichtung, Oberfläche und die passende Technik nach Größe. Hier wird gebucht.
zur leistung →
// leistung · katalog
Wo Filter herkommen: saubere Attribute im Katalog sind die Voraussetzung dafür, dass filterbare Attribute in der Suche überhaupt etwas hergeben.
zur leistung →
Die Anbindung selbst — Datenmodell, Auslöser, Fehlerfall, Schlüssel — gehört zur Schnittstellenentwicklung. Dort steht, wie wir Systeme grundsätzlich miteinander sprechen lassen; hier steht, was Meilisearch dabei besonders macht.
// Eine schnelle Suche, die im eigenen Haus bleibt?
Projekt anfragen