Das richtige PrestaShop-Theme für Ihr Unternehmen wählen

Die Wahl eines PrestaShop-Themes wirkt täuschend einfach — einen Marketplace durchstöbern, etwas Ansprechendes auswählen, installieren. Zwei Wochen später kämpft man mit kaputten Modul-Layouts, einem PageSpeed-Score in den 30ern und einem Support-Ticket, auf das niemand mehr antwortet. So vermeidet man das.

Erstmal wissen, womit man es zu tun hat

PrestaShop 8 und 9 liefern zwei Themes von Haus aus mit: Hummingbird und Classic.

Classic ist der alte Standard — Bootstrap 3, jQuery-lastig, seit PS 1.7 im Einsatz. Es funktioniert, ist stabil, und praktisch jedes Modul der Welt wurde damit getestet. Die meisten bezahlten Marketplace-Themes sind Forks von Classic. Das sollte man im Hinterkopf behalten.

Hummingbird ist das moderne — Bootstrap 5, saubereres Markup, deutlich bessere Performance aus dem Stand. Es wird aktiv von PrestaShop weiterentwickelt. Wer heute einen neuen Shop startet, ist mit Hummingbird als Grundlage richtig.

Das Problem: Die Mehrheit der kommerziellen Themes auf ThemeForest, PrestaShop Addons oder anderen Marketplaces basiert immer noch auf Classic. Sie sehen auf Screenshots poliert aus, schleppen aber jahrelange technische Schulden mit sich.

Kompatibilität prüfen, bevor man irgendwas kauft

Das ist Schritt eins, nicht Schritt drei. Bevor man einen Euro für ein Theme ausgibt, folgendes verifizieren:

• Welche PrestaShop-Version unterstützt wird — konkret die eigene Version
• Wann das letzte Update war — älter als 6 Monate ist ein gelbes Flag, älter als ein Jahr ein rotes
• Ob der Entwickler auf Support-Anfragen reagiert (Bewertungen lesen, nicht nur die Sternanzahl)
• Ob es auf PHP 8.1+ getestet wurde (Pflicht für PS 8/9)

Ein Theme, das „kompatibel mit PrestaShop 1.7" angibt, lässt sich technisch gesehen auf PS 8 installieren — aber man wird wahrscheinlich auf veraltete Funktionswarnungen, defekte Hooks oder Layout-Probleme mit neueren Core-Modulen stoßen. „Kompatibel" ist ein dehnbarer Begriff — man sollte ins Changelog schauen.

Performance schlägt Optik

Das Theme ist der mit Abstand größte Einflussfaktor auf den PageSpeed-Score eines Shops — mehr als das Hosting, mehr als die Bilder, mehr als fast alles andere. Ein aufgeblähtes Theme fühlt sich nicht nur langsam an. Es kostet direkt Rankings und Conversions.

Was die Performance von Themes ruiniert:

• 400 KB+ CSS laden mit Spezifitätskonflikten und doppelten Regeln
• 15 JavaScript-Dateien bündeln, die auf jeder Seite laden
• Einen vollständigen Icon-Font einbinden (FontAwesome 6 ≈ 400 KB), obwohl man 12 Icons nutzt
• Bilder per JS-Bibliothek lazy-loaden statt nativem loading="lazy"
• Massive Hero-Slider, die auf der Startseite 5 vollauflösende Bilder laden

Vor dem Kauf eines Themes die Demo-URL durch PageSpeed Insights jagen. Nicht die Startseite — die Kategorieseite. Liegt der Mobile-Score unter 60, lieber Abstand halten. Liegt er unter 40, sofort wegklicken.

Wer ernsthaften Geschwindigkeitsgewinn unabhängig vom Theme braucht: Performance Revolution kümmert sich um Caching, Asset-Optimierung und Core Web Vitals auf Modulebene — aber ein aufgeblähtes Theme begrenzt den Spielraum.

Child-Themes — keine Verhandlungssache

Wenn es eine Regel gibt, die erfahrene Entwickler von unerfahrenen unterscheidet, dann diese: Das Parent-Theme niemals direkt bearbeiten.

Wenn der Theme-Autor ein Update veröffentlicht — und das wird früher oder später passieren — sind alle eigenen Änderungen weg. CSS-Overrides, Template-Anpassungen, individuelle Layout-Modifikationen: alles futsch. Wer nicht aktualisiert, häuft Sicherheits- und Kompatibilitätsschulden an.

Immer ein Child-Theme erstellen. Ein Child-Theme erbt alles vom Parent und überschreibt nur, was man explizit ändert. Updates am Parent fließen durch, ohne die eigenen Anpassungen zu berühren.

Bevor man sich für ein Theme entscheidet, prüfen, ob es Child-Themes ordentlich unterstützt. Hummingbird macht das gut. Manche kommerziellen Themes erlauben es technisch, machen es aber unnötig kompliziert — ihre Template-Struktur folgt nicht den PrestaShop-Konventionen, weshalb Child-Theme-Overrides nicht sauber kaskadieren.

Für Content-Anpassungen, bei denen man gar keine Templates anfassen muss — individuelle HTML-Blöcke, Aktionsbereiche, Infozonen — ermöglicht HTML Blocks das Einbinden von Custom-Content in Hooks, ohne eine einzige Theme-Datei zu bearbeiten.

Modul-Kompatibilität wird unterschätzt

Themes und Module interagieren ständig. Ein Theme kann Modul-Templates überschreiben, Hook-Output verändern oder CSS einschleusen, das mit Modul-Styles kollidiert. Die meisten Käufer denken erst daran, wenn etwas kaputt ist.

Diese Fragen vor der Theme-Wahl stellen:

• Überschreibt es Standard-Modul-Templates? (Den /modules/-Ordner im Theme prüfen — wenn er voll ist, Vorsicht)
• Wird es mit eigenen Versionen gängiger Module wie Slidern, Mega-Menüs oder Produkt-Karussells geliefert?
• Ersetzt es native PrestaShop-Funktionalität durch theme-spezifische Features, die einen einschließen?

Themes, die ihr eigenes Mega-Menü, ihr eigenes Produkt-Tab-System, ihre eigene Layer-Navigation mitbringen — das sind Fallen. Man wird abhängig vom Theme-Autor für Funktionalität, die von eigenständigen, wartbaren Modulen übernommen werden sollte. Wenn das Theme veraltet, veraltet auch die Navigation.

Wer ein vernünftiges Mega-Menü braucht, sollte ein eigenständiges Mega Menu-Modul verwenden, das unabhängig vom Theme funktioniert. Gleiches gilt für Banner — Banner Revolution verwaltet Aktionsbanner über das Back-Office, ohne ein einziges Theme-Template anzufassen.

Auf echten Geräten testen, nicht am Browser-Resize

Jedes Theme behauptet, responsiv zu sein. Jedes Theme sieht gut aus, wenn man das Browserfenster schmaler zieht. Das sagt fast nichts.

Auf einem echten Android-Smartphone und einem echten iPhone testen. Konkret:

• Produktlistenseiten — klappen die Filter sauber ein? Ist das Raster lesbar?
• Produktdetailseiten — lassen sich Bilder swipen? Ist der „In den Warenkorb"-Button above the fold?
• Checkout — funktioniert das Formular mit mobilen Tastaturen? Sind die Felder groß genug zum Antippen?
• Navigation — öffnet und schließt das mobile Menü ohne Layout-Verschiebungen?

Touch-Targets, Schriftgrößen, Tap-Genauigkeit — das zeigt sich nur auf echter Hardware. Ein Checkout, der auf dem Handy nervt, kostet Verkäufe. So direkt ist das.

Theme-Editoren: praktisch, aber aufpassen beim Bloat

Viele kommerzielle Themes beinhalten einen visuellen Theme-Editor — iqitthemeeditor (Flavor) ist der am häufigsten anzutreffende. Diese Tools ermöglichen es Händlern, Farben, Fonts und Layout-Einstellungen im Back-Office zu ändern, ohne Code anzufassen.

Sie sind wirklich nützlich. Aber auch ein Performance-Risiko.

Theme-Editoren funktionieren, indem sie die eigenen Einstellungen zur Laufzeit in CSS kompilieren. Die generierten CSS-Dateien sind tendenziell groß, redundant und schwer zu optimieren, weil sie maschinengeneriert sind. Jedes Mal, wenn ein Händler eine Farbe anpasst, wird eine neue Datei kompiliert. Der Bloat summiert sich.

Wer einen Theme-Editor verwendet: das generierte CSS regelmäßig auditieren. Nach doppelten Property-Deklarationen schauen, nach ungenutzten Regelsets für nicht aktivierte Features und nach Variablen, die definiert, aber in der eigenen Konfiguration nie verwendet werden. Das summiert sich schneller, als man denkt.

Custom Fonts: die richtigen Schlachten wählen

Custom Fonts stärken die Markenidentität. Sie erhöhen aber auch das Gewicht jedes Seitenladevorgangs.

Eine einzelne Google-Font-Familie mit 4 Gewichten (regular, medium, semibold, bold) kann 80–200 KB an blockierenden Ressourcen hinzufügen, je nach Zeichensatzabdeckung. Das verschiebt den Largest Contentful Paint direkt nach hinten.

Die praktischen Regeln:

• Maximal 2 Font-Familien — eine für Überschriften, eine für den Fließtext
• Maximal 2–3 Gewichte pro Familie — Regular und Bold decken 90 % der Fälle ab
• Mit font-display: swap arbeiten, damit Text sofort mit einem Fallback gerendert wird
• Die above-the-fold verwendeten Fonts vorladen
• Variable Fonts in Betracht ziehen — eine Datei, die gesamte Gewichtsspanne

Der System-Font-Stack ist tatsächlich ausgezeichnet und lädt sofort. Wenn die eigene Marke keinen spezifischen Schriftzug erfordert, ist das eine ernstzunehmende Option.

Was gute Theme-Struktur ausmacht

Jenseits der Optik bestimmt die zugrundeliegende HTML-Qualität, wie der Shop in der Suche abschneidet und wie zugänglich er für alle Nutzer ist. Worauf man achten sollte:

• Semantische Überschriftenhierarchie — ein H1 pro Seite, logische H2/H3-Verschachtelung, keine Überschriften rein für Styling
• Sauberes strukturiertes Daten-Markup — Produkt-Schema, Breadcrumb-Schema, Review-Schema eingebaut oder hookbar
• Sauberes Bild-Markup — width- und height-Attribute gesetzt, um Layout-Shifts zu vermeiden, korrekte alt-Attribute
• Minimale render-blockierende Ressourcen — kritisches CSS inlined oder inlinebar, Scripts deferred

Die Überschriftenstruktur lässt sich in 30 Sekunden mit den Browser-DevTools prüfen. Das strukturierte Daten-Markup mit Googles Rich Results Test auf der Demo-URL. Das sind keine optionalen Extras — das sind Signale, auf die Google reagiert.

Red Flags, bei denen man besser Abstand hält

• Theme erfordert die Installation von 10+ Begleit-Modulen, um ordentlich zu funktionieren
• Letztes Update war vor mehr als einem Jahr
• Keine Child-Theme-Unterstützung oder Dokumentation dazu
• Demo-Site lädt langsam (selbst testen, nicht den Screenshots vertrauen)
• Support-Forum voller unbeantworteter Fragen
• Das Theme „beinhaltet" einen Page Builder, der Inhalte in einem proprietären Format speichert

Die praktische Empfehlung

Mit Hummingbird starten. Es wird aktiv vom PrestaShop-Team gepflegt, ist schnell, basiert auf Bootstrap 5 und zeigt, wohin das Ökosystem steuert. Sofort ein Child-Theme erstellen — bevor man eine einzige Zeile Custom-CSS schreibt. Das Child-Theme für alle Anpassungen verwenden.

Funktionalität über Module hinzufügen, nicht über Theme-Features. Custom-Banner? Modul. Mega-Menü? Modul. Individuelle Content-Zonen? Modul. Das hält das Theme schlank und den Shop wartbar, wenn Themes und Module in unterschiedlichen Zyklen aktualisiert werden.

Ein gut konfiguriertes Hummingbird-Child-Theme mit den richtigen Modulen übertrifft in Bezug auf PageSpeed-Scores und langfristige Wartbarkeit fast jedes schwere kommerzielle Theme. Es ist weniger aufregend als das Stöbern auf einem Marketplace, aber die Entscheidung, über die man sich sechs Monate später freut.

Verwandte Artikel

• Child Themes in PrestaShop: Warum Sie das Parent Theme niemals bearbeiten sollten
• Eigenes CSS und JavaScript in PrestaShop ohne Updates zu gefaehrden
• Was PrestaShop wirklich langsam macht: Datenbank, Module und Hosting