Berichte und Recherche zu Shopify und E-Commerce
Händler tippen „shopify predictive search“ ein und erwarten eine Funktion, die sie selbst formen können, doch die Section-Dateien zeigen: Die eigentliche Grenze steht längst im Code fest, bevor ein Händler überhaupt den Theme-Editor öffnet.
Händler, die „shopify predictive search“ in eine Suchleiste tippen, suchen meist nach einer Einstellung, die Suchergebnisse schlauer oder schneller macht. Der tatsächliche Code erzählt eine andere Geschichte. Dawn packt 14 Einstellungen in eine Datei und lässt Händler die Darstellung der Ergebnisse sehr detailliert formen. Horizon packt null Einstellungen in die beiden Dateien, die das Sucherlebnis selbst abbilden, und verschiebt jeden verstellbaren Regler in einen separaten Block. Keines der beiden Themes lässt Händler die Suchlogik über den Editor verändern. Die vorhandenen Einstellungen regeln, wie Ergebnisse aussehen, nicht welche Ergebnisse erscheinen – und wer diesen Unterschied kennt, bevor er den Theme-Editor öffnet, spart sich viel Herumklicken auf der Suche nach etwas, das dort nie existiert hat.
Dawns sections/main-search.liquid, intern benannt als t:sections.main-search.name, enthält 14 Einstellungen, wie im Repository Shopify/dawn beim Commit 258f00f vom 2026-08-10 erfasst. Die Range-Einstellung columns_desktop läuft von 1 bis 6 in Schritten von 1 und gibt feine Kontrolle darüber, wie viele Ergebnisse auf breiteren Bildschirmen in einer Reihe stehen. columns_mobile ist ein Select mit nur 2 Varianten, die Layoutwahl auf Mobile ist also binär statt ein Spektrum. image_ratio ist ein Select mit 3 Varianten, und image_shape geht mit 8 Varianten weiter und deckt etwa ab, wie Produkt-Thumbnails beschnitten und gerahmt werden. Zwei Checkboxen runden die nennenswerten Einstellungen ab: show_secondary_image und show_vendor, beide einfache Ein-Aus-Schalter.
Keine dieser 14 Einstellungen berührt den Suchalgorithmus. Sie regeln ausschließlich die Darstellung, was dem entspricht, was eine Section-Datei in Shopifys Theme-Architektur leisten soll. Wer ein anderes Ergebnis-Ranking oder ein anderes Fuzzy-Matching-Verhalten will, findet es hier nicht, denn diese Logik liegt vollständig außerhalb des Settings-Schemas der Section.
Der Vergleich wird bei Horizon noch deutlicher. Dessen sections/predictive-search.liquid, benannt als t:names.predictive_search, hat 0 Einstellungen, bestätigt beim Commit 8b42ace vom 2026-08-31. Diese Section deklariert zwar 1 Block-Typ, aber ihr eigenes Settings-Schema ist leer. Die dazugehörige Datei sections/predictive-search-empty.liquid, benannt als t:names.predictive_search_empty und zuständig für die Anzeige, wenn eine Suche nichts zurückgibt, hat beim gleichen Commit ebenfalls 0 Einstellungen.
Das ist keine Lücke in der Messung. So ist das Theme gebaut. Horizon verlagert die konfigurierbare Oberfläche in blocks/_search-input.liquid, benannt als t:names.search_input, mit 8 Einstellungen. Darunter: width, ein Select mit 2 Varianten; custom_width, eine Range von 0 bis 100 in Schritten von 1 Prozent; input_style, ein Select mit 2 Varianten; und drei Farbeinstellungen für input_background_color, input_text_color und input_border_color. Wer in Horizon das Erscheinungsbild der Suche bearbeitet, muss also den Block finden, nicht die Section, denn die Section selbst bietet nichts zum Anpassen.
| Theme | Datei | Anzahl Einstellungen | Nennenswerte Einstellungen |
|---|---|---|---|
| Dawn | sections/main-search.liquid | 14 | columns_desktop (Range 1–6), image_shape (Select, 8 Varianten), show_vendor (Checkbox) |
| Horizon | sections/predictive-search.liquid | 0 | keine; 1 Block-Typ deklariert |
| Horizon | sections/predictive-search-empty.liquid | 0 | keine |
| Horizon | blocks/_search-input.liquid | 8 | custom_width (Range 0–100%), input_background_color, input_border_color |
Die Methode ist schlicht: das Settings-Schema am Anfang jeder Liquid-Datei lesen, die Einträge zählen und Typ sowie Range notieren, wo das Schema eine angibt. Dasselbe Repository, dieselbe Commit-Referenz pro Theme, keine Interpretation über das hinaus, was das Schema selbst aussagt.
Im breiteren Markt, den themescout.co verfolgt, stehen 329 Themes im Ranking, geprüft am 2026-09-04, mit einem Medianpreis von $300 und einer Spanne von $100 bis $500. Die durchschnittliche Bewertung über 308 Themes mit ausreichend Reviews liegt bei 4.53 von 5, und die mediane Anzahl an Reviews pro Theme beträgt 23. Nichts davon sagt einem Händler etwas über die Einstellungen einer bestimmten Section, aber es zeigt, wie viel Auswahl der Markt bietet, bevor man auf Dawn oder Horizon eingrenzt.
Performance ist das andere Kontextstück, das einmal genannt werden sollte. Auf Mobile liegt der Median-Anteil der Stores, die alle Core Web Vitals bestehen, bei 85.5% über 247 Themes mit ausreichender Datenbasis, das beste Theme im Markt bei 98.6% und das schlechteste bei 46.1%. Auf Desktop liegt der Median bei 86.2% über 199 Themes, mit einem Bestwert von 99.2% und einem schlechtesten Wert von 30.3%. Das stammt aus CrUX-Daten für Juli 2026, also aus echtem Besucherverkehr und nicht aus einem Labor-Benchmark. Eine schwerere Search-Section mit mehr Markup könnte ein Theme plausibel ans untere Ende dieser Spanne drücken, auch wenn die Fakten hier Search-Sections nicht als konkrete Ursache isolieren.
Prüfe die tatsächlichen Section- und Block-Dateien des infrage kommenden Themes, statt anzunehmen, die Predictive-Search-Einstellungen sähen aus wie in Dawn, nur weil Dawn das Referenz-Theme ist, auf das sich die meisten Guides stützen. Zeigt die Search-Section eines Themes null Einstellungen, so wie es bei Horizon der Fall ist, dann suche nach einem zugehörigen Block, bevor du schlussfolgerst, die Funktion fehle vollständig.
Ja, über columns_desktop, eine Range-Einstellung von 1 bis 6 in Schritten von 1 innerhalb von sections/main-search.liquid. Es gibt eine separate Einstellung columns_mobile, aber sie ist ein Select mit nur 2 Varianten statt einer Range, die Layoutwahl auf Mobile ist also enger als auf Desktop. Beide Einstellungen liegen in derselben Datei, Shopify/dawn beim Commit 258f00f, datiert auf 2026-08-10. Keine der beiden Einstellungen berührt, welche Produkte der Suchalgorithmus ausspielt, sondern nur, wie die zurückgegebenen Ergebnisse angeordnet werden.
Ja. show_secondary_image ist eine Checkbox-Einstellung in sections/main-search.liquid und eine der 14 Einstellungen, die in dieser Datei zum Commit 258f00f vom 2026-08-10 erfasst sind. In derselben Section gibt es außerdem eine Checkbox show_vendor, sodass Herstellername und zweites Bild unabhängig voneinander umgeschaltet werden können. Keine der beiden Einstellungen ändert, welche Daten die Suchanfrage zurückgibt, sondern nur, was das Theme daraus rendert.
Weil Horizons sections/predictive-search.liquid 0 Einstellungen hat und sections/predictive-search-empty.liquid ebenfalls 0 Einstellungen, beides bestätigt beim Commit 8b42ace vom 2026-08-31. Horizon verlagert den anpassbaren Teil in einen Block statt in die Section: blocks/_search-input.liquid enthält 8 Einstellungen, darunter width, custom_width als Range von 0 bis 100 in Schritten von 1 Prozent sowie drei Farbeinstellungen für Hintergrund, Text und Rahmen. Das Fehlen in den Section-Dateien ist also real und gemessen, keine Lücke in der Berichterstattung, und wer in Horizon das Erscheinungsbild der Suche bearbeiten will, muss den Block ansehen, nicht die Section.
Die Fakten hier isolieren Search-Sections nicht gezielt, sie zeigen aber die Bandbreite, in der die gesamte Core-Web-Vitals-Performance eines Themes liegen kann. Auf Mobile liegt der Median über 247 Themes mit ausreichender Datenbasis bei 85.5% der Stores, die alle Core Web Vitals bestehen, mit einer Spanne von 46.1% bis 98.6%. Auf Desktop liegt der Median über 199 Themes bei 86.2%, mit einer Spanne von 30.3% bis 99.2%. Diese Zahlen stammen aus CrUX-Daten zu echten Besuchern im Juli 2026, nicht aus einem Labortest. Eine schwerere Search-Section ist also einer von vielen plausiblen Faktoren dafür, wo ein bestimmtes Theme in dieser Bandbreite landet.
Rein nach Anzahl der Einstellungen: ja. Dawns sections/main-search.liquid hat 14 Einstellungen in einer Datei. Horizon verteilt dieselbe Funktion über drei Dateien, zwei davon mit jeweils 0 Einstellungen und ein Block, blocks/_search-input.liquid, mit 8 Einstellungen. Zusammengerechnet umfasst Horizons suchbezogene Oberfläche 8 Einstellungen im Block plus null aus den beiden Sections, gegenüber Dawns 14 in einer einzigen Section. Die Architektur unterscheidet sich stärker als die reine Konfigurierbarkeit.