Ein Drupal-Produktkatalog ohne Commerce: Daten zuerst

Nicht jeder Hersteller braucht einen Onlineshop. Wenn Sie über Händler oder ein Vertriebsteam verkaufen, muss Ihre Website vor allem Produkte erklären, Käufern beim Vergleich von Spezifikationen helfen und aus Fragen Vertriebsgespräche machen. Ein Drupal-Produktkatalog ohne Commerce kann diese Aufgabe übernehmen, ohne Warenkorb, Checkout oder Onlinezahlungen einzuführen.

Ausgangspunkt sind strukturierte Produktdaten. Spezifikationen, Abmessungen, Materialien, Produktfamilien, Varianten, Bilder und begleitende Dokumente gehören in Datensätze, die Drupal auf verschiedenen Seiten und in anderen Ausgaben wiederverwenden kann. PDFs können Käufern weiterhin dienen, müssen aber nicht den gesamten Katalog tragen.

Diese Unterscheidung ist für Menschen und KI-Assistenten wichtig. Beide müssen das richtige Produkt finden, seine Attribute verstehen und eine Variante von einer anderen unterscheiden.

In diesem Artikel:

• Beginnen Sie mit der Aufgabe des Käufers, nicht mit dem Checkout
• Produkte als Datensätze mit klaren Beziehungen modellieren
• Ein gemeinsames Vokabular für Attribute, Familien und Varianten
• Komponenten sollen Daten anordnen, nicht duplizieren
• Produktlisten und Filter nach echten Auswahlkriterien aufbauen
• Produktdokumente aus denselben Datensätzen erzeugen
• Produktdaten für KI-Assistenten zugänglich machen
• Commerce ergänzen, wenn der Vertriebsprozess es verlangt
• Einen Katalog planen, den Ihr Team aktuell halten kann

Beginnen Sie mit der Aufgabe des Käufers, nicht mit dem Checkout

Angenommen, ein Hersteller verkauft Industriepumpen über Händler. Seine Käufer müssen Pumpen finden, die für ein bestimmtes Medium geeignet sind, Abmessungen und Betriebsgrenzen prüfen, technische Dokumentation herunterladen und nach der Verfügbarkeit fragen.

Die wichtigste Schaltfläche der Website könnte „Angebot anfordern“ oder „Händler finden“ sein. Keine von beiden erfordert ein Bestellsystem.

Eine nützliche Produktseite zeigt:

• Eine stabile Produktkennung und den Modellnamen.
• Eine Beschreibung des vorgesehenen Einsatzbereichs.
• Technische Spezifikationen mit Einheiten.
• Verfügbare Varianten und die Unterschiede zwischen ihnen.
• Bilder, Zeichnungen, Handbücher und Zertifikate.
• Eine Kontaktmöglichkeit, die die Kennung des Produkts oder der Variante in die Anfrage übernimmt.

Das ist eine Aufgabe der Veröffentlichung und der Produktauswahl. Wer sie als Onlineshop behandelt, führt Konzepte ein, die das Team vielleicht nie nutzt, und dazu Aufwand für Konfiguration, Tests und Wartung.

Beginnen Sie mit dem Katalog. Ob Transaktionen später auf die Website gehören, entscheidet der Vertriebsprozess.

Wie man Produkte auf Herstellerwebsites verwaltet, beschreibt auch der Artikel Wie man Produktdaten auf einer Drupal-Website für Hersteller effektiv verwaltet?

Produkte als Datensätze mit klaren Beziehungen modellieren

Strukturierte Datensätze reduzieren wiederholte Pflege. Ändert sich eine Abmessung, aktualisiert das Team das Quellfeld, statt jede Seite, jede Vergleichstabelle und jedes Dokument zu suchen, in das jemand den Wert kopiert hat.

In Drupal bedeutet „Entität“ nicht automatisch individuelle Entwicklung. Ein Node ist bereits eine Content-Entität. Ein Inhaltstyp „Produkt“ mit typisierten Feldern kann eine praktische Grundlage für einen Katalog sein.

Ein erstes Modell für den Pumpenhersteller könnte so aussehen:

Verwenden Sie Taxonomie-Begriffe für gemeinsame Klassifizierungen wie Material oder Einsatzbereich. Media-Entitäten können Dokumente und Bilder mit Metadaten speichern, sodass Redakteure eine Datei wiederverwenden, statt für jede Seite eine eigene Kopie hochzuladen.

Eine Familie kann ein Taxonomie-Begriff sein, wenn sie hauptsächlich Produkte gruppiert. Braucht sie umfangreiche redaktionelle Inhalte, Freigabeschritte oder eine eigene Seitenstruktur, passt ein separater Inhaltstyp möglicherweise besser.

Wählen Sie individuelle Content-Entitäten, wenn das Verhalten der Domäne den Mehraufwand rechtfertigt. Sie ermöglichen eine genauere Kontrolle über produktspezifisches Verhalten, aber das Team muss die nötigen redaktionellen Oberflächen und Funktionen für den Lebenszyklus selbst umsetzen und warten.

Für viele Kataloge bieten Inhaltstypen, Entitätsreferenzen, Taxonomie und Media genug Struktur.

Wie Sie vergleichbare Werte in Felder überführen, zeigen wir im Artikel Drupal Content Modeling für Answer Coverage: Felder statt Fließtext.

Festlegen, welches System für welches Feld verantwortlich ist

Wenn ein Product-Information-Management-System (PIM) bereits für die technischen Spezifikationen verantwortlich ist, kann Drupal diese Werte veröffentlichen, während Redakteure Webbeschreibungen und begleitende Inhalte pflegen.

Legen Sie diese Grenze früh fest. Sonst korrigiert ein Redakteur eine Spezifikation in Drupal, und der nächste Import überschreibt sie wieder.

Verwenden Sie stabile externe Kennungen für Importe und Beziehungen. Produktnamen ändern sich; Integrationen brauchen einen dauerhafteren Weg, denselben Datensatz zu erkennen.

Wie Sie die Verantwortung zwischen Drupal, PIM und ERP aufteilen, beschreiben wir im Artikel Drupal mit PIM und ERP als Quellen für Spezifikationen verbinden.

Ein gemeinsames Vokabular für Attribute, Familien und Varianten

Einheitliche Attribute machen Vergleiche verlässlich. Sie verhindern auch ein bekanntes Filterproblem: „Edelstahl“, „Nirosta“ und „VA“ erscheinen als getrennte Optionen, obwohl sie dasselbe bedeuten.

Definieren Sie für jedes Attribut:

• Bedeutung und Geltungsbereich.
• Datentyp.
• Einheit, sofern relevant.
• Zulässige Werte oder das referenzierte Vokabular.
• Für welche Produktfamilien es gilt.
• Regeln für Validierung und Anzeige.

Speichern Sie eine Abmessung als numerischen Wert mit definierter Einheit statt als Freitext wie „ca. 12 cm“. Ein Dezimalfeld kann den Wert enthalten, während die Konfiguration oder ein separates Einheitenfeld die Maßeinheit festlegt.

Manche Spezifikationen brauchen mehr Struktur. Minimale und maximale Betriebstemperatur sollten getrennte Werte sein, und eine Angabe zum Förderstrom braucht möglicherweise einen Verweis auf die Prüfbedingungen. Eine Zahl ohne ihre Bedingungen kann Käufer in die Irre führen.

Halten Sie unbekannte Werte getrennt. Eine leere Betriebsgrenze bedeutet nicht null, und „nicht zutreffend“ bedeutet nicht „noch nicht geliefert“.

Familien ordnen die relevanten Attribute

Pumpenfamilien können einige Attribute gemeinsam haben und sich in anderen unterscheiden. Eine Kreiselpumpe und eine Dosierpumpe brauchen nicht unbedingt identische Spezifikationsformulare.

Drupal leitet diese Unterschiede nicht aus der Bezeichnung einer Familie ab. Die Umsetzung muss sie über Inhaltstypen, Feldkonfiguration, Validierung oder individuelles Formularverhalten abbilden.

Bei einer überschaubaren Zahl stabiler Produkttypen sind explizite Felder oft einfacher zu pflegen und abzufragen als ein generisches Attribut-Wert-System. Kataloge mit vielen wechselnden Attributsätzen können ein dynamischeres Modell oder eine PIM-Integration rechtfertigen.

Entscheiden Sie nach der tatsächlichen Komplexität, nicht nach der Möglichkeit, dass der Katalog eines Tages alles enthalten könnte.

Varianten mit eigener Bedeutung eine eigene Identität geben

Eine Variante verdient einen eigenen Datensatz, wenn Käufer sie unabhängig identifizieren, referenzieren oder vergleichen müssen.

Beim Pumpenhersteller könnten Spannung und Anschlussgröße die bestellbaren Modelle unterscheiden. Jede Variante könnte eine eigene Kennung, relevante Spezifikationen, eine Zeichnung und einen Kontext für die Angebotsanfrage haben, obwohl die Website nie eine Bestellung verarbeitet.

Legen Sie fest, wo jeder Wert gespeichert wird. Zum Beispiel:

• Das Produkt enthält die gemeinsame Beschreibung und das Gehäusematerial.
• Die Variante enthält Spannung, Anschlussgröße und konfigurationsspezifische Abmessungen.
• Eine Anzeigeregel bestimmt, welche gemeinsamen Werte neben den Variantenwerten erscheinen.

Drupal braucht explizite Logik für vererbte und überschriebene Werte. Entitätsreferenzen allein legen diese Regeln nicht fest.

Bei einem kleinen Katalog kann es einfacher sein, jedes vermarktete Modell als vollständigen Produktdatensatz zu speichern, statt Vererbung einzuführen. Das richtige Modell ist das, das Redakteure pflegen können, ohne widersprüchliche Angaben zu erzeugen.

Komponenten sollen Daten anordnen, nicht duplizieren

Marketingteams brauchen Raum, um Produkte zu erklären. Sie möchten vielleicht eine Anwendungsgeschichte, ein Installationsbild, ein Spezifikationsfeld und einen Block für Angebotsanfragen auf derselben Seite.

Eine Komponentenbibliothek ermöglicht diese Freiheit, während die Produktdaten nur in ihren Feldern gepflegt werden.

Die Regel ist einfach: Felder enthalten die Produktdaten; Komponenten ordnen sie an und stellen sie dar.

Eine Spezifikationskomponente sollte die Felder des Produkts auslesen. Sie sollte Redakteuren kein weiteres Textfeld geben, in das sie dieselben Abmessungen eintippen können. Ein Variantenvergleich sollte die referenzierten Varianten laden, statt eine separate, von Hand geschriebene Tabelle zu pflegen.

Drupal bietet dafür mehrere Bausteine:

• Ansichtsmodi und Feldformatierer (Field Formatters) steuern, wie Entitätsdaten erscheinen.
• Layout Builder kann Redakteuren die Kontrolle über den Seitenaufbau geben.
• Single Directory Components können wiederverwendbare Templates, Styles und Skripte bündeln.
• Paragraphs können, wo es passt, strukturierte redaktionelle Abschnitte unterstützen.

Diese Werkzeuge haben unterschiedliche Aufgaben. Eine Komponentenbibliothek verbindet ein Template nicht automatisch mit Produktfeldern und setzt keine Bearbeitungsregeln durch. Entwickler müssen diese Verbindungen bauen und die erlaubten Layouts und Blöcke konfigurieren.

Im Pumpenkatalog könnten Redakteure eine Produkteinführung, eine Spezifikationstabelle, eine Dokumentenliste, einen Abschnitt zu Einsatzbereichen und einen Anfrageblock anordnen. Die technischen Werte kämen weiterhin aus den Datensätzen für Produkte und Varianten.

Lassen Sie Raum für Fließtext. Installationshinweise und Erklärungen zu Anwendungsfällen brauchen ihn oft. Daten, die für Filter, Vergleiche oder automatische Extraktion genutzt werden, gehören in Felder.

Wie wir mit Kunden an Komponenten arbeiten, beschreibt der Artikel Komponenten-Mindset: Kunden beibringen, in Komponenten zu denken.

Produktlisten und Filter nach echten Auswahlkriterien aufbauen

Gute Filter ersparen Käufern, ein Dutzend ungeeigneter Produkte zu öffnen.

Beginnen Sie damit, wie Kunden Geräte auswählen. Beim Pumpenhersteller könnten Einsatzbereich, Medienbeständigkeit, Förderstrombereich, Gehäusematerial und Anschlussgröße sinnvolle Filter sein.

Das Modul Views kann Produktlisten und einfache offene Filter (Exposed Filters) bereitstellen. Für anspruchsvollere Suchen können das Search-API-Ökosystem, ein passender Suchserver (zum Beispiel Apache Solr) und kompatible Facettenmodule eine reichere Indexierung und Navigation ermöglichen.

Die Architektur hängt von der Größe des Katalogs und den Suchanforderungen ab. Ein kleiner Katalog braucht möglicherweise keinen separaten Suchdienst.

Ein Beispiel für eine Produktsuche auf Basis von Apache Solr finden Sie im Artikel Produktsuchmaschine in Drupal mit Apache Solr-Integration - Anleitung.

Zeigen die Ergebnisse Produkte oder Varianten?

Diese Entscheidung beeinflusst sowohl die Filterung als auch die Genauigkeit.

Angenommen, eine Pumpenvariante unterstützt die gewählte Spannung, während eine andere Variante die gewählte Anschlussgröße hat. Eine Suche auf Produktebene, die alle Variantenattribute zusammenführt, könnte das übergeordnete Produkt anzeigen, obwohl keine einzelne Variante beide Anforderungen erfüllt.

Vermeiden Sie diese Mehrdeutigkeit, indem Sie Varianten separat indexieren oder Abfragen so gestalten, dass die Beziehung zwischen den Attributen derselben Variante erhalten bleibt. Wenn die Ergebnisse passende Varianten unter einem Produkt gruppieren, zeigen Sie, welche Varianten infrage kommen.

Legen Sie auch fest, wie sich Bereiche verhalten sollen. Produkte zu filtern, deren maximaler Förderstrom einen Wert übersteigt, ist etwas anderes, als Produkte zu finden, deren Betriebsbereich diesen Wert einschließt.

Verwenden Sie einheitliche Einheiten im Index, prüfen Sie die Regeln anhand echter Auswahlaufgaben und zeigen Sie genug Kontext, damit Käufer jeden Treffer verstehen.

Auch die Aktualität der Suche braucht Aufmerksamkeit. Eine veröffentlichte Änderung einer Spezifikation sollte das entsprechende Index-Update und die Cache-Invalidierung auslösen. Sonst können Produktseite und Filterergebnisse voneinander abweichen.

Produktdokumente aus denselben Datensätzen erzeugen

Käufer brauchen weiterhin Dokumente. Sie schicken technische Datenblätter per E-Mail an Kollegen, hängen sie an Beschaffungsanfragen an und nehmen sie mit auf die Baustelle.

Das Ziel ist nicht, PDFs abzuschaffen. Es geht darum, dieselben Spezifikationen nicht mehr doppelt zu pflegen.

Ein Dokumentengenerator pro Produkt kann strukturierte Felder, referenzierte Dateien und ein kontrolliertes Template zu einem technischen Datenblatt kombinieren. Webseite und erzeugtes Dokument greifen dann auf denselben Produktdatensatz zu.

Ein sinnvoller Erzeugungsprozess:

1. Wählt die vorgesehene veröffentlichte Revision des Produkts oder der Variante und die Sprache aus.
2. Ermittelt die zutreffenden Spezifikationen und begleitenden Bilder.
3. Erstellt das Dokument mit einem gepflegten Template.
4. Speichert die Quellrevision und das Erzeugungsdatum.
5. Ersetzt oder invalidiert die erzeugte Kopie, wenn sich ihre Quelle ändert.

Drupal braucht für diesen Ablauf eine Integration oder eine individuelle Umsetzung; Produktfelder allein erzeugen keine PDFs. Bei größeren Katalogen kann eine Erzeugung über eine Warteschlange das Rendern der Dokumente aus dem Seitenaufruf des Besuchers heraushalten.

Machen Sie das Dokumentdatum eindeutig. Ein Erzeugungszeitstempel sagt dem Leser, wann die Datei erstellt wurde, nicht unbedingt, wann ein Ingenieur die Spezifikationen geprüft hat.

Manche Dokumente sollten kontrollierte Uploads bleiben. Unterschriebene Zertifikate, extern ausgestellte Prüfberichte und freigegebene Zeichnungen haben eigene Revisionsprozesse. Verweisen Sie vom Produkt auf sie, statt sie neu zu erstellen.

Bei Dokumenten mit eingeschränktem Zugriff wenden Sie die Zugriffsregeln nicht nur auf den Link auf der Seite an, sondern auch auf die Download-Route und den Speichermechanismus.

Wie Sie PDFs aus Entitäten erzeugen, beschreibt der Artikel Erstellen Sie ein PDF von jedem Entity in Drupal - Überprüfung des Entity Print Moduls. Den umgekehrten Weg, also Daten aus PDFs nach Drupal zu übernehmen, beschreibt der Artikel Eine Drupal-Pipeline, die PDFs in strukturierte Inhalte verwandelt.

Produktdaten für KI-Assistenten zugänglich machen

KI-Assistenten können Ihrem Katalog über Suchergebnisse, gerenderte Seiten, strukturierte Metadaten oder eine Integration begegnen. Klare Produktdatensätze geben Ihnen eine einheitliche Quelle für all diese Kanäle.

Sie garantieren weder Auffindbarkeit noch Empfehlungen. Sie machen eine korrekte Interpretation aber wahrscheinlicher.

Beim Pumpenhersteller muss ein Assistent eine Familie von einem Modell unterscheiden, die gewählte Variante erkennen und eine Spezifikation mit ihrer Einheit und ihren Betriebsbedingungen verbinden. Ein Ordner mit uneinheitlich benannten PDFs macht das schwieriger.

Ein praktischer Ansatz für die Veröffentlichung umfasst:

• Lesbares HTML: Öffentliche Spezifikationen gehören in beschriftete Seiteninhalte, auf die Besucher und Suchmaschinen-Crawler zugreifen können.
• Stabile URLs und Kennungen: Produkte und unabhängig referenzierte Varianten brauchen dauerhafte Identitäten.
• JSON-LD: Ordnen Sie geeignete Felder den Schema.org-Eigenschaften für Product zu und nutzen Sie zusätzliche Eigenschaften, wo es passt.
• APIs oder Feeds: Stellen Sie freigegebene Felder für Integrationen bereit, die strukturierte Datensätze brauchen.
• Einheitlicher Umgang mit Revisionen: Aktualisieren Sie abgeleitete Ausgaben, wenn sich die Quelle ändert.

Schema.org-Markup sollte das sichtbare Produkt korrekt wiedergeben. Erfinden Sie keine Preise, Verfügbarkeiten, Bewertungen oder Angebote, nur um ein Template zu füllen. Gültiges Markup garantiert außerdem nicht, dass die Seite für die Produktfunktionen einer Suchmaschine infrage kommt.

JSON:API im Drupal-Core kann Entitätsdaten bereitstellen, abhängig von Konfiguration und Zugriffsprüfungen. Behandeln Sie die öffentliche Schnittstelle als bewusste Entscheidung über die Veröffentlichung: Prüfen Sie aktivierte Ressourcen, Feldzugriff, unveröffentlichte Inhalte und referenzierte Dateien.

Markdown-Exporte oder eine MCP-Integration können für einen bestimmten Agenten-Workflow sinnvoll sein. Keines von beiden ersetzt zugängliche Produktseiten, und keines ist für jeden Katalog nötig. Wenn Sie Werkzeuge für Agenten ergänzen, legen Sie fest, was sie lesen oder tun dürfen, und testen Sie diese Grenzen.

Einheitliche Daten kommen zuerst. Ein weiteres maschinenlesbares Format behebt keine widersprüchlichen Spezifikationen.

Wie Sie JSON-LD aus Feldern erzeugen, zeigen wir im Artikel JSON-LD in Drupal: so erzeugen Sie strukturierte Daten aus Feldern mit Schema.org Metatag.

Commerce ergänzen, wenn der Vertriebsprozess es verlangt

Drupal Commerce wird relevant, wenn die Website Transaktionsabläufe unterstützen soll, statt Produkte nur zu beschreiben.

Ein Preisfeld allein macht eine Website nicht zum Shop. Eine Variantenkennung auch nicht.

Commerce bietet commerce-spezifische Konzepte, darunter kaufbare Varianten, Warenkorb, Bestellungen, Checkout und die Möglichkeit, Zahlungsanbieter zu integrieren. Diese Konzepte werden nützlich, wenn Ihre Anforderungen von ihnen abhängen.

Wenn Onlinekäufe bereits geplant sind, berücksichtigen Sie diese künftige Architektur, bevor Sie den Katalog bauen. Stabile Kennungen und klare Beziehungen können einen späteren Umstieg erleichtern, aber der Wechsel zu Commerce erfordert trotzdem Datenzuordnung, Entscheidungen zu Abläufen und Tests.

Die Funktionen der Plattform beschreibt der Artikel Leitfaden zur Drupal Commerce-Plattform. Was sind die Funktionen von Drupal Commerce?

Einen Katalog planen, den Ihr Team aktuell halten kann

Beginnen Sie mit einer repräsentativen Produktfamilie, einschließlich der schwierigen Fälle: fehlende Spezifikationen, mehrere Sprachen, variantenspezifische Zeichnungen und Dokumente, die mehrere Produkte gemeinsam nutzen.

Bauen Sie einen vollständigen Weg von der Bearbeitung bis zur Veröffentlichung. Prüfen Sie Produktseite, Produktliste, Filter, Angebotsanfrage, maschinenlesbare Ausgabe und das erzeugte technische Datenblatt.

Ändern Sie dann eine Spezifikation. Wird jede Ausgabe korrekt aktualisiert? Sieht ein Redakteur, welche Werte fehlen? Enthält die Anfrage genau die Variante, die der Käufer gewählt hat?

Diese Tests zeigen mehr als ein ausgefeiltes Seiten-Mockup.

Drupal passt gut, wenn Ihr Katalog wiederverwendbare Daten, Beziehungen, redaktionelle Abläufe, mehrsprachige Veröffentlichung und mehrere Ausgabeformate braucht. Ein kleiner, selten aktualisierter Katalog mit wenigen Filtern ist auf einer einfacheren Plattform möglicherweise leichter zu pflegen. Ein Hersteller mit umfangreichen Prozessen rund um Produktdaten braucht neben Drupal unter Umständen ein PIM.

Die sinnvolle Unterscheidung lautet strukturierter Katalog oder duplizierte Informationen, nicht Katalog oder Shop. Bauen Sie die Datensätze um das herum auf, was Käufer wissen müssen, und lassen Sie Seiten, Dokumente und Integrationen diese Daten wiederverwenden.

Sie planen einen Drupal-Produktkatalog ohne Commerce? Bringen Sie eine Beispiel-Produktfamilie, einige technische Datenblätter und die Fragen mit, die Käufer am häufigsten stellen, und sprechen Sie mit Droptica. Wir helfen Ihnen, Datensätze, Filter und den Veröffentlichungsprozess zu planen, und prüfen dann, ob irgendein Teil Ihres Vertriebsprozesses tatsächlich Commerce erfordert. Mehr über unsere Arbeit erfahren Sie auf der Seite zu unseren Drupal-Entwicklungsdiensten.