Datenmodelle statt Plugin-Stapel

Viele WordPress-Websites werden nicht zu komplex, weil eine Funktion fehlt, sondern weil Inhalte ohne klares Schema wachsen. Ein neues Plugin erzeugt ein Feld, ein zweites eine Filterseite, ein drittes einen eigenen Inhaltstyp. Kurzfristig funktioniert das. Spätestens beim Theme-Wechsel, bei einer API-Anbindung oder bei neuen Redaktionsabläufen ist aber unklar, welche Daten wozu gehören. Ein belastbares WordPress Datenmodell beantwortet diese Frage vor der Werkzeugwahl.

Die Suchintention hinter diesem Thema ist praktisch: Verantwortliche müssen entscheiden, ob etwa „Referenzen“, „Standorte“, „Leistungen“ oder „Veranstaltungen“ ein eigener Inhaltstyp, eine Eigenschaft, eine Klassifikation oder schlicht eine Plugin-Funktion sein sollen. Die richtige Antwort hängt nicht von der Zahl der verfügbaren Plugins ab. Sie folgt aus Bedeutung, Lebenszyklus und späterer Nutzung der Daten.

Die Entscheidung beginnt mit der fachlichen Entität

Ein Datenmodell beschreibt, welche Objekte eine Website kennt, welche Eigenschaften sie besitzen und wie sie sich zueinander verhalten. Für eine B2B-Seite können das etwa Leistungen, Branchen, Ansprechpartner und Fallstudien sein. Erst wenn diese Begriffe sauber getrennt sind, lässt sich die WordPress-Technik passend zuordnen. Die Leitfrage lautet deshalb nicht „Brauchen wir ein Plugin?“, sondern: Ist dies ein eigenständiger Inhalt, ein Wert an einem Inhalt, eine wiederverwendbare Einordnung oder ein Verhalten?

Ein eigenständiger Inhalt hat üblicherweise einen eigenen Titel, Redaktionstext, Bearbeitungsstatus und eine eigene Detailseite. Eine Fallstudie bleibt beispielsweise dieselbe Fallstudie, auch wenn sich ihre Branche, ihr Veröffentlichungsdatum oder ihr Projektvolumen ändern. Diese stabile Identität spricht für einen Custom Post Type. Ein Projektvolumen dagegen ist eine Eigenschaft der Fallstudie. Es ist ein Feld. Die Branche kann vielen Fallstudien zugewiesen werden und ist als navigierbarer Filter interessant. Das spricht für eine Taxonomie. Ein Formularversand oder eine Kartenintegration ist dagegen Verhalten; dafür ist ein Plugin oder eine gezielte Integration zuständig.

Diese Trennung verhindert zwei typische Fehlentscheidungen. Erstens wird nicht jeder Wert zu einer Taxonomie, nur weil Redakteure ihn auswählen sollen. Zweitens wird nicht jede neue Sicht auf Inhalte als neuer Post Type angelegt. Ein Inhaltstyp modelliert eine fachliche Klasse, keine Darstellungsvariante. „Aktuelle Referenzen“ und „Alle Referenzen“ sind daher normalerweise Abfragen desselben Typs, keine zwei Typen.

Fachliche Frage	Geeignetes Mittel	Beispiel	Nicht passend, wenn
Hat das Objekt eine eigene Identität, Detailseite und Redaktion?	Custom Post Type	Fallstudie, Standort, Veranstaltung	Es nur eine zusätzliche Angabe zu einem bestehenden Inhalt ist
Beschreibt genau ein Wert den Inhalt?	Benutzerdefiniertes Feld (Meta)	Startdatum, PDF-URL, Projektsumme	Der Wert als unabhängiger Navigationspunkt dienen soll
Wird ein Begriff vielen Inhalten zugeordnet und gefiltert?	Taxonomie mit Terms	Branche, Region, Veranstaltungsformat	Es ein einmaliger oder freier Einzelwert ist
Erzeugt die Anforderung Verhalten oder eine externe Anbindung?	Plugin, eigener Code oder Integration	Formular, Consent, CRM-Synchronisation	Sie eigentlich die Semantik der Inhalte festlegt

Custom Post Types: für eigenständige Inhalte

Ein Custom Post Type (CPT) erweitert WordPress um eine fachlich benannte Inhaltsklasse. WordPress registriert ihn mit register_post_type(); nach der Registrierung erhält der Typ eine eigene Verwaltungsoberfläche. Die offizielle Dokumentation empfiehlt ausdrücklich, Custom Post Types in einem Plugin statt in einem Theme zu hinterlegen. So bleiben die Inhalte beim Theme-Wechsel portabel. Außerdem darf der technische Typ-Schlüssel höchstens 20 Zeichen lang sein und sollte einen projektspezifischen Präfix tragen, um Kollisionen zu vermeiden. 1

Für „Standorte“ ist ein CPT plausibel, wenn jeder Standort eine Adresse, einen Ansprechpartner, Öffnungszeiten, einen Beschreibungstext und eine eigene URL besitzt. Für „Hero-Bild vorhanden“ wäre er absurd. Entscheidend ist auch der Lebenszyklus: Wird der Gegenstand von mehreren Personen gepflegt, archiviert, gesucht oder in unterschiedlichen Templates ausgespielt, lohnt sich ein eigener Typ früh. WordPress speichert Post Types in der Tabelle posts; der CPT ist somit kein separates Fremdsystem, sondern eine strukturierte Nutzung des WordPress-Kerns. 2

Ein CPT sollte jedoch nicht zum Ausweichlager für unklare Daten werden. „Mitarbeiter-Spezialisierung“ ist meist keine neue Entität neben „Mitarbeiter“, sondern eine Zuordnung oder Eigenschaft. Wer jedes wiederkehrende Wort zu einem Typ macht, vervielfacht Editoren, Berechtigungen, Templates und URLs. Das erschwert die Redaktion statt sie zu unterstützen. Für die Vorarbeit eignet sich ein WordPress-Architektur-Audit: Es legt Objekte, Verantwortlichkeiten und bestehende Abhängigkeiten offen, bevor neue Datenstrukturen live gehen.

Felder: für Eigenschaften mit klarer Bedeutung

Benutzerdefinierte Felder speichern Metadaten, also Informationen zu einem Inhalt, Benutzer, Kommentar oder Term. WordPress beschreibt die Beziehung von Metadaten zu ihrem Objekt als many-to-one: Zu einem Objekt können daher zahlreiche Meta-Angaben gehören. 3 Das macht Felder geeignet für Attribute wie Startdatum, externe Kennung, Projektsumme, Download-Adresse oder Schalterwerte. Sie gehören fachlich zum jeweiligen Inhalt und benötigen meist keine eigene Archivseite.

Ein Feld sollte einen eindeutigen Namen, einen definierten Datentyp, eine Validierung und eine Regel für leere Werte erhalten. „Datum“ ist kein gutes Feldkonzept; event_start mit dem vereinbarten Format YYYY-MM-DD schon. Ebenso sollte ein Preis nicht zugleich als formatierten Text, als Zahl und als versteckter Filterwert gespeichert werden. Eine Quelle der Wahrheit pro Eigenschaft vereinfacht Abfragen, Exporte und spätere Migrationen.

Die Registrierung gehört zum Modell, auch wenn ein Feld-Plugin die Eingabemaske komfortabel erzeugt. register_meta() kennt unter anderem die Typen string, boolean, integer, number, array und object sowie Rückrufe für Bereinigung und Berechtigungsprüfung. WordPress empfiehlt, Meta-Schlüssel möglichst für die konkrete Kombination aus Objekttyp und Untertyp zu registrieren. 4 Soll ein Feld über die REST-API erreichbar sein, muss es mit show_in_rest freigegeben werden; beim Post Type ist zusätzlich die Unterstützung für Custom Fields erforderlich. 4

Taxonomien: für kontrollierte, wiederverwendbare Einordnung

Eine Taxonomie ist in WordPress ein System zur Klassifikation oder Gruppierung. Sie kann hierarchisch mit Eltern- und Kindbegriffen oder flach sein. Ihre einzelnen Begriffe heißen Terms. 5 Für Fallstudien sind „Branche“ und „Leistungsbereich“ gute Kandidaten, wenn Besucher danach filtern und Redakteure aus einem kontrollierten Vokabular wählen sollen. Für Veranstaltungen kann „Format“ als flache Taxonomie funktionieren; bei einer geografischen Struktur kann „Region“ hierarchisch sinnvoll sein.

Die wichtigste Abgrenzung lautet: Ein Term muss in seiner Wiederverwendung wertvoll sein. Eine Branche, die viele Fallstudien verbindet, trägt Navigation, Archivseiten und Filter. Eine individuelle Kundennummer tut das nicht und bleibt ein Feld. Auch ein Freitext wie eine abweichende Projektbezeichnung sollte nicht künstlich zum Term werden. Sonst entstehen Dubletten, Tippvarianten und Schein-Archive ohne redaktionellen Nutzen.

Eigene Taxonomien sind den Standardkategorien und -tags vorzuziehen, wenn sie eine fachlich getrennte Benennung benötigen. WordPress hebt als Vorteil hervor, dass solche Systeme unabhängig von Kategorien und Tags referenzierbar sind und eigene Menüs im Backend erhalten. 6 Das ist besonders wichtig, wenn mehrere Teams arbeiten: „Thema“ für Blogbeiträge und „Branche“ für Fallstudien dürfen im Interface nicht dieselbe, semantisch überladene Liste sein. Eine klare WordPress-Governance definiert dafür Begriffsverantwortung, Anlageregeln und Freigaben.

Der Plugin-Stack folgt dem Modell – nicht umgekehrt

Plugins sind wertvoll, wenn sie eine Fähigkeit liefern: eine sichere Formulareingabe, eine Suche, eine Kartenanzeige, ein Formular-zu-CRM-Workflow oder eine bessere Redaktionsoberfläche. Problematisch wird es, wenn ein Plugin ohne fachliche Entscheidung zum Eigentümer zentraler Unternehmensdaten wird. Dann bestimmt dessen Bedienoberfläche, ob etwas ein Feld, ein Typ oder ein Filter ist. Ein späterer Austausch wird zur Datenmigration statt zu einer austauschbaren Funktionsentscheidung.

Die robuste Aufteilung lautet: Das projektspezifische Datenmodell liegt in einem kleinen Site-Plugin oder einem gepflegten Must-use-Plugin. Das gewählte Feld- oder Block-Plugin kann darauf aufsetzen und die Redaktion erleichtern. Templates und Blocks lesen die registrierten Daten. Integrationsplugins erhalten klar abgegrenzte Schnittstellen. Damit bleibt die Kernfrage beantwortbar: Welcher Code definiert die Daten, und welcher Code stellt sie nur dar oder transportiert sie?

Prüfen Sie vor der Umsetzung diese kurze Checkliste:

Benennen Sie die Entität im Singular. Kann sie einen eigenen Titel und eine eigene URL tragen, ist ein CPT wahrscheinlich sinnvoll.
Formulieren Sie jedes Feld als Satz. „Eine Veranstaltung hat genau ein Startdatum“ macht Kardinalität und Datentyp sichtbar.
Testen Sie jeden Term gegen Navigation. Wird er mehrfach zugewiesen, gesucht oder archiviert, rechtfertigt er meist eine Taxonomie.
Trennen Sie Modell und Eingabehilfe. Eine angenehme Eingabemaske ist kein Ersatz für registrierte Felder und dokumentierte Schlüssel.
Planen Sie den Wechsel mit. Export, REST-Schnittstelle, Verantwortliche und URL-Struktur müssen ohne das aktuelle Theme nachvollziehbar bleiben.

Ein kleines, registriertes Modell für Veranstaltungen

Das folgende Beispiel registriert einen Inhaltstyp, eine Taxonomie und ein typisiertes Meta-Feld. Es gehört in ein projektspezifisches Plugin, nicht in das aktive Theme. Der Präfix btk_ reduziert das Risiko kollidierender Kennungen. Das Beispiel erzeugt bewusst keine eigene Eingabemaske; diese kann ein passendes Editor- oder Feld-Plugin liefern, ohne die Datenstruktur zu besitzen.

<?php
add_action( 'init', 'btk_register_event_model' );

function btk_register_event_model() {
    register_post_type( 'btk_event', [
        'labels'       => [ 'name' => __( 'Veranstaltungen', 'btk' ) ],
        'public'       => true,
        'show_in_rest' => true,
        'has_archive'  => true,
        'rewrite'      => [ 'slug' => 'veranstaltungen' ],
        'supports'     => [ 'title', 'editor', 'excerpt', 'thumbnail', 'revisions', 'custom-fields' ],
    ] );

    register_taxonomy( 'btk_event_format', [ 'btk_event' ], [
        'label'        => __( 'Format', 'btk' ),
        'public'       => true,
        'hierarchical' => false,
        'show_in_rest' => true,
        'rewrite'      => [ 'slug' => 'veranstaltungsformat' ],
    ] );

    register_post_meta( 'btk_event', 'btk_event_start', [
        'type'              => 'string',
        'single'            => true,
        'sanitize_callback' => 'sanitize_text_field',
        'auth_callback'     => static function ( $allowed, $meta_key, $object_id ) {
            return current_user_can( 'edit_post', $object_id );
        },
        'show_in_rest'      => true,
        'revisions_enabled' => true,
    ] );
}

Die Registrierung macht die beabsichtigte Datenform sichtbar: Ein Termin hat einen einzelnen Startwert, während ein Termin mehrere Formate über Terms zugeordnet bekommen kann. revisions_enabled ist hier möglich, weil der CPT Revisionen unterstützt; WordPress erlaubt Meta-Revisionen nur für den Objekttyp post und nur, wenn der konkrete Post Type selbst Revisionen unterstützt. 4 Für ein echtes Datum ergänzt die Speicherroutine zusätzlich eine Formatprüfung; sanitize_text_field() bereinigt Text, validiert aber kein fachliches Datumsformat.

Grenzen, Suchstruktur und Migration mitdenken

Nicht jede Beziehung passt gut in einzelne Meta-Werte. Wenn beispielsweise ein Projekt mehrere Ansprechpartner mit jeweiligen Rollen, Zeiträumen und Freigabestufen verbindet, ist eine lose Sammlung von IDs schnell unverständlich. Beginnen Sie trotzdem mit dem fachlichen Modell: Sind Ansprechpartner eigene Inhalte? Ist die Rolle eine Taxonomie, ein Feld an der Beziehung oder ein eigener Datensatz? Erst bei echten n:m-Beziehungen mit zusätzlichen Beziehungsattributen, transaktionalen Abläufen oder komplexem Reporting ist eine individuell entworfene Tabelle zu prüfen. Sie ist kein Performance-Reflex, sondern eine begründete Architekturentscheidung.

Auch SEO profitiert von dieser Reihenfolge. Ein CPT schafft konsistente Einzel- und Archivseiten; eine Taxonomie kann nachvollziehbare thematische oder regionale Archive ermöglichen. Beides verdient nur dann indexierbare URLs, wenn die Seiten eine eigene Suchintention, kuratierte Inhalte und ausreichende Differenzierung haben. Filterkombinationen, leere Term-Archive und bloße Sortierparameter sind keine automatisch wertvollen Landingpages. Legen Sie Slugs, Canonicals, interne Navigation und redaktionelle Texte gemeinsam mit dem Modell fest, nicht erst nach dem Go-live.

Die Migration wird leichter, wenn technische Schlüssel stabil, sprechend und dokumentiert sind. Notieren Sie pro Entität den CPT-Slug, pro Taxonomie die erlaubten Terms und pro Feld Typ, Format, Pflichtstatus und Quelle. Prüfen Sie zusätzlich, welche Daten ein Drittanbieter-Plugin bereits in Post Meta oder eigenen Tabellen ablegt. Eine WordPress-Update-Strategie sollte diese Abhängigkeiten einschließlich Staging-Test und Rückfallplan berücksichtigen. So bleibt ein Plugin-Wechsel planbar, statt zum riskanten Eingriff in historische Inhalte zu werden.

Fazit: erst Bedeutung, dann Werkzeug

Ein gutes WordPress Datenmodell ist keine abstrakte Vorarbeit, sondern die Grundlage für eine verständliche Redaktion, belastbare Templates und saubere Weiterentwicklung. Verwenden Sie einen Custom Post Type für eigenständige Inhalte, Felder für klar definierte Eigenschaften, Taxonomien für wiederverwendbare Klassifikationen und Plugins für abgegrenzte Fähigkeiten. Wo diese Entscheidung schriftlich festgehalten ist, wird der Plugin-Stack kleiner, austauschbarer und beherrschbar. Wo sie fehlt, verdeckt jedes neue Plugin das eigentliche Datenproblem nur für kurze Zeit.

Weiterführende Quellen

Diese offiziellen Dokumentationen und Standards vertiefen die im Beitrag behandelten Entscheidungen.