Was sind WordPress Custom Post Types?

Ein WordPress Custom Post Type (CPT) ist ein Inhaltstyp jenseits der fünf eingebauten (post, page, attachment, revision, nav_menu_item). CPTs speichern strukturierte Inhalte wie Produkte, Veranstaltungen, Immobilien, Rezepte, Testimonials oder Portfolio-Einträge mit eigenem Admin-Menü, Edit Screen, Taxonomien, URL-Struktur und Template-Hierarchie. Custom Post Types kamen in WordPress 2.9 (Dezember 2009) und wurden mit register_post_type() in WordPress 3.0 (Juni 2010) zur Standardmethode für strukturierte Inhalte. Ein CPT wird per PHP über register_post_type( $slug, $args ) am init-Hook registriert oder visuell über Plugins wie Custom Post Type UI (über 700.000 aktive Installationen), Pods (über 100.000) und Meta Box (über 400.000). Seit WordPress 5.0 (Dezember 2018) können CPTs den Block-Editor nutzen, wenn show_in_rest auf true gesetzt ist, was sie zugleich am REST-API-Endpunkt /wp-json/wp/v2/<slug> verfügbar macht. Die fünf Standardtypen bleiben: post, page, attachment (Medien), revision und nav_menu_item. WooCommerce allein registriert das product-CPT plus shop_order, shop_coupon, product_variation und zehn weitere. The Events Calendar nutzt tribe_events. ACF Pro kann seit Version 6.1 (März 2023) CPTs über sein UI registrieren. Custom Post Types sind 2025 weiter das Rückgrat jeder Nicht-Blog-WordPress-Seite.

Wann brauche ich einen Custom Post Type?

Ein CPT lohnt sich, wenn Inhalte weder zu Blogbeiträgen noch zu statischen Seiten passen. Typische Fälle:

• E-Commerce-Produkte: WooCommerce registriert product, shop_order, shop_coupon als CPTs. Jeder hat Preis, Bestand, SKU und Varianten.
• Veranstaltungen: Events Calendar nutzt tribe_events mit Startdatum, Enddatum, Venue und Organisator-Taxonomien.
• Immobilien: ein Property-CPT mit Zimmern, Bädern, Preis und Standort-Taxonomie.
• Portfolio: ein Project-CPT mit Kunde, Jahr, Tech-Stack und Beitragsbild.
• Testimonials, Teammitglieder, FAQs: kleine CPTs ohne Single-Templates, oft via Shortcode oder Block ausgegeben.
• Rezepte: Titel, Zutaten, Anleitung, Zubereitungszeit, Garzeit, Portionen, meist mit Schema.org-Recipe-Markup.
• Stellenanzeigen: ein Job-CPT mit Standort, Abteilung, Gehaltsspanne und Bewerbungsformular.

Seiten oder Beiträge könnten all das technisch aufnehmen, aber ein CPT bringt eigenes Admin-Menü, eigene Spalten in der Listenansicht, eigene Capabilities für Editor-Rollen und eine logische URL-Struktur (/produkte/ statt /blog/<produkt>).

So registrierst du einen Custom Post Type

In einer Plugin-Datei (bevorzugt) oder in der functions.php des Themes:

add_action( 'init', 'mysite_register_product_cpt' );

function mysite_register_product_cpt() {
    $labels = array(
        'name'                  => 'Produkte',
        'singular_name'         => 'Produkt',
        'menu_name'             => 'Produkte',
        'add_new'               => 'Neu hinzufügen',
        'add_new_item'          => 'Neues Produkt',
        'edit_item'             => 'Produkt bearbeiten',
        'all_items'             => 'Alle Produkte',
        'search_items'          => 'Produkte durchsuchen',
    );

    $args = array(
        'labels'             => $labels,
        'public'             => true,
        'show_in_rest'       => true,
        'has_archive'        => true,
        'rewrite'            => array( 'slug' => 'produkte', 'with_front' => false ),
        'supports'           => array( 'title', 'editor', 'thumbnail', 'excerpt', 'custom-fields' ),
        'menu_icon'          => 'dashicons-cart',
        'menu_position'      => 20,
        'capability_type'    => 'post',
        'show_in_nav_menus'  => true,
    );

    register_post_type( 'product', $args );
}

Wichtige Argumente

Plugin gegen Theme-Registrierung

CPTs immer in einem Plugin registrieren, nie im Theme. Wenn register_post_type() in der functions.php liegt und der Nutzer das Theme wechselt, verschwindet das CPT aus dem Admin-Menü und die Inhalte werden unzugänglich (die Datensätze in der Datenbank bleiben mit dem alten post_type, sind aber nicht mehr über das Admin editierbar). Die Community spricht von plugin territory vs. theme territory: Inhaltsstruktur gehört in Plugins, Präsentation gehört in Themes.

Template-Hierarchie für CPTs

WordPress sucht für einen CPT mit Slug product nach diesen Template-Dateien:

• Einzelseite: single-product-<slug>.php, single-product.php, single.php, singular.php, index.php.
• Archiv: archive-product.php, archive.php, index.php.
• Taxonomie-Archiv: taxonomy-<tax>-<term>.php, taxonomy-<tax>.php, taxonomy.php, archive.php.

Block-Themes nutzen HTML-Templates in templates/single-product.html und templates/archive-product.html.

CPTs und die REST API

Mit show_in_rest => true ist der CPT unter /wp-json/wp/v2/<rest_base> verfügbar. Standard-rest_base ist der Post-Type-Slug. Headless-Frontends nutzen diesen Endpunkt. Custom-Meta-Felder werden über register_post_meta() mit show_in_rest => true exponiert. Ohne REST fällt der Editor auf den Classic Editor zurück.

CPTs und der Block-Editor

Damit ein CPT den Block-Editor (Gutenberg) nutzt, muss show_in_rest => true gesetzt sein und supports muss editor enthalten. Optional kann template in den args ein Default-Block-Layout für neue Beiträge setzen und template_lock verhindert, dass Nutzer Blöcke entfernen oder verschieben.

Plugins, die CPTs ohne Code registrieren

• Custom Post Type UI (CPT UI): über 700.000 aktive Installationen. Visueller Editor für CPTs und Taxonomien. Kostenlos.
• ACF Pro: seit Version 6.1 (März 2023) registriert CPTs und Taxonomien im eigenen UI. Über 2 Millionen Seiten nutzen ACF.
• Pods Framework: über 100.000 Installationen. Komplettes Content Modeling mit CPTs, Custom Taxonomies und Custom Tables.
• Meta Box: CPT-Registrierung plus Advanced Fields und Beziehungen.
• Toolset Types: kommerziell, beliebt für CPTs plus Frontend-Formulare.

Performance und Skalierung

• Alle CPT-Inhalte landen in derselben wp_posts-Tabelle wie Beiträge und Seiten. Bis ca. 100.000 Zeilen ist die Performance identisch, danach wird der Index auf post_type relevant.
• Nicht mehr als 20 bis 30 CPTs pro Seite registrieren. Jeder bringt Admin-Menü, Rewrite Rules und Capability Checks.
• Rewrite Rules bei Plugin-Aktivierung einmal mit flush_rewrite_rules() flushen, niemals bei jedem Request.
• Bei hunderttausenden Einträgen sollte eine eigene Tabelle mit $wpdb in Betracht gezogen werden. Beispiel: WooCommerce hat Bestellungen in 8.0 (August 2023) auf High Performance Order Storage (HPOS) umgestellt.

Häufige Fehler

• Falscher Hook. Immer init, nicht plugins_loaded oder after_setup_theme.
• Vergessenes show_in_rest. Ohne taucht der CPT nicht im Block-Editor und nicht in der REST API auf.
• Rewrite Rules nicht geflusht. Der Aufruf /produkte/ liefert 404 bis Rules geflusht sind.
• CPT-Registrierung im Theme statt im Plugin.
• Slug-Konflikt mit Seite. Ein CPT mit Slug produkte kollidiert mit einer Seite namens Produkte unter derselben URL.
• capability_type auf eigenen Wert ohne entsprechende Capabilities zu registrieren. Editoren können den CPT dann nicht bearbeiten.

Was InspectWP prüft

InspectWP erkennt Custom Post Types im gerenderten HTML und durchsucht REST-API-Endpunkte, wenn sie verfügbar sind. Der Report identifiziert beliebte CPT-Anbieter (WooCommerce, Events Calendar, ACF) und meldet öffentlich zugängliche CPT-Archive.