Suchfunktion für deine Website: welche Stufe du brauchst – und was sie kostet

Die meisten Website-Suchen sind schlecht: Sie verzeihen keine Tippfehler, sortieren Treffer ohne erkennbare Logik, und niemand schaut in ihre Protokolle. Die Frage ist dabei selten, welche Suchtechnologie «die beste» ist. Die Frage ist, welche Stufe dein Projekt braucht – und ab wann die nächste Stufe ihr Geld wert ist.

Wir denken Website-Suche bei happycoding in drei Stufen. Stufe 1: die Postgres-Volltextsuche, die in deiner Datenbank vermutlich schon steckt. Stufe 2: Meilisearch, eine eigenständige Suchmaschine mit Typo-Toleranz und Facetten. Stufe 3: Elasticsearch oder OpenSearch, wenn Suche und Auswertung dein Kerngeschäft berühren.

In diesem Artikel bekommst du drei Dinge: konkrete Kriterien, wann welche Stufe reicht. Reale Kosten mit Abrufdatum statt «kommt drauf an». Und den einen Hebel, den fast alle übersehen: dein Suchprotokoll. Am Ende kannst du die Entscheidung selbst treffen oder zumindest jedes Agentur-Angebot sauber einordnen.

Warum wir das aufschreiben? Weil die Ratgeber-Landschaft zu diesem Thema erstaunlich leer ist: Was du heute zu «Suchfunktion Website» findest, sind CMS-Klickanleitungen und Forenbeiträge. Eine Entscheidungshilfe entlang der Technologie-Stufen, mit echten Kosten und Datum, haben wir nicht gefunden. Also gibt es sie jetzt.

Noch eine Abgrenzung, bevor es losgeht: Dieser Artikel handelt von der Endnutzer-Suche auf deiner Website oder in deinem Shop. Wissenssuche in internen Anwendungen, also RAG auf eigenen Dokumenten, ist eine eigene Baustelle mit eigenem Werkzeugkasten. Die Trennlinie ziehen wir weiter unten noch einmal scharf.

Bevor du eine neue Suchmaschine einkaufst, schau in deine Datenbank: PostgreSQL bringt eine vollwertige Volltextsuche mit. Wenn deine Website ohnehin auf Postgres oder Supabase läuft, ist Stufe 1 keine Anschaffung, sondern eine Konfiguration.

Die Postgres-Volltextsuche arbeitet mit tsvector und tsquery: Texte werden in Wortstämme zerlegt, sodass «Dichtungen» auch Seiten mit «Dichtung» findet. Dazu kommen Relevanz-Ranking inklusive Wortnähe, Phrasensuche und vorkonfigurierte Sprachprofile, Deutsch eingeschlossen (postgresql.org, Abruf 04.09.2026).

Was fehlt, ist Typo-Toleranz: Der Suchbegriff «Dichtungsrng» liefert in der Standard-Volltextsuche null Treffer. Mit der Erweiterung pg_trgm kannst du Fuzzy-Matching über Trigramme nachrüsten, mit eigenen Indizes, eigenen Schwellwerten und eigener Abfragelogik. Das funktioniert, ist aber Handarbeit statt eingebauter Standard.

In der Praxis heißt Stufe 1: ein Suchendpunkt in deiner bestehenden Anwendung, der die Datenbank abfragt, die du ohnehin betreibst. Kein zweites System, kein zweiter Index, keine Synchronisierung. Was du trotzdem bauen musst, ist die Ergebnisseite selbst: Trefferliste, Hervorhebung, leerer Zustand. Die Suchlogik ist bei Stufe 1 oft der kleinste Teil der Arbeit.

Unsere Faustregel aus Projekten: Stufe 1 genügt, wenn vier Kriterien zusammenkommen.

Überschaubarer Bestand: Deine Website hat wenige hundert Seiten oder Datensätze. In dieser Größenordnung liefert die Volltextsuche brauchbare Treffer, ohne dass du an der Relevanz lange feinjustieren musst.

Keine Facetten: Niemand muss Ergebnisse nach Kategorie, Preis oder Hersteller filtern. Sobald Filterleisten ins Spiel kommen, bist du in Stufe 2.

Suche ist Nebenfunktion: Deine Besucher navigieren primär über Menü und interne Links. Die Suche ist ein Fallback, kein zentrales Bedienelement.

Daten liegen schon in Postgres: Dann entfällt die größte Aufwandsposition jeder Suchlösung, nämlich die Indexierungs-Pipeline. Du fragst einfach die Datenbank ab, die du ohnehin betreibst.

Erfüllst du alle vier Punkte, ist eine neue Suchmaschine rausgeworfenes Geld: Du würdest ein zweites System betreiben, das nichts findet, was Postgres nicht auch findet. Reißt einer der Punkte, lies weiter.

Sobald deine Suche ein Produktmerkmal ist, etwa im Shop, im Kundenportal oder in der Wissensdatenbank, lohnt sich eine dedizierte Suchmaschine. Unsere Standardempfehlung dafür ist Meilisearch. Was das Werkzeug genau ist und wie es sich einordnet, haben wir im CIO-Guide zu Meilisearch aufgeschrieben.

Meilisearch ist auf Instant Search gebaut: Ergebnisse erscheinen beim Tippen, Typo-Toleranz und Facetten sind Standard statt Zusatzprojekt. Aus «Dichtungsrng» wird ohne Konfiguration «Dichtungsring». Der Hersteller verspricht Antworten in unter 50 Millisekunden – das ist eine Vendor-Angabe (meilisearch.com, Abruf 04.09.2026), deckt sich aber mit unserer Projekterfahrung bei üblichen Datenmengen.

Auch semantische Suche steckt im normalen Binary: Über den Parameter semanticRatio mischst du Volltext- und Vektortreffer stufenlos. Als Embedding-Quellen sind unter anderem OpenAI, Cohere, Mistral, Gemini und HuggingFace angebunden, dazu ein REST-Embedder für beliebige APIs. Was das konkret bringt und wann es Overkill ist, liest du im Artikel zur semantischen Suche.

Zur Einordnung: Meilisearch findet Dokumente für deine Besucher. Wenn du Fragen in natürlicher Sprache beantworten willst, bist du bei RAG – einem anderen Werkzeug für ein anderes Problem, das wir in RAG vs. Fine-Tuning auseinandernehmen.

Die Lizenz hat seit August 2025 zwei Hälften, und beide gehören in jede seriöse Empfehlung. Der Kern ist MIT-lizenziert: frei nutzbar, auch produktiv und kommerziell. Daneben steht die Enterprise Edition unter der Business Source License 1.1: Produktivbetrieb nur mit Vertrag, jeder Versionsstand wird nach vier Jahren MIT. Enterprise-exklusiv sind derzeit Module wie Sharding, also verteilte Setups, dazu Analytics- und Zugriffskontroll-Funktionen (meilisearch.com/blog, Abruf 04.09.2026).

Zu den Preisen, Abruf 04.09.2026: Meilisearch Cloud startet bei 20 $ pro Monat. Der Kostenrechner nennt für 100.000 Dokumente und 50.000 Suchanfragen rund 30 $ monatlich. Self-Hosting ist kostenlos; dafür liegen Updates, Backups und Skalierung bei dir.

Für unsere Positionierung zählt noch ein dritter Weg: Self-Hosting auf einem eigenen Server in der EU. Deine Suchanfragen, und damit ein erstaunlich ehrliches Abbild dessen, was deine Besucher wollen, bleiben dann vollständig auf deiner Infrastruktur. Gepflegt wird das Projekt aktiv: Zum Abruf am 04.09.2026 ist v1.53.1 vom 13. August 2026 der aktuelle Stand.

Stufe 3 ist für Fälle, in denen Suche mehr ist als eine Suchleiste: Auswertungen über Millionen von Ereignissen, Logdaten-Analyse, sehr große oder schnell wachsende Datenmengen. Elasticsearch und OpenSearch sind dafür gebaut – und sie verlangen dafür ein eigenes Betriebsteam oder ein Budget für Managed Hosting.

Typische Signale, dass du wirklich in Stufe 3 bist: Du willst nicht nur finden, sondern auswerten, etwa Suchtrends über Monate oder Dashboards über Logdaten. Deine Datenmenge wächst schneller, als eine einzelne Instanz mitwächst. Und es gibt jemanden im Haus, der den Cluster als Teil seiner Arbeit betreibt, nicht nebenbei.

Kurz zur Lizenzlage, weil sie oft falsch erzählt wird. Elasticsearch ist seit Ende August 2024 dreifach lizenziert: ELv2, SSPL und zusätzlich AGPL (elastic.co, Abruf 04.09.2026). OpenSearch, Anfang 2021 als Fork von Elasticsearch entstanden, steht unter Apache 2.0 und gehört seit September 2024 zur OpenSearch Software Foundation unter dem Dach der Linux Foundation (linuxfoundation.org, Abruf 04.09.2026).

Für dich heißt das: Beide Optionen sind lizenzseitig für den Produktivbetrieb gangbar. Die Entscheidung fällt über Betrieb und Ökosystem, nicht über die Lizenz.

Unsere ehrliche Grenze: Wir raten den meisten Kunden von Stufe 3 ab. Ein Cluster will dimensioniert, überwacht, aktualisiert und abgesichert werden – laufende Kosten, die eine Website-Suche selten rechtfertigt. Welche der beiden Optionen wann passt, vergleichen wir in Elasticsearch vs. OpenSearch; leichtgewichtige Auswege sammeln wir in den Elasticsearch-Alternativen.

Vorab: Die folgenden Aufwände sind Erfahrungswerte von happycoding aus eigenen Projekten, keine Marktdaten. Dein Fall kann abweichen – nach oben wie nach unten.

Stufe 1 ausreizen: Volltextsuche auf bestehenden Postgres-Daten aufsetzen, inklusive Ranking und deutschem Sprachprofil, kostet bei uns typischerweise zwei bis fünf Personentage. Mit nachgerüsteter pg_trgm-Typo-Toleranz eher am oberen Rand.

Stufe 2 einführen: Meilisearch aufsetzen, Daten hineinsynchronisieren und ein Suchinterface mit Facetten bauen, liegt bei uns meist zwischen einer und drei Wochen. Der Server selbst läuft schnell; die Zeit geht in die Ränder drumherum.

Stufe 3 einführen: Ein Elasticsearch- oder OpenSearch-Setup beginnt bei mehreren Wochen und endet nie ganz, weil der Betrieb dauerhaft Aufmerksamkeit braucht. Deshalb steht diese Stufe bei uns nur zur Debatte, wenn die Anforderungen sie erzwingen.

Die drei größten Aufwandstreiber sind in allen Stufen dieselben. Die Indexierungs-Pipeline: Wie kommen Änderungen aus deinem System zuverlässig in den Suchindex? Das Facetten-Datenmodell: Filter sind nur so gut wie die Datenfelder dahinter. Und Mehrsprachigkeit: Jede Sprache braucht eigene Sprachprofile und oft eigene Indizes.

Für dein nächstes Agentur-Angebot heißt das: Lass dir den Aufwand entlang dieser drei Treiber aufschlüsseln. Ein Pauschalpreis für «Suche einbauen» ohne Blick auf Datenmodell und Mehrsprachigkeit ist keine Kalkulation, sondern eine Wette.

Egal welche Stufe du wählst: Protokolliere jede Suchanfrage, besonders die mit null Treffern. Dieses Protokoll ist die günstigste Nutzerforschung, die du bekommen kannst – deine Besucher tippen dir wörtlich, was sie erwarten und nicht finden.

Null-Treffer-Anfragen sind konkret drei Listen zugleich. Ein Synonym-Backlog: Suchen Leute «Rechnung», deine Seite sagt aber «Beleg», pflegst du das Synonym ein. Eine Content-Lückenliste: Häufige Suchen ohne passende Seite sind ein Redaktionsplan, den dir niemand in Rechnung stellt. Und eine Produktideen-Quelle: Wiederkehrende Anfragen nach Funktionen, die es nicht gibt, sind Feature-Wünsche in Rohform.

Praktisch brauchst du dafür wenig: Logge Suchbegriff, Trefferzahl und Zeitstempel, mehr nicht. Schon eine simple Datenbanktabelle reicht für den Anfang. Wichtig ist die Routine: einmal im Monat die häufigsten Null-Treffer-Anfragen anschauen und drei davon beheben. Das ist eine Stunde Arbeit mit messbarem Ergebnis.

Dass hier viel liegen bleibt, zeigt die Forschung von Baymard: In groß angelegten Nutzertests von E-Commerce-Suchen traten mehr als 700 such-spezifische Usability-Probleme auf, und der Benchmark über 344 große US- und EU-Websites attestiert der Website-Suche insgesamt einen schwachen Zustand (baymard.com, Abruf 04.09.2026). Die Konversions-Multiplikatoren, die dazu kursieren, zitieren wir bewusst nicht: Die Primärquellen sind nicht frei zugänglich.

Und noch einen Schritt weiter gedacht: Wer aus Suchanfragen systematisch Funktionen ableitet, baut irgendwann Software statt nur Suche. Genau dort beginnt für uns Individualsoftware – nicht mit einer Idee auf der grünen Wiese, sondern mit belegtem Bedarf aus deinem eigenen Suchprotokoll.

Mach den Selbsttest mit drei Fragen. Erstens: Brauchen deine Besucher Filter oder Tippfehler-Toleranz? Nein heißt Stufe 1. Zweitens: Ist die Suche ein Feature deines Produkts? Ja heißt Stufe 2, in den meisten Fällen Meilisearch. Drittens: Brauchst du Auswertungen über sehr große Datenmengen und hast ein Betriebsteam? Nur dann ist Stufe 3 eine Antwort.

Der günstigste erste Schritt kostet dich keinen Cent: Aktiviere heute dein Suchprotokoll und schau in zwei Wochen auf die Null-Treffer-Liste. Sie sagt dir zuverlässiger als jede Beratung, ob deine Besucher an der Suche scheitern – und woran genau.

Wird die Suche Teil einer größeren Anwendung, etwa eines Portals oder Shops, findest du unsere Herangehensweise unter Web-App entwickeln lassen. Und wenn du unsicher bist, welche Stufe zu deinem Projekt passt: Buch dir ein kostenloses Erstgespräch mit mir – wir schauen gemeinsam auf deine Daten, dein Suchprotokoll und die ehrlichste Antwort auf die Frage, ob du überhaupt etwas Neues brauchst.