Custom Post Types sind eigene Inhaltstypen in WordPress, getrennt von Beiträgen und Seiten, mit eigenem Editor, eigener URL und eigenem Archiv. Sie lohnen sich, sobald ein Inhalt eigene Felder, eine eigene Übersichtsseite oder einen eigenen Lebenszyklus braucht, etwa Portfolios, Events oder Rezepte. Technisch registrieren Sie einen solchen Beitragstyp mit register_post_type() oder greifen auf Plugins wie CPT UI zurück.
Kurz gesagt:
- Custom Post Types sind sinnvoll, wenn Inhalte ein eigenständiges Archiv, spezielle Felder und eine eigene URL-Struktur benötigen.
- Für kleine Projekte reicht oft CPT UI oder ein Plugin, während bei langfristigen Vorhaben die Registrierung in einem eigenen Plugin mit
register_post_type()die robusteste Lösung ist.- Beim Registrieren mit
register_post_type()müssen die Rewrite-Regeln neu gesetzt werden, sonst führen Archiv- und Einzelansichten häufig zu 404-Fehlern.- Prefixen Sie Post-Type-Keys immer mit einem kurzen Projekt- oder Firmenkürzel, um Konflikte und Performance-Probleme bei großen Datenmengen zu vermeiden.
- Taxonomien sollten explizit mit
register_taxonomy()registriert werden, um Archiv- und Abfragefehler bei Custom Post Types zu verhindern.
Inhaltsverzeichnis
- Wann Sie einen Custom Post Type statt Beiträgen oder Custom Fields brauchen
- CPTs per Plugin oder per Code: Welche Methode passt zu Ihnen
- Wie funktioniert register_post_type() im Detail
- Taxonomien und Custom Fields sauber mit CPTs verknüpfen
- Frontend-Darstellung: Templates, Permalinks und typische Fehler
- Best Practices für Performance und Wartbarkeit
- Praxiserfahrung aus Agenturprojekten von Werbeeinfach
- Wie Werbeeinfach Sie bei der Umsetzung unterstützt
- Quellen
- FAQ
Wann Sie einen Custom Post Type statt Beiträgen oder Custom Fields brauchen
Nicht jeder Inhalt verdient einen eigenen Beitragstyp. Die Faustregel: Ein Custom Post Type lohnt sich, wenn der Inhalt einen eigenen Lebenszyklus hat, ein eigenes Archiv braucht und im Admin-Menü als eigener Punkt auftauchen soll, getrennt von den normalen Beiträgen.
Drei Signale sprechen fast immer für einen eigenen Beitragstyp:
- Der Inhalt hat eine eigene Editor-Ansicht mit spezifischen Feldern, die bei normalen Beiträgen keinen Sinn ergeben (zum Beispiel Veranstaltungsdatum, Zutatenliste, Referenzkunde).
- Er braucht eine eigene Archivseite mit eigener URL-Struktur, unabhängig von der Blog-Übersicht.
- Er soll im Admin-Bereich als eigener Menüpunkt erscheinen, damit Redakteure nicht zwischen normalen Beiträgen und Sonderinhalten suchen müssen.
Typische Praxisbeispiele: ein Portfolio mit Projektreferenzen, eine Eventseite mit Datum und Ort, eine Rezeptsammlung mit Zutaten und Zubereitungszeit, Kundenstimmen mit Bewertung und Foto oder ein eigener Produktkatalog außerhalb von WooCommerce. Laut Elementor nutzen viele Enterprise-WordPress-Installationen mehrere Custom Post Types, oft fünf oder mehr, meist für genau solche Inhalte, die eben nicht in den klassischen Blog-Rhythmus passen.
Nicht jedes Problem braucht aber einen neuen Beitragstyp. Wenn Sie nur Inhalte gruppieren oder filtern wollen, etwa nach Kategorie oder Standort, reicht oft eine eigene Taxonomie auf bestehenden Beiträgen. Und wenn Sie nur ein zusätzliches Feld an einen bestehenden Beitrag anhängen wollen, wie ein Zitat oder ein Icon, genügt ein Custom Field per ACF oder eigener Meta-Box. Ein eigener Beitragstyp lohnt sich erst, wenn mehrere solcher Felder zusammenkommen und der Inhalt strukturell eigenständig ist. Diese Unterscheidung entscheidet oft darüber, ob eine WordPress-Website später wartbar bleibt oder im Feld-Wildwuchs versinkt.
CPTs per Plugin oder per Code: Welche Methode passt zu Ihnen
Es gibt zwei grundsätzliche Wege, einen Custom Post Type anzulegen: über ein Plugin mit Oberfläche oder direkt im Code. Beide haben ihre Berechtigung, je nachdem, wer am Projekt arbeitet und wie langfristig es gepflegt werden soll.
CPT UI ist die schnellste Einstiegsoption ohne Programmierkenntnisse. Sie legen Beitragstyp und Taxonomie über ein Formular an, das Plugin übernimmt die Registrierung im Hintergrund. Advanced Custom Fields (ACF) geht einen Schritt weiter: Neben der Registrierung von Feldgruppen bringt die Pro-Version auch eine eigene Oberfläche für Beitragstypen mit, praktisch, wenn gleichzeitig komplexe Custom Fields verwaltet werden müssen. Pods eignet sich besonders, wenn relationale Daten oder eigene Datenbanktabellen ins Spiel kommen, etwa wenn ein Beitragstyp mit mehreren anderen verknüpft werden soll. Laut SmartWP bieten alle drei Lösungen unterschiedliche Trade-offs zwischen Einfachheit und Flexibilität, keine ist grundsätzlich die bessere Wahl.
Die Code-Variante bedeutet: Sie schreiben register_post_type() selbst, entweder direkt in der functions.php des Themes oder in einem eigenen kleinen Plugin. Genau hier liegt der entscheidende Unterschied für die Praxis: Inhalte, die im Theme registriert werden, verschwinden beim Theme-Wechsel spurlos aus dem Admin-Menü, auch wenn die Datenbankeinträge selbst erhalten bleiben. Ein Plugin dagegen bleibt unabhängig vom Theme aktiv.
- CPT UI oder Pods: schnelle Umsetzung ohne Entwickler, gut für kleinere Projekte.
- ACF Pro: sinnvoll, wenn ohnehin komplexe Feldgruppen verwaltet werden.
- Eigenes Plugin mit
register_post_type(): die robusteste Lösung für langlebige, wachsende Projekte.
Profi-Tipp: Registrieren Sie Ihre Custom Post Types grundsätzlich in einem eigenen kleinen Plugin, nie in der functions.php. Das kostet fünf Minuten mehr Aufwand, erspart Ihnen aber einen Datenverlust-Schreck beim nächsten Theme-Relaunch.
Wie funktioniert register_post_type() im Detail
Die Funktion register_post_type() ist laut der Entwicklerdokumentation von WordPress die zentrale Schnittstelle, um einen eigenen Beitragstyp im System bekanntzumachen. Zwei Regeln sind dabei nicht verhandelbar: Der Post-Type-Key darf maximal 20 Zeichen lang sein, muss klein geschrieben werden und sollte mit sanitize_key() bereinigt werden, bevor er registriert wird.
Registrierungen von Beitragstypen müssen an den
init-Hook gehängt werden. Ein zu früher oder zu später Aufruf führt dazu, dass WordPress den Beitragstyp entweder gar nicht kennt oder ihn im Backend fehlerhaft darstellt.
Die wichtigsten Argumente im $args-Array bestimmen, wie sich Ihr Beitragstyp im Alltag verhält:
- labels: Steuert alle Bezeichnungen im Admin-Menü, von „Neuen Eintrag erstellen“ bis zur Menübezeichnung selbst.
- public: Legt fest, ob der Beitragstyp im Frontend sichtbar ist und eine eigene URL bekommt.
- show_in_rest: Aktiviert den Block-Editor und macht den Beitragstyp über die REST-API abrufbar, laut SmartWP heute praktisch Pflicht für jeden neuen Beitragstyp.
- has_archive: Erzeugt eine automatische Archivseite, etwa unter
/portfolio/. - rewrite: Bestimmt die URL-Struktur, zum Beispiel einen eigenen Slug statt des Post-Type-Keys.
- supports: Definiert, welche Editor-Elemente verfügbar sind, Titel, Beitragsbild, Editor, Excerpt.
- taxonomies: Verknüpft bestehende oder neue Taxonomien direkt mit dem Beitragstyp.
- query_var: Steuert, wie der Beitragstyp in URL-Abfragen referenziert werden kann.
Ein kompaktes Beispiel, wie die Registrierung in der Praxis aussieht:
function acme_register_portfolio_cpt() {
register_post_type( 'acme_portfolio', array(
'labels' => array( 'name' => 'Projekte' ),
'public' => true,
'has_archive' => true,
'show_in_rest' => true,
'supports' => array( 'title', 'editor', 'thumbnail' ),
'rewrite' => array( 'slug' => 'projekte' ),
'taxonomies' => array( 'projekt_kategorie' ),
) );
}
add_action( 'init', 'acme_register_portfolio_cpt' );
Der Schlüssel acme_portfolio trägt hier bewusst ein Präfix, dazu später mehr im Abschnitt zu Best Practices. Wichtig ist auch: Beim Aktivieren eines Plugins sollten Sie laut TypeError einen register_activation_hook setzen, der die Rewrite-Regeln flusht, für Theme-basierte Registrierungen eignet sich stattdessen after_switch_theme.
Taxonomien und Custom Fields sauber mit CPTs verknüpfen
Eine eigene Taxonomie lohnt sich, sobald Sie Inhalte nach einem wiederkehrenden Merkmal filtern wollen, das nicht in die Standardkategorien passt, etwa „Projektart“ bei einem Portfolio oder „Veranstaltungsort“ bei Events. Für einfache Fälle reichen dagegen die vorhandenen Kategorien oder Schlagwörter, wenn Sie diese im taxonomies-Argument des Beitragstyps eintragen.
Ein häufiger Stolperstein: Das bloße Eintragen einer Taxonomie im taxonomies-Array reicht nicht immer aus, um die Integration vollständig zu garantieren. Laut Entwicklerdokumentation sollten Sie Taxonomien explizit mit register_taxonomy() registrieren, sonst drohen Probleme bei parse_query oder pre_get_posts, etwa wenn Archivseiten plötzlich falsche Beiträge anzeigen.
Für zusätzliche Felder haben Sie zwei Wege:
- add_meta_box(): Die native WordPress-Lösung, mehr Code, aber volle Kontrolle über Speicherung und Darstellung im Editor.
- Advanced Custom Fields: Schnellere Umsetzung über eine Oberfläche, besonders praktisch bei vielen unterschiedlichen Feldtypen.
Beide Wege funktionieren nur zuverlässig im Block-Editor, wenn show_in_rest auf true gesetzt ist. Ohne diese Einstellung bleibt der Beitragstyp auf den klassischen Editor beschränkt und taucht in der REST-API nicht auf, was spätestens bei einer Anbindung an ein Headless-Frontend oder eine App zum Problem wird. Wer den Beitragstyp später auch für Suchmaschinen sichtbar strukturieren will, sollte an dieser Stelle zusätzlich einen Blick auf technische SEO-Optimierung für WordPress werfen, denn Archivseiten und Taxonomie-URLs beeinflussen die Indexierung direkt.
Frontend-Darstellung: Templates, Permalinks und typische Fehler
WordPress sucht für Custom Post Types nach einem festen Muster von Template-Dateien. Für einzelne Einträge greift single-{post_type}.php, für die Archivübersicht archive-{post_type}.php. Fehlen diese Dateien, fällt WordPress auf single.php beziehungsweise archive.php zurück, was optisch oft nicht zum restlichen Design passt.
Die URL-Struktur steuern Sie über das rewrite-Argument: der slug-Parameter legt den Pfad fest, with_front bestimmt, ob ein vorangestellter Präfix aus den allgemeinen Permalink-Einstellungen übernommen wird, und feeds aktiviert einen eigenen RSS-Feed für den Beitragstyp. Das has_archive-Argument entscheidet, ob überhaupt eine automatische Übersichtsseite entsteht.
Der häufigste Fehler nach einer CPT-Registrierung: Die Archivseite oder einzelne Beiträge liefern einen 404-Fehler, obwohl der Code korrekt aussieht. Der Grund ist fast immer, dass die Rewrite-Regeln nicht neu generiert wurden.
- Gehen Sie im Backend zu Einstellungen → Permalinks und klicken Sie einfach auf Speichern, ohne etwas zu ändern.
- Alternativ per WP-CLI mit dem Befehl
wp rewrite flush, praktisch für automatisierte Deployments. - Bei Plugin-Aktivierung übernimmt ein
register_activation_hookdiesen Schritt automatisch.
Laut TypeError ist genau dieser Flush-Schritt die häufigste Fehlerquelle bei neu angelegten Beitragstypen, unabhängig davon, ob per Plugin oder Code registriert wurde. Eine zweite, oft unterschätzte Fehlerquelle: Wird der Beitragstyp im Theme statt in einem Plugin registriert, verschwindet er beim nächsten Theme-Wechsel komplett, samt Admin-Menüpunkt, auch wenn die Datensätze in der Datenbank erhalten bleiben.
Best Practices für Performance und Wartbarkeit
Ein Custom Post Type, der heute mit zehn Testeinträgen funktioniert, kann bei zehntausend Einträgen völlig anders reagieren. Ein paar Regeln verhindern spätere Überraschungen.
Prefixen Sie Ihre Post-Type-Keys grundsätzlich mit einem kurzen Projekt- oder Firmenkürzel, etwa acme_portfolio statt nur portfolio. Das reduziert Konflikte mit reservierten WordPress-Bezeichnungen oder mit Post-Types anderer aktiver Plugins erheblich. Vermeiden Sie außerdem hierarchical => true, sobald Sie mit mehreren tausend Einträgen rechnen, denn WordPress lädt für das Parent-Dropdown im Editor sämtliche IDs auf einmal, was den Admin-Bereich spürbar verlangsamt.
- Reservierte oder generische Slugs wie
post,pageoderattachmentniemals überschreiben. - Bei absehbar großen Datenmengen auf
hierarchical => trueverzichten. can_exportaktiviert lassen, damit Redakteure Inhalte regulär über die Backend-Exportfunktion sichern können.- Bei personenbezogenen Feldern (Namen, E-Mail-Adressen, Bewertungen mit Klarnamen) frühzeitig prüfen, ob eine DSGVO-konforme Speicherung und Löschroutine nötig ist.
Profi-Tipp: Testen Sie neue Beitragstypen immer zuerst auf einer Staging-Umgebung, besonders wenn Taxonomien oder Custom Fields mit im Spiel sind. Timing-Fehler beim init-Hook oder falsch registrierte Taxonomien erzeugen Query-Fehler, die im Livebetrieb deutlich schwerer zu debuggen sind als vorher auf einer Testkopie.
Praxiserfahrung aus Agenturprojekten von Werbeeinfach
In Agenturprojekten tauchen Custom Post Types regelmäßig in ähnlichen Konstellationen auf: ein Portfolio mit Projektreferenzen für Dienstleister, ein Produktkatalog außerhalb von WooCommerce für Unternehmen mit reinem Anfragegeschäft, oder eine Eventseite mit wiederkehrenden Terminen für Verbände und Bildungsanbieter. Die Branche spielt dabei zunehmend eine untergeordnete Rolle, entscheidend ist die Struktur der Inhalte, nicht das Gewerbe dahinter.
Der Workflow bei solchen Projekten folgt meist demselben Muster:
- Custom Post Type wird in einem eigenen, schlanken Plugin registriert, nie im Theme.
show_in_rest => truewird standardmäßig gesetzt, damit Block-Editor und spätere API-Anbindungen ohne Nacharbeit funktionieren.- Taxonomien werden vor der Verknüpfung mit dem Beitragstyp einzeln durchdacht, oft reicht eine einzige gut benannte Taxonomie statt drei überlappender.
- Nach jeder Änderung an Rewrite-Regeln wird der Permalink-Flush explizit in den Deployment-Prozess eingebaut, nicht dem Zufall überlassen.
- Jede Änderung läuft zuerst über eine Staging-Umgebung, bevor sie live geht.
Wer mehr über die technische Basis solcher Projekte wissen möchte, findet auf der Übersicht zu WordPress-Leistungen einen Einblick, welche Entwicklungsschritte typischerweise dazugehören, von der ersten Architekturentscheidung bis zur laufenden Betreuung.
Wie Werbeeinfach Sie bei der Umsetzung unterstützt
Custom Post Types richtig zu planen entscheidet oft schon vor der ersten Zeile Code darüber, ob eine Website später wartbar bleibt. Agenturen übernehmen oft diesen Teil für Sie: von der Architekturentscheidung, welcher Inhalt einen eigenen Beitragstyp braucht, über die saubere Registrierung in einem eigenen Plugin bis zur Anbindung an Taxonomien und den Block-Editor.
Der Ablauf ist bewusst schlank gehalten: Zuerst eine kurze Beratung, in der geklärt wird, welche Inhalte tatsächlich einen eigenen Beitragstyp rechtfertigen und welche besser über Taxonomien oder Custom Fields laufen. Danach die Entwicklung als eigenständiges, theme-unabhängiges Plugin, damit Ihre Inhalte auch einen Website-Relaunch überstehen. Anschließend ein Test auf einer Staging-Kopie, bevor irgendetwas live geschaltet wird, und im Anschluss laufende Wartung, damit Rewrite-Regeln, Sicherheitsupdates und neue WordPress-Versionen keine Überraschungen produzieren.
Wenn Sie einen Custom Post Type nicht nur einmal anlegen, sondern langfristig stabil betrieben haben wollen, lohnt sich ein Blick auf die individuelle Plugin-Entwicklung von Werbeeinfach. Dort erfahren Sie, wie eine saubere, portable Registrierung Ihres Beitragstyps aussieht, unabhängig davon, welches Theme Sie heute oder in drei Jahren einsetzen. Schreiben Sie einfach, welchen Inhaltstyp Sie abbilden wollen, den Rest klären wir gemeinsam im Erstgespräch.
Quellen
- Elementor — WordPress Custom Post Type
- register_post_type() — WordPress Developer Resources
- SmartWP — WordPress Custom Post Types Guide
- TypeError — register_post_type() Dokumentation
FAQ
Was sind Custom Post Types in WordPress genau?
Custom Post Types sind eigene Inhaltstypen neben Beiträgen und Seiten, mit eigenem Editor, eigener URL-Struktur und eigenem Archiv, gedacht für Inhalte wie Portfolios, Events oder Produkte.
Wie erstellt man einen Custom Post Type ohne Plugin?
Sie schreiben die Funktion register_post_type() mit den gewünschten Argumenten und hängen sie an den init-Hook, am besten in einem eigenen kleinen Plugin statt in der functions.php des Themes.
Wie legt man Kategorien für einen Custom Post Type fest?
Sie registrieren eine eigene Taxonomie mit register_taxonomy() und verknüpfen sie über das taxonomies-Argument mit dem Beitragstyp, alternativ lassen sich auch bestehende Kategorien oder Schlagwörter einbinden.
Wie ermittelt man den Post Type eines Beitrags in WordPress?
Innerhalb der WordPress-Schleife liefert die Funktion get_post_type() den Schlüssel des aktuellen Beitragstyps zurück, nützlich für bedingte Template-Logik oder individuelle Ausgaben.
Sollte ich CPT UI, ACF oder eigenen Code verwenden?
CPT UI eignet sich für schnelle, codefreie Umsetzungen, ACF Pro lohnt sich bei parallel benötigten komplexen Feldgruppen, und eigener Code in einem Plugin bietet die größte Kontrolle für langfristig gepflegte Projekte, wie sie Werbeeinfach in Kundenprojekten regelmäßig umsetzt.
