WordPress Child-Theme: Warum es Pflicht ist, keine Option

Von Manuel Hack, ihp media · Aktualisiert am 16. Juni 2026

Sie haben das Theme Ihres Kunden nach Wunsch angepasst, eigene CSS-Regeln geschrieben, vielleicht eine functions.php erweitert. Dann kommt das nächste Theme-Update, und alles ist weg. Das ist kein Fehler, das ist das erwartete Verhalten von WordPress. Ein Child-Theme ist die sauberste, offiziell unterstützte Lösung.

Das Problem: Theme-Updates löschen Ihre Arbeit

WordPress-Themes bestehen aus Dateien: PHP-Templates, eine style.css, JavaScript, oft eine functions.php. Wenn der Theme-Hersteller eine neue Version veröffentlicht, ersetzt der Update-Prozess diese Dateien durch die aktuelle Version. Was vorher drinstand, ist danach weg.

Das trifft jeden, der eigenen Code direkt ins Theme geschrieben hat. Einen angepassten header.php, eigene CSS-Regeln am Ende der style.css, eine erweiterte functions.php. Alles überschrieben. Wer Updates deshalb aufschiebt, um Anpassungen zu erhalten, tauscht ein kleineres Problem gegen ein größeres: Veraltete Themes sind eines der häufigsten Einfallstore für Angreifer. Dazu mehr im Ratgeber zu WordPress-Updates und warum Aufschieben riskanter ist als Aktualisieren.

Ein Child-Theme löst diesen Konflikt. Es erbt das gesamte Erscheinungsbild und alle Funktionen des Parent-Themes, hält aber alle eigenen Anpassungen in einem separaten Ordner. Das Parent-Theme kann gefahrlos aktualisiert werden. Die eigenen Änderungen bleiben unangetastet.

Aufbau eines Child-Themes

Ein Child-Theme ist kein Plug-in und kein Sonderkonstrukt, sondern ein ganz normales WordPress-Theme mit einer besonderen Eigenschaft: Es teilt WordPress mit, welches Theme es als Basis nutzen soll.

Drei Teile sind nötig:

Das Child-Theme liegt als eigener Ordner unter wp-content/themes/, typischerweise mit dem Suffix -child, also zum Beispiel twentytwentyfour-child. WordPress erkennt es als eigenständiges Theme und aktiviert es. Die restlichen Dateien des Parent-Themes werden weiterhin verwendet, solange das Child-Theme sie nicht selbst mitbringt.

Schritt-für-Schritt-Anleitung

Das Folgende setzt voraus, dass ein Parent-Theme aktiv ist. Der Ordnername des Parent-Themes ist z.B. twentytwentyfour.

Schritt 1: Ordner anlegen

Im Verzeichnis wp-content/themes/ einen neuen Ordner anlegen, zum Beispiel twentytwentyfour-child. Der Name ist frei wählbar, sollte aber eindeutig auf das Parent-Theme verweisen.

Schritt 2: style.css erstellen

Im neuen Ordner eine Datei style.css mit diesem Mindest-Header anlegen:

/*
Theme Name:   Twenty Twenty-Four Child
Description:  Child-Theme für Twenty Twenty-Four
Template:     twentytwentyfour
Version:      1.0.0
*/

Das Feld Template: ist entscheidend. Es enthält den genauen Ordnernamen des Parent-Themes, ohne Schrägstrich, ohne Leerzeichen am Ende. Steht hier ein falscher Wert, zeigt WordPress den Fehler „Stylesheet missing“ beim Aktivieren. Eigene CSS-Regeln kommen direkt unterhalb dieses Headers in dieselbe Datei.

Schritt 3: functions.php erstellen und Parent-Styles laden

Eine Datei functions.php im Child-Theme-Ordner anlegen. Der richtige Weg, die Parent-Styles zu laden, ist per wp_enqueue_scripts-Hook:

<?php
add_action( 'wp_enqueue_scripts', 'ihp_child_enqueue_styles' );
function ihp_child_enqueue_styles() {
    $parent_style = 'parent-style';
    wp_enqueue_style(
        $parent_style,
        get_template_directory_uri() . '/style.css'
    );
    wp_enqueue_style(
        'child-style',
        get_stylesheet_directory_uri() . '/style.css',
        array( $parent_style ),
        wp_get_theme()->get( 'Version' )
    );
}

Der verbreitete ältere Weg mit @import url("../parent-theme/style.css"); in der Child-CSS funktioniert zwar noch, gilt aber als veraltet. Er erzeugt einen zusätzlichen HTTP-Request, lädt die Styles sequenziell statt parallel und hat keinen Einfluss auf die Ladereihenfolge im WordPress-Asset-System. Wer Templates und Hooks sauber voneinander trennen will, liest dazu die offizielle Dokumentation zu wp_enqueue_scripts auf developer.wordpress.org.

Schritt 4: Child-Theme aktivieren

Im WordPress-Backend unter Design > Themes das Child-Theme auswählen und aktivieren. Danach die Website im Browser prüfen: Das Design sollte identisch aussehen wie mit dem Parent-Theme. Sieht es anders aus, fehlt der Parent-Style-Enqueue oder der Template:-Header ist falsch.

Schritt 5: Anpassungen einpflegen

Eigene CSS-Regeln kommen in die style.css des Child-Themes, nach dem Header-Block. Eigene PHP-Hooks kommen in die functions.php. Soll ein einzelnes Template des Parent-Themes geändert werden, z.B. die single.php, wird diese Datei in den Child-Theme-Ordner kopiert und dort bearbeitet. WordPress greift beim Laden immer zuerst auf das Child-Theme zurück.

Aus der Praxis: In einem Projekt war die Suchseite des Parent-Themes schlecht strukturiert und produzierte mehrere H1-Überschriften. Die Lösung war eine eigene search.php im Child-Theme, die lediglich die Überschriften-Hierarchie korrigierte. Das Parent-Theme blieb vollständig unangetastet. Beim nächsten Update des Themes war die Korrektur weiterhin aktiv.

Wer regelmäßig zwischen Produktiv- und Testumgebung arbeitet, sollte das Child-Theme per Versionskontrolle verwalten. Wie eine sinnvolle Testumgebung aussieht, zeigt der Ratgeber zur Staging-Umgebung.

/*
Theme Name:   Mein Child-Theme
Description:  Child-Theme fuer [Name des Parent-Themes]
Template:     [ordnername-des-parent-themes]
Version:      1.0.0
Author:       [Ihr Name]
*/

/* Eigene CSS-Regeln ab hier */

<?php
/**
 * Laedt die Styles des Parent-Themes und des Child-Themes.
 * Template-Feld in style.css muss dem Ordnernamen des Parent-Themes entsprechen.
 */
add_action( 'wp_enqueue_scripts', 'ihp_child_enqueue_styles' );
function ihp_child_enqueue_styles() {
    $parent_style = 'parent-style';
    wp_enqueue_style(
        $parent_style,
        get_template_directory_uri() . '/style.css'
    );
    wp_enqueue_style(
        'child-style',
        get_stylesheet_directory_uri() . '/style.css',
        array( $parent_style ),
        wp_get_theme()->get( 'Version' )
    );
}

// Eigene PHP-Hooks und Funktionen ab hier

Wann ein Child-Theme nicht nötig oder sinnvoll ist

Ein Child-Theme ist kein Allheilmittel und in einigen Konstellationen schlicht nicht der richtige Weg.

Block-Themes, wie sie WordPress seit Version 5.9 kennt, arbeiten grundlegend anders als klassische PHP-Themes. Das Site-Editor-Prinzip speichert alle Anpassungen am Theme, an Headern, Footern, Schriften und Farben, in der Datenbank als Post-Einträge, nicht als Dateien. Ein Theme-Update überschreibt diese Datenbankeinträge nicht. Ein Child-Theme löst hier ein Problem, das gar nicht besteht. Wer sich einen Überblick über die verschiedenen Ansätze verschaffen will, findet ihn im Vergleich Divi, Elementor oder Gutenberg.

Auch für reine PHP-Schnipsel, die nichts mit Templates zu tun haben, ist ein Code-Snippets-Plugin oft der bessere Weg. Es macht Snippets einzeln aktivier- und deaktivierbar, verhindert Syntaxfehler mit White-Screen-Folge im Produktivsystem und braucht kein Child-Theme als Umweg. Das Plugin ist kein Ersatz für ein Child-Theme, wenn Template-Overrides gebraucht werden, aber ein sinnvoller Begleiter für alles, was in die functions.php käme. Wie man generell zu viele Plugins vermeidet, zeigt der Ratgeber zu WordPress Plugin-Bloat.

Sonderfall Divi und andere Page-Builder

Divi ist ein klassisches PHP-Theme, kein Block-Theme. Das bedeutet: Wer direkt in den Divi-Themendateien Änderungen macht, verliert sie beim nächsten Divi-Update genau wie bei jedem anderen klassischen Theme. Hier gilt dasselbe wie überall.

Allerdings sind die meisten Anpassungen in Divi keine Dateiänderungen. Farben, Abstände, Schriften und Modul-Optionen werden in der Datenbank gespeichert, in den Divi Theme Options und per Custom CSS im Customizer. Diese Einstellungen überleben Updates unabhängig davon, ob ein Child-Theme aktiv ist oder nicht.

Ein Child-Theme für Divi ist vor allem sinnvoll für:

• Eigene PHP-Hooks, z.B. einen benutzerdefinierten wp_head-Hook oder einen Filter auf Divi-Module
• Template-Overrides, etwa eine angepasste single.php für Beitragsdetailseiten
• Größere CSS-Mengen, die besser in einer eigenen Datei liegen als im Customizer

Wer in Divi ausschließlich über das Theme Options Panel und den Customizer arbeitet, braucht kein Child-Theme. Wer eigene PHP-Funktionen einbinden oder Templates überschreiben will, kommt ohne eines nicht aus. Die Faustregel: Liegt die Änderung in einer Datei, gehört sie ins Child-Theme. Liegt sie in einem Formularfeld im Backend, ist sie bereits updateresistent.

Ein Theme-Wechsel, der manchmal als Alternative zum Child-Theme-Aufwand gesehen wird, ist ein erheblich größerer Eingriff. Was dabei zu beachten ist, erklärt der Ratgeber WordPress Theme wechseln ohne Datenverlust.

Sofort-Checkliste

• Ist das aktive Theme ein klassisches PHP-Theme? Dann ein Child-Theme anlegen, bevor Anpassungen gemacht werden.
• Enthält die style.css des Child-Themes einen korrekten Template:-Header mit dem genauen Ordnernamen des Parent-Themes?
• Werden die Parent-Styles per wp_enqueue_scripts geladen, nicht per @import?
• Liegt kein eigener Code direkt in den Dateien des Parent-Themes?
• Liegen Template-Overrides im Child-Theme-Ordner, nicht als Direktänderung im Parent?
• Ist das Child-Theme in der WordPress-Themeverwaltung als aktives Theme eingestellt?
• Bei Block-Theme: Anpassungen über den Site-Editor gemacht, kein Child-Theme nötig?
• Wurde nach einem Theme-Update geprüft, ob alle Child-Theme-Anpassungen noch wirksam sind?

Häufige Fragen

Was passiert, wenn ich kein Child-Theme verwende und das Parent-Theme aktualisiere?

Alle Dateien des Parent-Themes werden durch die neue Version ersetzt. Änderungen, die direkt in diesen Dateien standen, ob in der style.css, der functions.php oder in Template-Dateien, sind danach nicht mehr vorhanden. WordPress zeigt keine Warnung, der Update-Prozess löscht die Änderungen kommentarlos.

Reicht es, nur eine style.css im Child-Theme zu haben, oder muss ich auch eine functions.php anlegen?

Die style.css mit dem korrekten Template:-Header ist das einzige technisch notwendige Minimum. Ohne functions.php lädt WordPress aber die Styles des Parent-Themes möglicherweise nicht korrekt, je nach Theme. Die beste Praxis ist, immer eine functions.php mitzulegen, die die Parent-Styles per wp_enqueue_scripts explizit einbindet. Das ist eine Datei mit zehn Zeilen und macht das Verhalten vorhersehbar.

Kann ich ein Child-Theme nachträglich anlegen, wenn ich Änderungen schon direkt im Parent-Theme gemacht habe?

Ja, aber die Reihenfolge ist wichtig. Zuerst alle vorhandenen Anpassungen aus den Parent-Dateien dokumentieren und kopieren, dann das Child-Theme anlegen, dann die Anpassungen ins Child-Theme übertragen, erst dann das Child-Theme aktivieren. Wer zuerst aktiviert und danach sucht, riskiert, die Ursprungsversion der Parent-Dateien nicht mehr zu kennen. Wenn Updates bereits gelaufen sind und Anpassungen überschrieben wurden, hilft nur ein Backup aus der Zeit vor dem Update. Wie ein verlässliches Backup-System aussieht, zeigt der Ratgeber zu WordPress-Wartung.

Wie viele Ebenen von Child-Themes sind möglich?

WordPress unterstützt offiziell nur eine Ebene: ein Child-Theme erbt von einem Parent-Theme. Ein Kind-eines-Kind-Themes, also ein Child-Child-Theme, wird nicht unterstützt. Wer eine zweite Anpassungsebene benötigt, löst das über mehrere Template-Dateien im einen Child-Theme oder durch Hooks, nicht durch verschachtelte Theme-Vererbung.

Verliere ich etwas, wenn ich ein Child-Theme statt des Parent-Themes aktiviere?

Nein, solange das Child-Theme korrekt eingerichtet ist. Es erbt alle Templates, Styles und Funktionen des Parent-Themes. Das Erscheinungsbild ist identisch, und sämtliche Theme-Optionen bleiben erhalten. Einzig: Theme-Updates müssen weiterhin am Parent-Theme eingespielt werden, nicht am Child-Theme. Das Child-Theme selbst braucht kein Update, es hat ja keine eigene Versionierung im Update-Kanal.

Funktioniert ein Child-Theme auch mit einem Multisite-Netzwerk?

Ja. In einem WordPress-Multisite-Netzwerk können Child-Themes genau wie normale Themes netzwerkweit aktiviert oder einzelnen Sites zugewiesen werden. Das Netzwerk-Admin muss das Child-Theme zuerst für das Netzwerk freischalten. Der Aufbau und die Funktionsweise sind identisch mit einer Einzelinstallation.

Gibt es ein Plugin, das ein Child-Theme automatisch erstellt?

Ja. Das Plugin Child Theme Configurator aus dem offiziellen WordPress-Verzeichnis erstellt ein korrekt aufgebautes Child-Theme mit wenigen Klicks und kopiert optional vorhandene Styles aus dem Parent. Das ist eine bequeme Lösung für den Einmalfall. Wer regelmäßig Child-Themes anlegt oder eigene Strukturvorgaben hat, baut sie besser manuell, so wie oben beschrieben. Die manuelle Variante erfordert drei Dateien und ist in zehn Minuten erledigt.

Muss das Child-Theme denselben Ordnernamen haben wie das Parent-Theme plus „-child“?

Nein. Das Suffix -child ist eine Konvention, keine Pflicht. Der Ordnername kann frei gewählt werden, solange er eindeutig ist und keine Sonderzeichen enthält. WordPress identifiziert das Parent-Theme ausschließlich über das Template:-Feld in der style.css, nicht über den Ordnernamen des Child-Themes.