JTL Plugin GPSR: Produktsicherheit im Shop rechtskonform umsetzen

Autor: eRock Creations Redaktion · Fokus: JTL Plugin GPSR, Produktsicherheit, JTL-Wawi, Compliance; Stand: 30.04.2026

JTL Plugin GPSR ist eine technische Lösung, mit der Onlinehändler Pflichtangaben nach der EU-Produktsicherheitsverordnung (GPSR) strukturiert auf Produktdetailseiten im JTL-Shop ausgeben können. Die Verordnung verpflichtet seit dem 13. Dezember 2024 alle Händler, sicherheitsrelevante Informationen wie Herstellerangaben, Warn- und Sicherheitshinweise sowie die verantwortliche Person in der EU gut sichtbar im Online-Angebot bereitzustellen.

Die zentrale Herausforderung liegt nicht nur in der rechtlichen Umsetzung, sondern vor allem in der wartbaren, performanten und skalierbaren Datenpflege über das gesamte Sortiment hinweg. Ein JTL GPSR Plugin verbindet die zentrale Datenpflege in JTL-Wawi mit einer flexiblen, UX- und Performance-optimierten Darstellung im Shop – ohne dass tiefgreifende Anpassungen am JTL Template erforderlich sind.

Warum JTL Plugin GPSR für Händler jetzt relevant ist

Die GPSR ist keine theoretische Anforderung, sondern eine rechtlich verpflichtende Verordnung, die seit dem Stichtag durchgesetzt wird. Verstöße können Abmahnungen, Marktüberwachungsmaßnahmen oder Verkaufsverbote nach sich ziehen. Für Händler bedeutet das: Bestimmte Informationen müssen bereits im Online-Angebot vorhanden und gut sichtbar platziert sein – nicht versteckt in Download-Bereichen oder nur in PDFs.

In vielen Shops erfolgt die initiale Umsetzung überstürzt: Texte werden manuell pro Artikel gepflegt, Templates werden notdürftig angepasst, und nach wenigen Wochen zeigt sich, dass das Setup nicht wartbar ist. Besonders bei Sortimenten mit vielen Herstellern oder häufigen Änderungen wird der Pflegeaufwand schnell zum Problem. Ein strukturiertes Setup – bestehend aus sauberer Datenpflege, zuverlässigem Sync und flexibler Darstellung – ist deshalb entscheidend. Damit die Ausgabe stabil läuft, sollten Shopbetreiber von Anfang an auch die JTL Shop Performance Optimierung mitdenken.

Pflichtinhalte auf der Produktdetailseite nach GPSR

Händler müssen folgende Informationen auf jeder Produktdetailseite bereitstellen:

Herstellerangaben: Name/Marke, Anschrift, elektronische Adresse wie E-Mail oder Website
Warnhinweise und Sicherheitsinformationen: produktspezifisch, beispielsweise Nutzungshinweise, Altersfreigaben, Risiken, Schutzmaßnahmen
Verantwortliche Person in der EU: Name/Firma, Anschrift, elektronische Adresse – nur erforderlich, wenn der Hersteller außerhalb der EU sitzt

Die Anforderung „gut sichtbar" bedeutet konkret: Nutzer müssen die Informationen ohne Suche finden können. Eine reine PDF-Lösung im Download-Bereich erfüllt diese Anforderung nicht und genügt den rechtlichen Vorgaben nicht.

Was ein JTL GPSR Plugin leistet und welche Alternativen es gibt

Ein GPSR Plugin für JTL übernimmt die strukturierte Ausgabe der Pflichtdaten im JTL-Shop. Es greift auf die in JTL-Wawi gepflegten Informationen zu und gibt diese auf der Produktdetailseite aus – je nach Konfiguration in Tabs, Akkordeons, Info-Boxen oder anderen Darstellungsformen.

Die zentrale Funktion besteht darin, die Datenquelle (Wawi) und die Darstellung (Shop) sauber zu entkoppeln. Dadurch lassen sich Änderungen zentral pflegen und automatisch auf alle betroffenen Produkte ausspielen. Das reduziert den Wartungsaufwand erheblich und minimiert Fehlerquellen. Der Ansatz verbessert die Datenkonsistenz und erleichtert die Skalierung bei wachsendem Sortiment.

Alternative Umsetzungen ohne Plugin

Wenn ein Update oder die Installation eines Plugins kurzfristig nicht umsetzbar ist, gibt es zwei bewährte Alternativen:

Template-seitige Abfrage von Funktionsattributen: GPSR-Daten werden als Funktionsattribute gepflegt und im Template direkt ausgelesen. Vorteil: schnell umsetzbar. Nachteil: wartungsintensiv bei Template-Updates, erfordert saubere Dokumentation.
Zentral verwaltete Ausgabe über Content-Ansatz: Herstellerinfos werden einmal gepflegt und über Drops, Blöcke oder Template-Logik auf Produktseiten ausgespielt. Vorteil: reduziert Redundanz, schnell implementierbar. Nachteil: weniger strukturiert als Plugin-Lösung.

In der Praxis funktionieren diese Ansätze als Übergangslösung gut – langfristig ist jedoch eine strukturierte Datenpflege in Kombination mit einem Plugin die wartbarste Variante. Sie bietet mehr Flexibilität und erleichtert die langfristige Pflege bei großen Produktkatalogen.

Technische Voraussetzungen und Systemlandschaft

Die Umsetzung basiert auf der Verbindung zwischen JTL-Wawi und JTL-Shop. Folgende technische Rahmenbedingungen müssen erfüllt sein:

JTL-Shop: GPSR-Plugin installiert, verfügbar im JTL Extension Store
JTL-Wawi: Ab Version 1.9.6.0 können GPSR-Informationen über dedizierte Eingabefelder gepflegt werden
Migrationslogik: Bereits gepflegte GPSR-Daten über Funktionsattribute werden in neueren Wawi-Versionen übernommen

Der häufigste Fehler in der Praxis: Nach der Pflege der GPSR-Informationen wird kein Komplettabgleich für Artikel und Hersteller durchgeführt. Ein einfacher Onlineshop-Abgleich reicht nicht aus – die Daten werden dann nicht in den Shop übertragen. Dieser Schritt ist entscheidend für die Datenübernahme.

Typische Troubleshooting-Fälle

Wenn nach der Einrichtung keine GPSR-Informationen im Shop erscheinen, liegt das meist an einem der folgenden Punkte:

Kein Komplettabgleich durchgeführt
Falscher Verkaufskanal in der Wawi aktiviert
Cache nicht geleert: Shop-Cache, Template-Cache, Plugin-Cache müssen bereinigt werden
Template-Override überschreibt die Plugin-Ausgabe

Eine systematische Fehlersuche beginnt immer mit der Prüfung des Komplettabgleichs, gefolgt von der Cache-Kontrolle und der Überprüfung eventueller Template-Anpassungen, die die Plugin-Funktionalität beeinflussen könnten.

Datenmodell aus der Praxis: zentral, wiederverwendbar, skalierbar

Ein funktionierendes GPSR-Setup steht und fällt mit der Datenstruktur. Ziel ist es, Redundanz zu vermeiden und Änderungen zentral zu pflegen. Folgende Datenbereiche müssen abgebildet werden:

Herstellerdaten – zentral und wiederverwendbar

Herstellername, Anschrift, Kontakt wie E-Mail oder Website werden idealerweise einmal pro Hersteller gepflegt und auf alle zugehörigen Artikel ausgespielt. Das spart Zeit und reduziert Fehler. Bei Änderungen an Herstellerinformationen genügt eine zentrale Aktualisierung, die dann automatisch für alle betroffenen Produkte gilt.

Produktspezifische GPSR-Daten

Warnhinweise, Sicherheitsinfos und gegebenenfalls Produkttyp-Logik werden auf Artikelebene gepflegt. Diese Informationen haben eine höhere Priorität als zentrale Herstellerangaben und überschreiben diese bei Bedarf. Produktspezifische Daten sind individuell und können nicht pauschal pro Hersteller festgelegt werden.

EU-Verantwortliche Person

Wenn der Hersteller außerhalb der EU sitzt, muss eine verantwortliche Person in der EU angegeben werden. Diese Daten sollten als eigenständiger Datensatz gepflegt werden, der per Hersteller- oder Import-Logik zugeordnet wird – nicht tausendfach pro Artikel. Eine zentrale Pflege verhindert Inkonsistenzen und erleichtert spätere Anpassungen.

Dokumente und Medien

Anleitungen, Sicherheitsblätter, PDFs und Bilder sollten klar benannt, versioniert und in sinnvoller Dateigröße vorliegen. Große PDF-Dateien beeinträchtigen die Performance und sollten komprimiert oder lazy geladen werden. Eine durchdachte Medien-Verwaltung verbessert die Ladezeiten und die User Experience erheblich.

Datenpflege in JTL-Wawi: Felder versus Funktionsattribute

Ab JTL-Wawi 1.9.6.0 können GPSR-Informationen über dedizierte Eingabefelder gepflegt werden. Das ist der empfohlene Weg, weil er standardisiert, wartbar und zukunftssicher ist. Die nativen Felder sind speziell für die GPSR-Anforderungen konzipiert und erleichtern die strukturierte Datenpflege.

In älteren Wawi-Versionen oder bei spezifischen Connector-Szenarien werden GPSR-Daten über Funktionsattribute gepflegt. Typische Attributnamen aus der Praxis:

gpsr_responsibleperson_homepage
gpsr_responsibleperson_name
gpsr_responsibleperson_email
gpsr_manufacturer_homepage
gpsr_manufacturer_email

Der größte Aufwandstreiber bei Funktionsattributen: Pflege pro Artikel. Bei großen Sortimenten wird das schnell fehleranfällig und teuer. Deshalb sollte, wo möglich, zentral pro Hersteller gepflegt werden. Die zentrale Pflege spart nicht nur Zeit, sondern minimiert auch das Risiko von Inkonsistenzen und Pflegefehlern.

Massenpflege per CSV und JTL-Ameise: Schritt-für-Schritt-Logik

Für große Sortimente ist die manuelle Pflege nicht praktikabel. Stattdessen hat sich die Massenpflege per CSV und JTL-Ameise bewährt. Der Prozess sieht folgendermaßen aus:

Artikelverwaltung öffnen: Filter setzen, beispielsweise nach Hersteller oder Warengruppe, um gezielt Artikel zu bearbeiten
Export als CSV: Tabelleneinstellung exportieren, Artikelnummern als Schlüssel behalten
CSV vorbereiten: Spaltenpaare je Funktionsattribut anlegen – Attributname plus Attributwert
Import mit JTL-Ameise: Mapping prüfen, Attributname und Attributwert korrekt zuordnen, Verkaufskanäle aktivieren, Option „Attribute als Funktionsattribute anlegen" auf Ja setzen
Komplettabgleich durchführen: Artikel plus Hersteller, sonst keine Anzeige im Shop

Dieser Prozess lässt sich pro Attribut oder pro Hersteller durchführen. Je nach Sortiment kann es sinnvoll sein, separate Import-Läufe pro Attribut zu fahren, um die Übersichtlichkeit zu behalten. Wichtig ist, dass alle Schritte dokumentiert und nachvollziehbar sind, um spätere Fehlersuchen zu erleichtern.

Darstellung im JTL-Shop: UX und Performance in Einklang bringen

Die GPSR-Informationen müssen sichtbar sein – aber sie dürfen die Produktseite nicht überladen oder die Conversion beeinträchtigen. In der Praxis haben sich folgende Darstellungsvarianten bewährt:

Tab- oder Akkordeon-Lösung

Kurzer sichtbarer Teaser plus aufklappbare Details für Warn- und Sicherheitshinweise. Vorteil: Inhalte sind sichtbar, aber nicht aufdringlich. Nachteil: erfordert sauberes JavaScript und funktioniert nur, wenn Consent- oder Cookie-Tools nicht blockieren. Diese Darstellungsform ist besonders nutzerfreundlich und hält die Seite übersichtlich.

Sticky Info-Box

Kurze Box im sichtbaren Bereich plus ausführliche Infos darunter. Vorteil: gut sichtbar, einfach umsetzbar. Nachteil: kann bei langen Texten viel Platz einnehmen. Eine Sticky-Box eignet sich besonders für wichtige Hinweise, die dauerhaft präsent bleiben sollen.

Hinweis mit Link-Anker

Kurzer Hinweis im oberen Bereich plus Link zu einem GPSR-Block weiter unten. Vorteil: flexibel, performant. Nachteil: erfordert Nutzeraktion. Diese Variante ist performant, setzt aber voraus, dass Nutzer aktiv nach weiteren Informationen suchen.

Performance-Hardfacts

Folgende Punkte sind in der Praxis entscheidend:

PDFs und umfangreiche Medien lazy laden oder erst nach Nutzeraktion nachladen
Große PDF-Dateien komprimieren, Dateigröße unter 500 KB anstreben
DOM schlank halten: nicht alle langen Inhalte mehrfach rendern
Nach Änderungen Cache leeren – abhängig von Shop, Template und Plugin

Performance-Optimierung ist kein Nice-to-have, sondern essenziell für gute Nutzererfahrung und SEO-Rankings. Langsame Ladezeiten führen zu höheren Absprungraten und beeinträchtigen die Conversion.

Plugin- und Template-Kompatibilität prüfen

Bevor das Setup live geht, sollten folgende Punkte geprüft werden:

Passt die JTL-Shop-Version zur Plugin-Version?
Überschreibt das Template Produktdetail-Blöcke, Tabs oder Attribut-Ausgaben?
Können Cache, Minify oder Bundling Konflikte mit JavaScript oder CSS verursachen?
Blockieren Consent- oder Cookie-Tools PDF-Viewer oder externe Links?
Beeinflussen Such-, Filter- oder SEO-Plugins das Rendering der Detailseite?

Die Praxis-Regel: Änderungen zuerst in Staging- oder Testsystem validieren – inklusive aktiver Cache-, Minify- und Consent-Konfiguration. Nur so lassen sich unerwartete Konflikte frühzeitig erkennen und beheben, bevor sie im Live-System Probleme verursachen.

Multichannel und Connector: Datenmodell-Mapping für konsistente Ausgabe

Wenn Produkte nicht nur im JTL-Shop, sondern auch auf Marktplätzen oder in anderen Systemen verkauft werden, muss das Datenmodell kanalübergreifend konsistent bleiben. Folgendes Minimal-Mapping hat sich bewährt:

Manufacturer: Name, Adresse, E-Mail oder Website → Hersteller-Entität oder Metafelder beim Artikel
EU Responsible Person: Name, Adresse, E-Mail oder Website → eigene Metafelder oder Custom Fields, je nach Zielsystem auf Artikel- oder Herstellerebene
Warnings/Safety Info: Textfelder → artikelbezogene Eigenschaften oder Metafelder, mehrsprachig falls nötig
Documents: Medien-URLs oder Assets → Artikel-Medien oder Downloads plus optional Metafelder für Dokumenttyp

Früh klären: Wo liegt die „Source of Truth" – in der Wawi, im PIM oder im jeweiligen Kanal? Sonst entstehen Abweichungen, die später schwer zu korrigieren sind. Eine klare Definition der führenden Datenquelle verhindert Inkonsistenzen und erleichtert die Synchronisation.

Test- und Abnahme-Protokoll: fachlich und technisch

Folgende Punkte sollten vor Go-Live geprüft werden:

Fachlicher Check

Herstellerangaben vollständig und korrekt?
EU-verantwortliche Person nur dort, wo nötig – und dann vollständig?
Warn- und Sicherheitsinfos passend, verständlich, sichtbar?

Technischer Check

Anzeige auf Produktdetailseite in Desktop plus Mobile – Viewport prüfen
Nach Datenpflege: Komplettabgleich durchgeführt?
Cache geleert und neu aufgebaut – Shop, Template, Plugin?
PDFs und Downloads erreichbar, keine 404-Fehler, Ladezeit vertretbar
Mehrsprachigkeit und Multishop: richtige Sprache und Shop-Kanal liefert richtige Inhalte

Regression-Check nach Updates

Template-Update oder Plugin-Update: GPSR-Block weiterhin sichtbar?
Minify und Consent aktiv: Interaktionen wie Tabs oder Akkordeon funktionieren?

Ein strukturiertes Abnahme-Protokoll schützt vor bösen Überraschungen nach dem Go-Live und stellt sicher, dass alle Anforderungen erfüllt sind. Regelmäßige Kontrollen nach Updates verhindern, dass wichtige Funktionen verloren gehen.

Was in der Praxis schiefgeht: typische Fehlerbilder

Folgende Fehler sehen wir immer wieder:

GPSR-Daten gepflegt, aber kein Komplettabgleich durchgeführt → nichts im Shop sichtbar
Daten pro Artikel gepflegt, obwohl zentral pro Hersteller sinnvoll wäre → unnötiger Aufwand
Importware ohne EU-Verantwortliche Person → Compliance-Risiko
Pflichtinfos vorhanden, aber nicht gut sichtbar oder schlecht platziert → Risiko plus schlechte UX
Historisch gewachsene Setups mit Attributen, Template-Anpassungen, Plugins → unklare Zuständigkeiten, doppelte oder fehlende Ausgaben
Performance-Falle: PDFs oder Medien direkt auf der Seite eingebunden → Ladezeiten und CLS-Probleme

Die meisten dieser Fehler lassen sich durch saubere Planung, strukturierte Prozesse und regelmäßige Kontrollen vermeiden. Eine gute Dokumentation hilft dabei, auch bei späteren Anpassungen den Überblick zu behalten.

Aufwand und Vorgehen: Zeit- und Risiko-Einschätzung je Szenario

Je nach Ausgangslage variiert der Aufwand erheblich:

Szenario A: Wawi ab Version 1.9.6.0 plus Plugin plus Standardtemplate

Aufwand: niedrig bis mittel – Datenpflege plus Sync plus Darstellung prüfen. Risiko: niedrig, wenn Komplettabgleich und Abnahme-Protokoll sauber sind. Dieses Szenario ist die empfohlene Standardlösung.

Szenario B: ältere Wawi oder schneller Workaround nötig

Aufwand: mittel – Funktionsattribute plus Ameise plus Template-Ausgabe. Risiko: mittel, durch Template-Wartung, Datenkonsistenz, Import-Fehler. Dieses Szenario funktioniert als Übergangslösung, sollte aber langfristig auf die native Lösung migriert werden.

Szenario C: großes Sortiment, viele Hersteller, häufige Änderungen

Aufwand: initial höher, danach deutlich niedriger durch zentrale Pflege und strukturierte Prozesse. Risiko: sinkt stark mit sauberem Datenmodell plus Massenprozessen. Investitionen in Struktur zahlen sich hier besonders schnell aus.

Entscheidungskriterien

Anzahl Artikel und Hersteller
Änderungsfrequenz – Sicherheitstexte, Importe
Multichannel oder Connector notwendig?
Ressourcen: Entwicklung versus Content-Pflege
Time-to-Implement versus Langzeit-Wartbarkeit

Eine ehrliche Bestandsaufnahme zu Beginn spart später Zeit, Geld und Nerven. Wer von Anfang an auf Skalierbarkeit und Wartbarkeit achtet, profitiert langfristig.

Frontend-Anforderung: Anpassbarkeit ohne Programmierung

Viele Shopbetreiber benötigen eine Lösung, die ohne tiefes Template-Coding anpassbar ist. Moderne Templates und Plugins wie das Snackys Template bieten umfangreiche Anpassungsoptionen, die es Nutzern ermöglichen, Layouts, Platzierung und Darstellung flexibel zu konfigurieren – ohne Programmierkenntnisse. Das gilt auch für GPSR-Inhalte: flexible Platzierung wie Tabs, Akkordeon oder Infobox, steuerbare Sichtbarkeit je Produkttyp oder Hersteller und Wartbarkeit bei Template-Updates sind möglich, wenn die Lösung entsprechend konzipiert ist.

Zielbild: saubere Datenpflege plus flexible, konfigurierbare Ausgabe statt individueller Sonderprogrammierung pro Produktseite. Solche Ansätze erleichtern die Arbeit für verschiedene Branchen und machen technische Shop-Optimierung auch für Nutzer ohne Programmierkenntnisse zugänglich. Das Snackys Template und die zugehörigen Plugins sind so konzipiert, dass sie Nutzern durch umfangreiche Anpassungsoptionen ermöglichen, ihre Shops individuell zu gestalten, ohne auf Entwickler angewiesen zu sein – und das über verschiedene Branchen hinweg.

Praxis-Checkliste: was du am Ende mitnehmen solltest

Folgende Punkte solltest du nach der Lektüre umsetzen können:

Welche GPSR-Datenfelder benötigt werden: Hersteller, EU-Verantwortliche Person, Warn- und Sicherheitsinfos, Dokumente
Wo diese Daten in JTL gepflegt werden: Wawi-Felder versus Funktionsattribute
Wie die Daten zuverlässig in den Shop kommen – Komplettabgleich ist Pflicht
Wie Pflegeaufwand reduziert wird: zentral pro Hersteller, Massenimport, klare Prozesse
Wie die Darstellung „gut sichtbar" und trotzdem UX- und Performance-tauglich bleibt: Tabs, Akkordeon, Lazyloading, saubere Platzierung
Wie du per Test- und Abnahme-Protokoll sicherstellst, dass alles live korrekt ist – inklusive Mobile, Cache, Consent und Minify

Die GPSR ist keine einmalige Aufgabe, sondern ein fortlaufender Prozess. Ein sauberes Setup spart langfristig Zeit, Geld und Nerven – und schützt vor rechtlichen Risiken. Wer jetzt strukturiert vorgeht, ist nicht nur rechtlich auf der sicheren Seite, sondern profitiert auch von skalierbaren, wartbaren Prozessen, die sich bei wachsendem Sortiment auszahlen.

Unsere Plugins