Welche Plugins ein JTL-Shop wirklich braucht – und wo man sich verzettelt

Ein frisch aufgesetzter JTL-Shop kann viel, aber nicht alles. Spätestens nach ein paar Monaten steht die Frage im Raum: Welche Erweiterungen braucht der Shop wirklich – und welche kauft man nur, weil sie im Store gut aussehen? Dieser Beitrag ist eine Entscheidungshilfe aus der Praxis: in welcher Reihenfolge sich Erweiterungen lohnen, was der Shop ohne jedes Plugin schon mitbringt, welche Fragen man vor dem Kauf stellt, was eine Erweiterung über drei Jahre tatsächlich kostet – und wie man wieder ausmistet, ohne Daten zu verlieren.

Erst die Pflicht, dann die Kür

Die nützlichste Reihenfolge ist nicht die spannendste. Was ein Shop zuerst braucht, ist das, dessen Fehlen ihn Geld oder Rechtsfrieden kostet:

1. Pflichten, die aus dem Sortiment folgen. Altersprüfung bei altersbeschränkter Ware, Pflichtangaben wie Grundpreis und CLP, Rechtstexte, die aktuell bleiben. Das ist kein Komfort, sondern die Voraussetzung dafür, dass der Shop überhaupt betrieben werden darf.
2. Zahlung und Versand. Jede fehlende Zahlart ist ein messbarer Abbruch. Hier zuerst nachzurüsten zahlt sich schneller aus als jede Gestaltungsidee.
3. Sichtbarkeit. SEO-Grundlagen, saubere Weiterleitungen, Strukturdaten. Wirkt langsam, aber dauerhaft.
4. Conversion und Gestaltung. Countdowns, Vertrauenselemente, Template-Anpassungen. Richtig eingesetzt sehr wirksam – aber erst, wenn Besucher da sind, auf die sie wirken können.
5. Betrieb. Backup, Spamschutz, Überwachung der Cron-Jobs. Fällt niemandem auf, bis es fehlt.

Wer diese Reihenfolge umdreht und mit Punkt 4 anfängt, hat am Ende einen hübschen Shop mit wenig Besuchern und einem offenen Rechtsrisiko. Das ist der häufigste Fehler, den ich sehe – und er ist nachvollziehbar: Ein Countdown ist am Tag der Installation sichtbar, saubere Weiterleitungen sind es nie.

Was JTL-Shop ohne jede Erweiterung schon kann

Bevor Sie etwas kaufen, lohnt der Blick auf das, was ab Werk da ist. Der häufigste vermeidbare Kauf ist der für eine Funktion, die der Shop längst hat – sie steht nur an einer Stelle, die man nicht vermutet.

• SEO-Grundlagen: sprechende URLs, Meta-Felder je Artikel, Kategorie und Seite, XML-Sitemap, Canonical-Tags, robots.txt. Das reicht für kleine Sortimente vollständig aus.
• Weiterleitungen: eine eigene Verwaltung im Backend. Sie legt beim Ändern einer URL automatisch eine 301 an.
• Rechtstexte und Pflichtangaben: Vorlagen für AGB, Widerruf, Datenschutz und Impressum, Grundpreisangabe, Versandkostenhinweise.
• Consent-Manager: JTL-Shop bringt seit Version 5 einen eigenen mit. Ein zweites Consent-Plugin ist fast immer ein Fehler, weil sich beide gegenseitig blockieren.
• OnPage Composer: Startseite und Inhaltsseiten lassen sich ohne Template-Eingriff gestalten. Vieles, wofür Händler einen „Seitenbaukasten“ kaufen, geht hier schon.
• Kundengruppen, Staffelpreise, Kupons, Bewertungen, Newsletter-Grundfunktion.

Was der Shop nicht mitbringt, ist alles, was über viele Datensätze hinweg arbeitet oder externe Dienste anbindet: Lücken in Meta-Angaben über tausende Artikel finden, Search-Console-Daten auswerten, Altersprüfung, Tracking mit Einwilligungssteuerung, Backups. Genau dort beginnt der sinnvolle Zukauf.

Fünf Fragen vor jedem Kauf

Der Preis eines Plugins ist selten das Problem. Teuer wird, was danach kommt. Diese fünf Fragen filtern erfahrungsgemäß das meiste heraus:

• Für welche Shop-Versionen ist es freigegeben – und für welche PHP-Versionen? Ein Plugin, das nur bis JTL-Shop 5.5 reicht, blockiert Ihr nächstes Shop-Update. Fragen Sie konkret nach, bis wann der Anbieter nachzieht, und lassen Sie sich die Antwort schriftlich geben.
• Greift es ins Template ein? Erweiterungen, die Template-Dateien überschreiben, überleben Shop-Updates oft nicht. Besser sind Lösungen, die über Hooks und eigene Blöcke arbeiten und das Template unangetastet lassen. Fragen Sie: „Muss ich nach einem Shop-Update etwas von Hand nachziehen?“
• Was passiert bei der Deinstallation? Der Plugin-Manager fragt beim Deinstallieren nach, ob die Daten des Plugins entfernt werden sollen und ob auch seine Datenbanktabellen gelöscht werden. Wer hier bestätigt, verliert alles, was nur dort lag – Freigaben, Punktestände, Protokolle. Fragen Sie den Anbieter vorher, welche Daten in diesen Tabellen stehen und ob er einen Export anbietet: Das entscheidet, ob Sie die Rückfrage später mit „ja“ oder mit „nein“ beantworten.
• Lädt es Skripte von fremden Servern? Dann brauchen Sie dafür eine Einwilligung und einen Eintrag im Consent-Manager – und die Seite wird langsamer. Fragen Sie vor dem Kauf, welche externen Abrufe das Plugin auslöst und ob es sich in den Consent-Manager des Shops einträgt.
• Gibt es eine Dokumentation, die Sie vor dem Kauf lesen können? Wenn nicht, ist das eine Antwort für sich.

Ein Hinweis, der schon einige Stunden gespart hat: Wenn Sie eine Erweiterung nur vorübergehend loswerden wollen – zur Fehlersuche oder während einer Migration –, deaktivieren Sie sie, statt sie zu deinstallieren. Deaktivierte Plugins werden nicht mehr ausgeführt, ihre Einstellungen und Tabellen bleiben unangetastet, und Sie müssen sich gar nicht erst entscheiden.

Was eine Erweiterung über drei Jahre wirklich kostet

Im Store steht ein Preis. In der Buchhaltung steht am Ende eine andere Zahl. Rechnen Sie bei jeder Erweiterung diese fünf Posten zusammen, bevor Sie zusagen:

Posten	Worauf zu achten ist
Lizenz	Einmalkauf oder Abo? Bei Einmalkauf: Wie lange sind Updates enthalten, und was kostet die Verlängerung?
Einrichtung	Eine Stunde oder ein Tag? Bei allem, was in den Bestellprozess eingreift, kalkulieren Sie Testbestellungen mit ein.
Laufende Kosten je Vorgang	Prüfungen gegen externe Dienste, SMS, API-Abrufe. Bei Altersprüfungen oder Bonitätsabfragen ist das der größte Posten – und er wächst mit dem Umsatz.
Pflege bei Shop-Updates	Je Shop-Update einmal testen. Bei zwei bis drei Updates im Jahr und zehn Plugins ist das ein ganzer Arbeitstag pro Jahr, den niemand einplant.
Ausstiegskosten	Datenexport, Umstellung, Umgewöhnung. Je mehr Daten eine Erweiterung ansammelt, desto teurer wird der Ausstieg – rechnen Sie ihn mit, bevor Sie einsteigen.

Die Faustregel aus der Betreuung: Der Kaufpreis ist über drei Jahre selten mehr als ein Drittel der Gesamtkosten. Das verschiebt den Vergleich zwischen zwei Angeboten deutlich – die günstigere Lizenz mit schlechter Dokumentation ist regelmäßig die teurere Entscheidung.

Warum die Anzahl selbst zählt

Jedes Plugin bringt eigene Einstellungen, einen eigenen Update-Rhythmus und eine eigene Vorstellung davon, wie die Oberfläche auszusehen hat. Bei drei Erweiterungen merkt man das kaum. Bei fünfzehn ergeben sich Effekte, die keiner einzelnen Erweiterung anzulasten sind:

• Nach einem Shop-Update ist nicht ein Plugin zu prüfen, sondern fünfzehn – und das langsamste bestimmt, wann Sie aktualisieren können.
• Jedes Plugin lädt eigene CSS- und JavaScript-Dateien. Die Summe davon ist der häufigste Grund für schlechte Core-Web-Vitals-Werte in gewachsenen Shops.
• Niemand weiß nach einem Jahr noch, welche Einstellung in welcher Oberfläche steht.

Daraus folgt keine Regel wie „möglichst wenige Plugins“. Es folgt daraus: Für jede Erweiterung sollte benennbar sein, welche Frage sie beantwortet. Was sich nicht benennen lässt, fliegt raus – und zwar bevor es Daten angesammelt hat.

Vier Konflikte, die man erst im Betrieb sieht

Zwei Erweiterungen können einzeln fehlerfrei arbeiten und sich trotzdem im Weg stehen. Diese vier Muster begegnen mir am häufigsten – und keines davon erzeugt eine Fehlermeldung:

1. Doppelte Strukturdaten. Zwei Erweiterungen schreiben Produkt-Auszeichnungen in dieselbe Seite, eine als JSON-LD, eine als Microdata. Google sieht widersprüchliche Preise oder Verfügbarkeiten und zeigt im Zweifel gar kein Rich Result. Zu erkennen im Rich-Results-Test: Steht ein Product zweimal mit unterschiedlichen Werten da, haben Sie den Fall.
2. Zwei Consent-Lösungen. Die eine blockiert Skripte, die die andere freigeben will. Typisches Bild: Nach „Alle akzeptieren“ lädt das Tracking trotzdem nicht – oder umgekehrt lädt es schon vor der Einwilligung. Beides ist ein echtes Problem, das zweite auch rechtlich.
3. Konkurrierende Template-Überschreibungen. Zwei Erweiterungen überschreiben dieselbe Smarty-Datei. Die zuletzt geladene gewinnt, die andere Funktion verschwindet stillschweigend. Sichtbar wird das meist erst nach einem Update, wenn sich die Ladereihenfolge ändert.
4. Cron-Jobs, die niemand ansieht. Mehrere Erweiterungen legen eigene geplante Aufgaben an. Bleibt eine davon hängen, läuft die Warteschlange des Shops nicht weiter – und plötzlich werden auch Bestellbestätigungen nicht mehr versendet. Der Zusammenhang ist beim Suchen alles andere als offensichtlich.

Gegen alle vier hilft dieselbe Gewohnheit: nach jeder Installation einmal eine Testbestellung durchführen, den Quelltext einer Artikelseite ansehen und die Cron-Übersicht prüfen. Fünf Minuten, die den Nachmittag retten, an dem es jemand auffällt.

Vor dem Shop-Update: eine Prüfliste

JTL pflegt mehrere Versionslinien parallel – im September 2026 sind 5.6.4, 5.7.4 und 5.8.1 am selben Tag erschienen. Sie müssen also nicht sofort auf die neueste Linie springen; ein Sicherheits- und Fehlerbehebungsstand für Ihre Linie reicht oft. Was vor jedem Update steht:

• Liste aller installierten Erweiterungen mit Version und Freigabestand des Anbieters
• Backup von Datenbank und Dateien – und einmal geprüft, ob es sich wirklich einspielen lässt
• Update auf einer Kopie des Shops, nie direkt im Live-Betrieb
• Danach durchtesten: eine Bestellung bis zum Abschluss, die Zahlarten, die Suche, das Kundenkonto
• Cron-Jobs und Fehlerprotokoll in den ersten Tagen im Auge behalten – Probleme zeigen sich selten sofort

Wenn eine Erweiterung ein Update blockiert, ist das eine Information über diese Erweiterung, nicht über den Shop. Zweimal in Folge der gleiche Bremser heißt: ersetzen.

Ausmisten, ohne Daten zu verlieren

Gewachsene Shops tragen fast immer Erweiterungen mit, die niemand mehr nutzt. Entfernen ist richtig – aber in dieser Reihenfolge:

1. Inventur. Jede Erweiterung mit einem Satz beschreiben: Welche Frage beantwortet sie, und woran merken Sie, dass sie wirkt? Was sich nicht beschreiben lässt, kommt auf die Liste.
2. Daten sichern. Bevor irgendetwas angefasst wird: Datenbank-Backup. Zusätzlich das exportieren, was die Erweiterung selbst anbietet – Freigaben, Punktestände, Protokolle.
3. Erst deaktivieren, nicht deinstallieren. Zwei bis vier Wochen laufen lassen und beobachten, ob jemand etwas vermisst. Einstellungen und Tabellen bleiben in dieser Zeit erhalten.
4. Dann erst deinstallieren – und die Rückfragen nach Daten und Tabellen bewusst beantworten, nicht wegklicken. Behalten Sie die Tabellen im Zweifel: Sie lassen sich später immer noch löschen, zurückholen lassen sie sich nicht. Bei Altersfreigaben aus einem Vorgänger-Plugin gilt ohnehin: übernehmen, bevor deinstalliert wird, nicht danach.
5. Aufräumen, was zurückbleibt. Verwaiste Cron-Jobs, Consent-Dienste ohne Gegenstück, CSS-Reste im Child-Template.

Eine Erweiterung pro Woche, nicht fünf an einem Abend. Wenn danach etwas nicht stimmt, wollen Sie wissen, welche es war.

Einzelne Plugins oder eine Suite?

Beides hat ernsthafte Argumente, und die Entscheidung hängt weniger am Funktionsumfang als an der Frage, wer den Shop betreut.

Einzelne Plugins	Eine Suite
Für jede Aufgabe lässt sich der beste Anbieter wählen	Eine Oberfläche, ein Update, ein Ansprechpartner
Ein Ausfall betrifft nur eine Funktion	Funktionen kennen einander – keine doppelten Strukturdaten, keine widersprüchlichen Einstellungen
Wechsel einzeln möglich	Abhängigkeit von einem Anbieter; bei dessen Ausfall steht mehr still
Summe der Lizenzen oft höher	Was man nicht nutzt, zahlt man trotzdem mit
Fehlersuche ist einfach: ein Plugin, ein Verantwortlicher	Fehlersuche ist einfacher: weniger Beteiligte, die aufeinander zeigen

Mein Eindruck aus der Betreuung: Shops mit eigener IT fahren mit einzelnen, austauschbaren Erweiterungen gut. Händler, die den Shop nebenbei betreiben, verlieren dort Zeit – für sie ist weniger Oberfläche mehr wert als die theoretisch bessere Einzellösung. Ein Mittelweg funktioniert ebenfalls: eine Suite für die Masse der kleinen Aufgaben, Spezialisten für die zwei, drei Punkte, an denen der Shop sein Geld verdient.

Was KI daran ändert – und was nicht

Seit es Schnittstellen gibt, über die ein KI-Assistent einen Shop direkt lesen kann, verschiebt sich eine Sache spürbar: die Analyse. Fragen wie „welche Artikel haben keine Meta-Description“, „wo kannibalisieren sich zwei Seiten“ oder „welcher Cron-Job läuft nicht mehr“ beantwortet ein Assistent in Minuten, wenn er Zugriff auf die Shopdaten hat. Was früher eine Tabellenkalkulation und einen Nachmittag gekostet hat, ist heute eine Frage.

Was sich nicht verschiebt, ist die Verantwortung. Ein Vorschlag ist ein Vorschlag. Jede Lösung, die eine KI direkt in den Live-Shop schreiben lässt, ist aus meiner Sicht falsch gebaut – nicht weil die Texte schlecht wären, sondern weil niemand einen Fehler bemerkt, bevor ein Kunde ihn sieht. Achten Sie darauf, dass Änderungen als Entwurf entstehen und ein Mensch sie freigibt. Und prüfen Sie, welche Daten die Schnittstelle überhaupt herausgibt: Kundendaten haben in einem Analysewerkzeug nichts verloren.

Offenlegung

Ich entwickle selbst eine Erweiterung für JTL-Shop, die Shop-Suite PRO – entstanden aus genau dem Problem, das oben beschrieben ist: In meinem eigenen Shop liefen zu viele Einzellösungen nebeneinander. Das macht diesen Beitrag nicht neutral, und Sie sollten ihn entsprechend lesen. Die fünf Fragen oben gelten trotzdem – stellen Sie sie auch mir.

Häufige Fragen

Wie viele Plugins verträgt ein JTL-Shop?

Eine feste Zahl gibt es nicht. Entscheidend ist, wie viele davon Skripte und Stile ins Frontend laden und wie viele ins Template eingreifen. Zehn zurückhaltende Erweiterungen sind unproblematischer als drei, die jede Seite mit eigenen Dateien beladen.

Was passiert beim Deinstallieren mit meinen Daten?

Das entscheiden Sie selbst: Der Plugin-Manager fragt beim Deinstallieren, ob die Daten des Plugins gelöscht werden sollen und ob auch seine Datenbanktabellen entfernt werden. Bestätigen Sie beides, ist alles weg, was nur dort lag. Antworten Sie mit „nein“, bleiben die Tabellen in der Datenbank stehen – als Altlast, aber eben auch als Rettungsanker. Wer nur vorübergehend abschalten will, deaktiviert stattdessen; dabei bleiben Einstellungen und Tabellen in jedem Fall erhalten.

Woran erkenne ich, ob ein Plugin mein Shop-Update blockiert?

An der Freigabeangabe des Anbieters für die Ziel-Shopversion und die PHP-Version. Fehlt sie oder endet sie bei einer älteren Version, testen Sie das Update zuerst auf einer Kopie des Shops – nie direkt im Live-Betrieb.

Brauche ich ein SEO-Plugin für JTL-Shop?

JTL-Shop bringt Grundlagen wie URLs, Meta-Felder und Sitemap mit. Eine Erweiterung lohnt sich dort, wo es um Fleißarbeit über viele Seiten geht: fehlende und doppelte Angaben finden, Weiterleitungen aufräumen, Strukturdaten ergänzen. Für zwanzig Artikel macht man das von Hand, für zweitausend nicht.

Kann ich zwei Plugins für dieselbe Aufgabe parallel betreiben?

Technisch oft ja, sinnvoll fast nie. Bei Consent-Managern, Strukturdaten und Tracking führt der Parallelbetrieb regelmäßig zu widersprüchlichen Ergebnissen, die keine Fehlermeldung erzeugen. Wenn Sie wechseln: das alte Plugin deaktivieren, das neue einrichten, erst danach deinstallieren.

Was kostet eine Erweiterung wirklich?

Rechnen Sie neben der Lizenz die Einrichtung, laufende Kosten je Vorgang, den Testaufwand bei jedem Shop-Update und die Ausstiegskosten dazu. Über drei Jahre ist der Kaufpreis erfahrungsgemäß selten mehr als ein Drittel der Gesamtsumme.

Muss ich immer auf die neueste JTL-Shop-Version aktualisieren?

Nein. JTL pflegt mehrere Versionslinien parallel und veröffentlicht für ältere Linien weiterhin Korrekturstände. Entscheidend ist, dass Sie Sicherheitsaktualisierungen für Ihre Linie einspielen – der Sprung auf eine neue Hauptversion kann warten, bis Ihre Erweiterungen dafür freigegeben sind.

Wenn Sie vor einer solchen Entscheidung stehen und sie nicht allein treffen wollen: schreiben Sie mir. Welche Shop-Systeme sich wie unterscheiden, steht im Shopsystem-Vergleich; was bei altersbeschränkter Ware technisch dazukommt, im Beitrag Altersprüfung im JTL-Shop einrichten.

Quellen

• JTL-Shop Developer Guide: Allgemeine Informationen zu Plugins – zum Verhalten beim Deaktivieren. Zum Deinstallieren hält der Leitfaden nur fest, dass Einstellungen und Tabellen entfernt werden; die Rückfrage nach Daten und Tabellen stellt der Plugin-Manager im Backend (geprüft in JTL-Shop 5.8)
• JTL-Shop Core, Versions-Tags auf GitLab – parallel gepflegte Versionslinien
• JTL-Guide: JTL-Shop – Funktionsumfang im Auslieferungszustand