Intelligente Suche für PrestaShop: Wenn die Standardsuche nicht ausreicht

Zuletzt geprüft im Juni 2026 — natives Verhalten anhand der PrestaShop-Core-Klasse Search und der Einstellungen unter Shop-Parameter → Suche in 1.7.6+, 8.x und 9.x verifiziert.

Ein Kunde gibt "bycicle helmet" in Ihre Suchleiste ein. Gemeint war "bicycle helmet" — ein vertauschter Buchstabe. In einer frischen PrestaShop-Installation bekommt er oft tatsächlich Ergebnisse, weil PrestaShop seit Jahren eine Fuzzy-Suche eingebaut hat. Aktivieren Sie aber den falschen Schalter, spielen Sie ein großes Synonym-Vokabular ein, auf das Ihr Katalog nie ausgelegt war, oder lassen Sie den Suchindex veralten, sieht derselbe Kunde eine leere Seite, nimmt an, dass Sie keine Helme führen, und geht. Dabei liegen 47 Stück im Lager. In diesem Beitrag geht es um die konkrete Lücke zwischen dem, was die native PrestaShop-Suche tatsächlich leistet — und das ist mehr, als viele Händler denken — und dem Punkt, an dem sie wirklich an ihre Grenzen kommt.

Diese Unterscheidung ist wichtig, weil der übliche Rat ("Die Standardsuche ist dumm, kaufen Sie ein Suchmodul") nur halb stimmt und Sie in beide Richtungen Geld kostet. Manche Shops verlieren Umsatz wegen Einstellungen, die sie heute Nachmittag kostenlos im Backoffice korrigieren könnten. Andere haben bereits jeden nativen Hebel ausgereizt und verlieren trotzdem Besucher mit klarer Kaufabsicht — für sie ist eine andere Suchmaschine die ehrliche Antwort. Zu welcher Gruppe Sie gehören, erkennen Sie erst, wenn Sie wissen, was die native Suche wirklich tut.

Was die native PrestaShop-Suche tatsächlich macht (mehr, als Sie denken)

Das Suchfeld im Frontoffice wird vom SearchController und der Core-Klasse Search (classes/Search.php) verarbeitet. Es führt keinen naiven LIKE '%term%'-Scan über Ihre Produkte aus. Stattdessen zerlegt PrestaShop bei jedem Speichern eines Produkts die indexierbaren Felder in Tokens und schreibt sie in die Tabellen ps_search_word und ps_search_index; bei der Anfrage wird gegen diesen vorbereiteten Index gesucht und die Treffer werden bewertet. Drei native Verhaltensweisen überraschen die meisten Händler:

• Fuzzy Matching (tippfehlertolerante Suche) ist eingebaut. Mit der Einstellung PS_SEARCH_FUZZY kann PrestaShop ein Suchwort mit einem indexierten Wort innerhalb einer kleinen Editierdistanz abgleichen — sodass "bycicle" trotzdem "bicycle" finden kann. Prüfen Sie unter Shop-Parameter → Suche, ob die ungefähre bzw. Fuzzy-Suche aktiviert ist. Der Wert PS_SEARCH_FUZZY_MAX_LOOP begrenzt, wie intensiv PrestaShop pro Wort sucht, damit die Suche schnell bleibt. Der Mythos, PrestaShop liefere bei jedem Tippfehler null Ergebnisse, ist schlicht veraltet.
• Synonyme gibt es bereits, nur unter anderem Namen. PrestaShop nennt sie Aliase und speichert sie in der Tabelle ps_alias. Sie verwalten sie im Backoffice unter Shop-Parameter → Suche → Aliase. Ordnen Sie "couch" "sofa" zu, "trainers" "sneakers", "telly" "television", und das Wort des Suchenden wird in Ihr Wort umgeschrieben, bevor der Index abgefragt wird.
• Relevanz wird gewichtet, und die Gewichtungen legen Sie fest. Dieselbe Einstellungsseite für die Suche bietet eine Gewichtung für jedes indexierte Feld — Produktname, Artikelnummer/EAN/MPN, Kurzbeschreibung, ausführliche Beschreibung, Kategoriename, Hersteller, Tags, Attribute und Eigenschaften. Ein Treffer im Produktnamen kann deutlich stärker zählen als eine beiläufige Erwähnung tief in einer Beschreibung. Genau so verhindern Sie, dass bei "red dress" ein roter Werkzeugkasten vor den eigentlichen Kleidern erscheint.

Was heißt das konkret für Sie? Bevor Sie Geld ausgeben, öffnen Sie zuerst die nativen Sucheinstellungen und prüfen Sie, ob die Fuzzy-Suche aktiv ist, ob die Feldgewichtungen zu Ihrem Katalog passen und ob Sie mit einer Alias-Liste begonnen haben. Ein relevanter Teil der Beschwerden über eine "kaputte Suche" ist in Wahrheit eine nie konfigurierte Standardeinstellung, eine leere Alias-Liste oder — sehr häufig — ein veralteter Index.

Die mit Abstand häufigste Ursache für "die Suche ist kaputt": ein veralteter Index

Weil PrestaShop nicht Ihre Live-Produkttabelle durchsucht, sondern einen vorbereiteten Index, kann alles, was außerhalb des normalen Speicherns eines Produkts passiert, dazu führen, dass der Index einen Katalog beschreibt, den es so nicht mehr gibt. Massenimporte, SQL-Updates, wiederhergestellte Backups, Multishop-Änderungen oder eine halb abgeschlossene Migration lösen genau das aus. Das Symptom ist frustrierend: Ein Produkt ist auf seiner Seite eindeutig live, aber die Suche nach seinem exakten Namen liefert nichts.

Die Lösung ist, den Index neu aufzubauen. Auf der Seite Shop-Parameter → Suche gibt es die Aktion "Gesamten Index neu aufbauen" (und für kleinere Korrekturen die Option "Fehlende Produkte zum Index hinzufügen"). Bei größeren Katalogen sollten Sie das über den Cron-Task statt im Browser ausführen, damit kein Timeout entsteht.

PrestaShop bringt genau dafür einen Cron-Endpunkt für den Suchindex mit. Der Button auf der Suchseite ruft ihn mit einem Flag für den vollständigen Neuaufbau auf; denselben Job können Sie regelmäßig ausführen. Die Formularfelder zeigen Ihnen die URL — der vollständige Neuaufbau ergänzt &full=1, der leichtere Durchlauf "fehlende Produkte hinzufügen" lässt es weg:

# Full rebuild (use after a bulk import / restore / SQL change)
curl -s "https://yourstore.com/searchcron.php?id_shop=1&token=YOUR_SEARCH_TOKEN&full=1"

# Lighter pass: only index products missing from ps_search_index
curl -s "https://yourstore.com/searchcron.php?id_shop=1&token=YOUR_SEARCH_TOKEN"

Das token ist der Wert, den PrestaShop neben den Index-Aktionen auf der Seite mit den Sucheinstellungen anzeigt (denken Sie sich keinen aus — kopieren Sie die exakte URL, die PrestaShop Ihnen gibt). Binden Sie den Aufruf für den vollständigen Neuaufbau in Ihre Importroutine ein, und die ganze Ticket-Kategorie "Suche ist kaputt" durch veraltete Indizes verschwindet weitgehend.

Machen Sie den Index-Neuaufbau zu einem Standardschritt nach jedem Massenimport — es ist die günstigste Suchkorrektur überhaupt und löst einen großen Teil der "meine Suche ist kaputt"-Tickets sofort.

Wo die native Suche wirklich an ihre Grenze stößt

All das macht die native Suchmaschine nicht grenzenlos. Nachdem Sie Gewichtungen konfiguriert, Aliase gepflegt und den Index aktuell gehalten haben, bleiben vier echte Grenzen — und genau diese lohnen es, mit einem Modul zu beseitigen.

Die letzte Spalte ist der ehrliche Test. Wenn Ihr Problem in Spalte eins liegt, haben Sie wahrscheinlich ausgeschöpft, was Konfiguration leisten kann, und eine dedizierte Suchschicht ist eine vernünftige Investition statt Luxus.

Ein Hinweis zu den zwei PrestaShop-"Such"-Funktionen, die oft verwechselt werden

Es lohnt sich, zwei Dinge zu trennen, die beide "Suche" genannt werden. Das Suchfeld (dieser Artikel) beantwortet eine getippte Anfrage — "bicycle helmet" — und wird von der Core-Klasse Search angetrieben. Die Facettensuche (das Modul ps_facetedsearch) ist die Filter-Seitenleiste links auf Kategorieseiten — Preis, Marke, Farbe, Größe — für einen Kunden, der bereits in einer Kategorie stöbert und die Auswahl eingrenzen möchte. Beide lösen unterschiedliche Aufgaben, und in der Regel brauchen Sie beides. Wenn Ihr eigentliches Problem darin besteht, Kunden nach dem Einstieg in eine große Kategorie beim Aussortieren zu helfen, dann ist das der Filter-Artikel, nicht dieser hier: siehe Kunden helfen, Produkte in großen Katalogen zu finden und Kategorieseiten, die konvertieren.

Was eine dedizierte Suchschicht ergänzt — und warum sie sich bezahlt macht

Wenn Sie aus der nativen Suche herausgewachsen sind, "sucht" ein spezialisiertes Suchmodul nicht einfach abstrakt besser; es beseitigt die vier konkreten Grenzen oben. Die entscheidenden Funktionen, jeweils über das Geschäftsproblem gedacht, das sie lösen:

• Sofortige AJAX-Ergebnisse während der Eingabe. Ein Dropdown mit passenden Produkten — inklusive Bild, Preis und Direktlink — erscheint, bevor der Kunde das Wort fertig getippt hat. Das ist der größte wahrgenommene Qualitätssprung und verkürzt den Weg von der Absicht zur Produktseite.
• Verwaltete Synonyme statt einzelner Aliase. Gruppieren Sie "couch = sofa = settee" einmal, und jede Variante wird aufgelöst. So kostet ein vergessener Plural oder regionaler Begriff keinen Verkauf mehr.
• Analysen zu Null-Treffer-Suchen. Ein Protokoll, das genau zeigt, welche Suchanfragen nichts geliefert haben, macht verlorene Suchen zu einer Aufgabenliste: Jede leere Anfrage ist entweder ein Produkt, das Sie aufnehmen sollten, ein Synonym, das fehlt, oder eine Beschreibung, die korrigiert werden muss. Diese Nachfragedaten bekommen Sie auf keinem anderen Weg.
• Weiterleitungen und Muster-Routing. Leiten Sie eine bekannte Falschschreibung, einen Markennamen oder ein Kampagnen-Keyword direkt auf die passende Seite. Muster-Routing behandelt ganze Suchanfrage-Familien mit einer Regel — zum Beispiel kann jede "NxN"-Größe wie "800x800" oder "90x90" auf Ihrer Größenseite landen statt in einer dünnen Trefferliste.
• Merchandising und Boosting. Schieben Sie margenstarke, lieferbare oder saisonale Produkte bei ausgewählten Begriffen nach oben, damit die Suche aktiv verkauft, statt nur aufzulisten.

Genau diese Lücke schließt unser Modul MPR Search Revolution für PrestaShop: Echtzeit-AJAX-Suche, verwaltete Synonymgruppen, ein Analyse-Dashboard für Suchanfragen, das Null-Treffer- und Trend-Suchen sichtbar macht, Begriffsumleitungen mit musterbasierter Weiterleitung und Produkt-Boosting — alles aus dem Backoffice konfiguriert, ohne Theme-Umbau oder Core-Änderungen, damit es Updates übersteht. Was heißt das konkret für Sie? Die nativen Hebel, die Sie sonst von Hand nachjustieren würden (Synonyme, Relevanz, Weiterleitungen), werden zu einem verwalteten Arbeitsablauf, und die Suchen, die Sie bisher lautlos verloren haben, werden zu einer messbaren, korrigierbaren Liste. Außerdem halten wir im Backoffice einen Suchsimulator bereit, damit Sie testen können, welche Ergebnisse eine bestimmte Anfrage liefert, bevor Ihre Kunden es tun.

So entscheiden Sie — ein kurzer Rahmen

Gehen Sie diese Punkte der Reihe nach durch; stoppen Sie beim ersten Schritt, der Ihr Problem löst.

• Die Suche liefert nichts für Produkte, die eindeutig existieren? Bauen Sie den Index neu auf (Shop-Parameter → Suche). Machen Sie das nach jedem Import zur Routine.
• Irrelevante Produkte stehen vor den richtigen? Erhöhen Sie auf derselben Seite die Gewichtung des Produktnamens und senken Sie die Gewichtung der ausführlichen Beschreibung.
• Einige bekannte Synonyme oder Falschschreibungen funktionieren nicht? Legen Sie sie als Aliase an. Wenn die Liste kurz und stabil ist, reichen native Aliase wirklich aus — kaufen Sie nicht mehr, als Sie brauchen.
• Sie brauchen Sofortergebnisse, skalierbare Synonyme, Daten zu Null-Treffer-Suchen oder Merchandising-Steuerung? Das sind die vier nativen Grenzen. Hier ist eine dedizierte Suchschicht die richtige Entscheidung, kein Konfigurationstrick.

Suche ist Teil eines größeren Findability-Bildes

Das Suchfeld ist einer von drei Wegen, über die ein Kunde ein Produkt findet, und die anderen sollten ihren Teil tragen, damit die Suche nicht die ganze Arbeit allein leisten muss. Eine starke Kategoriestruktur und ein klares Mega-Menü lassen Menschen zu dem navigieren, was sie möchten, ohne überhaupt zu tippen, während seiteninterne Filter eine Kategorie nach dem Einstieg eingrenzen. Und weil ein großer und wachsender Anteil dieser Suchen inzwischen auf dem Smartphone stattfindet, muss das Dropdown während der Eingabe daumenfreundlich und schnell sein — siehe Mobile Commerce.

Ihre Suchleiste gehört zu den wertvollsten Flächen auf der Website: Jeder, der sie nutzt, hat Ihnen bereits mit eigenen Worten gesagt, was er kaufen möchte. Kunden, die suchen, konvertieren tendenziell deutlich häufiger als reine Stöberer — sie haben Absicht —, deshalb ist eine fehlgeschlagene Suche ein Besucher mit hoher Kaufabsicht, der den Shop verlässt. Die gute Nachricht: Die günstigsten Korrekturen (ein frischer Index, sinnvolle Gewichtungen, eine erste Alias-Liste) sind kostenlos und liegen jetzt schon in Ihrem Backoffice. Investieren Sie erst dann in eine dedizierte Suchschicht, wenn Sie an die nativen Grenzen stoßen — und wenn Sie es tun, lassen Sie sie ihren Wert täglich belegen, indem sie Ihnen genau zeigt, welche Suchen Sie früher verloren haben.

Häufig gestellte Fragen

Kann die PrestaShop-Standardsuche überhaupt mit Tippfehlern umgehen?

Ja — Fuzzy Matching, also ungefähre Treffer, ist seit Jahren eingebaut und wird über die Einstellung PS_SEARCH_FUZZY unter Shop-Parameter → Suche gesteuert. Dabei wird ein Suchwort mit einem indexierten Wort innerhalb einer kleinen Editierdistanz abgeglichen, sodass "bycicle" trotzdem "bicycle" finden kann. Die alte Behauptung, jeder Tippfehler liefere null Ergebnisse, ist veraltet; die übliche Ursache für echte Null-Treffer bei einem offensichtlichen Tippfehler ist, dass die Fuzzy-Suche deaktiviert wurde oder der Index veraltet ist.

Mein Produkt ist live, aber die Suche nach dem exakten Namen findet nichts — warum?

Fast immer ist der Index veraltet. PrestaShop durchsucht die vorbereiteten Tabellen ps_search_word / ps_search_index, nicht Ihre Live-Produkttabelle. Alles, was Produkte außerhalb des normalen Speicherns ändert — Massenimporte, SQL-Updates, wiederhergestellte Backups, Migrationen — kann daher dazu führen, dass der Index einen Katalog beschreibt, der nicht mehr passt. Bauen Sie den Index über die Suchseite (oder den Cron-Endpunkt oben) neu auf, dann ist das Produkt wieder auffindbar.

Unterstützt PrestaShop Synonyme?

Ja, unter einem anderen Namen: Aliase, gespeichert in ps_alias und verwaltet unter Shop-Parameter → Suche → Aliase. Ordnen Sie "couch" "sofa" zu, "trainers" "sneakers", und das Wort des Suchenden wird in Ihr Wort umgeschrieben, bevor der Index abgefragt wird. Wenn die Liste kurz und stabil ist, reichen sie wirklich aus; die Grenze liegt darin, dass jedes Synonym eine manuelle Zeile ist, was bei den Hunderten Begriffen, die ein echter Katalog irgendwann braucht, nicht skaliert.

Warum stehen irrelevante Produkte vor den richtigen?

Relevanz ist gewichtet, und die Gewichtungen bestimmen Sie. Die Seite mit den Sucheinstellungen bietet eine Gewichtung pro indexiertem Feld — Name, Artikelnummer, Beschreibungen, Kategorie, Tags, Attribute, Eigenschaften. Wenn eine Suche nach "red dress" einen roten Werkzeugkasten ausgibt, erhöhen Sie die Gewichtung des Produktnamens und senken Sie die Gewichtung der ausführlichen Beschreibung, damit ein Treffer im Namen deutlich stärker zählt als eine beiläufige Erwähnung in einer Beschreibung.

Wie finde ich heraus, welche Suchanfragen nichts liefern?

Die native Suche protokolliert Null-Treffer-Anfragen nicht auf brauchbare Weise, und genau deshalb verschwindet unerfüllte Nachfrage lautlos. Dieses Signal zu erfassen — also ein Protokoll von Suchen ohne Ergebnis, aus dem jede Anfrage zu einem aufzunehmenden Produkt, einem fehlenden Synonym oder einer zu korrigierenden Beschreibung wird — ist eine der vier Grenzen, die eine dedizierte Suchschicht wie MPR Search Revolution beseitigt. Diese Nachfragedaten erhalten Sie mit der nativen Suche allein nicht.

Was ist der Unterschied zwischen Suchfeld und Facettensuche?

Sie erfüllen unterschiedliche Aufgaben. Das Suchfeld beantwortet eine getippte Anfrage und wird von der Core-Klasse Search angetrieben (dieser Artikel). Die Facettensuche (ps_facetedsearch) ist die Filter-Seitenleiste links auf Kategorieseiten — Preis, Marke, Farbe, Größe — für jemanden, der bereits in einer Kategorie stöbert. In der Regel brauchen Sie beides; wenn Ihr eigentliches Problem das Aussortieren in einer großen Kategorie nach dem Einstieg ist, gehört das zum Thema Filter, nicht zu diesem Artikel.

Weiterführende Lektüre

• Kunden helfen, Produkte in großen Katalogen zu finden — Facettenfilter, die andere Hälfte der Findability im Shop.
• PrestaShop-Kategoriestruktur für SEO-optimierte Navigation — damit Menschen Produkte finden, ohne überhaupt zu tippen.
• PrestaShop-Mega-Menü: Navigation, die konvertiert — ein klares Menü entlastet das Suchfeld.