Ein WordPress Child-Theme ist ein Theme, das Styling und Funktionalität eines anderen Themes, dem sogenannten Parent-Theme, erbt. Wenn du ein Child-Theme aktivierst, sagst du WordPress, das Parent für alles zu verwenden, außer für Dateien, die das Child überschreibt. Der ganze Sinn dahinter: wenn der Parent-Theme-Entwickler ein Update veröffentlicht (was regelmäßig passiert, oft mit Sicherheitsfixes), überleben deine Anpassungen unberührt. Ohne Child-Theme wird jede Anpassung, die du am Theme machst, beim nächsten Update überschrieben. Mit Child-Theme liegen deine Änderungen in einem eigenen Ordner, den Updates nicht anfassen.
Warum brauche ich 2026 ein Child-Theme?
Drei Gründe, die sich in 15 Jahren nicht geändert haben:
- Parent-Theme-Updates überstehen. Theme-Entwickler liefern monatlich oder häufiger Updates. Jedes Update überschreibt jede Datei im Parent-Theme-Ordner. Wenn du
header.phpoderstyle.cssdirekt editiert hast, sind deine Änderungen weg. Ein Child-Theme hat einen eigenen Ordner, den Updates nie anfassen. - Nur gezielte Dateien überschreiben. Ein Child-Theme kann selektiv jede Datei vom Parent ersetzen. Eigene
footer.php? Einfach ins Child-Theme legen. Gleiche footer.php wie im Parent, aber mit einem CSS-Tweak? Dann einfach das CSS in diestyle.cssdes Childs schreiben und footer.php in Ruhe lassen. - Eigenes PHP ergänzen, ohne das Theme zu forken. Die
functions.phpdes Child-Themes wird parallel zur Parent-functions.php geladen. Filter, Custom Post Types, entfernte Actions oder beliebiges PHP, ohne Parent-Code anzufassen.
Der Ansatz "ich editiere einfach das Parent" bricht beim ersten Auto-Update des Themes, was auf einer typischen WordPress-Seite binnen Wochen passiert. Nimm ein Child-Theme.
Wann brauche ich KEIN Child-Theme?
Drei Szenarien, in denen ein Child-Theme das falsche Werkzeug ist:
- Wenn du nur über den Customizer oder Site-Editor anpasst. Farbänderungen, Schriftarten und ähnliche Einstellungen über Design, Anpassen (Classic) oder den Site-Editor (Block-Themes) werden in der Datenbank gespeichert, nicht in Theme-Dateien. Sie überleben Updates auch ohne Child-Theme.
- Wenn du nur Custom-CSS ergänzt. WordPress hat ein eingebautes "Zusätzliches CSS"-Panel im Customizer. Kleine CSS-Anpassungen liegen dort und überdauern Updates. Ein Child-Theme ist Overkill für zwei CSS-Regeln.
- Wenn du ein Block-Theme (FSE) nutzt und nur Templates anpasst. Full-Site-Editing-Themes speichern Template-Anpassungen in der Datenbank, erreichbar über Design, Editor. Der Bedarf an Child-Themes ist deutlich kleiner. Block-Themes profitieren weiterhin für eigenes PHP oder theme.json-Overrides von einem Child-Theme, aber der typische Fall "ich will das Logo verschieben und den Footer-Text ändern" braucht keines mehr.
Wenn du PHP-Dateien, Template-Dateien editierst oder mehr als ein paar CSS-Zeilen ergänzen willst, brauchst du ein Child-Theme. Für alles andere ist 2026 der Customizer oder Site-Editor genug.
Methode 1: Child-Theme manuell installieren (5 Minuten)
Das minimale Child-Theme sind zwei Dateien in einem Ordner. Schritt für Schritt:
Schritt 1: Child-Theme-Ordner anlegen
Per SFTP (oder dem Datei-Manager im Hosting-Panel) verbinden und zu /wp-content/themes/ navigieren. Du siehst Ordner für jedes installierte Theme, etwa twentytwentyfour/ oder astra/. Daneben einen neuen Ordner anlegen. Namenskonvention: Parent-Name plus -child. Wenn dein Parent-Theme Astra ist, heißt der Ordner astra-child.
Schritt 2: style.css mit dem benötigten Header anlegen
Im neuen astra-child-Ordner eine Datei style.css anlegen. In einem Texteditor öffnen und diesen Header-Kommentarblock einfügen:
/*
Theme Name: Astra Child
Theme URI: https://deineseite.de
Description: Child-Theme für Astra
Author: Dein Name
Author URI: https://deineseite.de
Template: astra
Version: 1.0.0
Text Domain: astra-child
*/Die Zeile Template ist die einzige, die exakt passen muss: sie muss der Ordnername des Parent-Themes sein (Groß-/Kleinschreibung beachten). Die anderen Zeilen können beliebigen Inhalt haben; sie tauchen unter Design, Themes auf.
Schritt 3: functions.php anlegen, um Parent-Styles zu enqueue-en
Im selben astra-child-Ordner functions.php anlegen:
<?php
add_action('wp_enqueue_scripts', function () {
wp_enqueue_style('parent-style', get_template_directory_uri() . '/style.css');
wp_enqueue_style('child-style', get_stylesheet_uri(), ['parent-style']);
});Das sorgt dafür, dass das Stylesheet des Parent-Themes zuerst geladen wird, danach das des Childs, sodass deine Anpassungen das Parent überschreiben. Ohne das ist die style.css des Child-Themes leer und die Seite wird ungestylt geladen. Viele alte Tutorials empfehlen weiterhin @import url('../astra/style.css'); in der style.css des Childs. Den @import-Ansatz 2026 nicht mehr verwenden. Er ist langsam (erzwingt einen zweiten HTTP-Request, bevor CSS geparst wird), wird vom WordPress-Codex nicht mehr empfohlen, und der Enqueue-Ansatz oben ist der moderne Standard.
Schritt 4: Child-Theme aktivieren
Im WordPress-Admin zu Design, Themes gehen. Du siehst dein neues Child-Theme in der Liste (eventuell mit Platzhalter-Vorschau). Auf Aktivieren klicken. Deine Seite sollte genauso aussehen wie vorher — gleiche Schriften, gleiches Layout, gleiche Farben — weil das Child alles vom Parent erbt.
Sieht die Seite ungestylt aus, stimmt das Enqueue in der functions.php nicht. Prüfen, dass die Template:-Zeile in der style.css exakt dem Parent-Ordnernamen entspricht.
Methode 2: Ein Child-Theme-Plugin nutzen (ohne Coding)
Für Nutzer, die nicht an SFTP wollen, automatisieren Plugins die Erstellung. Zwei zuverlässige Optionen 2026:
- Child Theme Configurator. Kostenlos, aktiv gepflegt, die beliebteste Option. In zwei Klicks installiert, erzeugt das Child-Theme aus jedem aktiven Parent, erlaubt das Kopieren von Parent-Dateien ins Child zum Bearbeiten über die Admin-UI. Die pragmatische Wahl für die meisten Nutzer.
- Generate Child Theme. Neueres Plugin mit Fokus auf Block-Themes. Sinnvoll, wenn du ein Full-Site-Editing-Theme wie Twenty Twenty-Four nutzt, wo die Patterns anders sind.
Plugin-Schritte:
- Plugin installieren und aktivieren.
- Zu Werkzeuge, Child Themes (Child Theme Configurator) oder dem Äquivalent gehen.
- Parent-Theme auswählen.
- Auf "Neues Child-Theme erstellen" klicken.
- Das Plugin erzeugt Ordner, style.css und functions.php korrekt. Zu Design, Themes und aktivieren.
Das Plugin kann nach der Erstellung des Child-Themes deaktiviert werden. Das Child-Theme selbst hängt nicht vom Plugin ab.
Wie passe ich das Child-Theme nach der Aktivierung an?
Drei Kategorien von Anpassungen:
CSS-Anpassungen
CSS-Regeln unterhalb des Header-Kommentars in die style.css des Childs schreiben. Das Child-CSS lädt nach dem Parent-CSS, deine Regeln überschreiben also, außer das Parent nutzt !important oder höher spezifische Selektoren.
/* In astra-child/style.css */
.site-title {
font-family: Georgia, serif;
color: #2c3e50;
}
.entry-content a {
text-decoration: underline;
}Template-Overrides
Um eine Template-Datei anzupassen (Header, Footer, Single-Post-Layout etc.), die Datei vom Parent-Theme ins Child-Theme an demselben Pfad kopieren. WordPress nutzt dann die Child-Version statt der Parent-Version.
Beispiel: footer.php anpassen:
wp-content/themes/astra/footer.phpnachwp-content/themes/astra-child/footer.phpkopieren.- Die Kopie im Child bearbeiten.
- Speichern. Der nächste Seitenaufruf nutzt deine Version.
Bei Block-Themes ist es anders: statt PHP-Template-Dateien nutzen sie HTML-Dateien in einem templates/-Ordner und theme.json für globale Styles. Das Override-Mechanismus ist gleich; die Datei vom Parent ins Child unter demselben relativen Pfad kopieren.
PHP-Anpassungen
Filter, Actions oder eigenen Code in die functions.php des Childs einfügen — niemals ins Parent. Die functions.php des Childs lädt vor der des Parents, also kann es Filter registrieren, die das Parent später abfragt.
// In astra-child/functions.php
// WordPress-Login-Logo-URL ändern
add_filter('login_headerurl', function () {
return home_url();
});
// WordPress-Emojis deaktivieren
remove_action('wp_head', 'print_emoji_detection_script', 7);
remove_action('wp_print_styles', 'print_emoji_styles');Wie übernehme ich meine Customizer-Einstellungen ins Child-Theme?
Häufiger Schmerzpunkt: du hast unter dem Parent-Theme Farben, Schriften und Widgets im Customizer eingerichtet. Beim Aktivieren des Child-Themes wirken sie zurückgesetzt.
Die Wahrheit: Customizer-Einstellungen werden pro Theme gespeichert. Jedes Theme (Parent und Child sind für WordPress unterschiedliche "Themes") hat seine eigenen Einstellungen. So bewahrst du sie:
- Unter dem Parent-Theme zu Design, Anpassen gehen, Zahnrad-Icon und "Export" (manche Themes bieten das an, nicht alle). Oder ein Plugin wie Customizer Export/Import nutzen.
- Child-Theme aktivieren.
- Zurück in den Customizer und die Datei importieren.
Wenn dein Theme keinen Customizer-Export unterstützt, ist die Alternative, dieselben Einstellungen unter dem Child-Theme manuell zu konfigurieren. Für Widgets bietet WordPress 4.2+ einen "Widget Importer & Exporter"-Workflow über das Werkzeuge-Menü oder über Plugins wie Widget Importer Exporter.
Was ist mit Block-Themes (Full Site Editing)?
Bei Block-Themes (Twenty Twenty-Two und neuer sowie moderne FSE-Themes) ist die Child-Theme-Struktur leicht anders. Das Zwei-Dateien-Minimum wird zu:
- style.css mit demselben Header-Block, aber
Template: parent-theme-ordner, das auf das Parent-Block-Theme verweist. - theme.json im Child-Ordner. Diese Datei überschreibt die theme.json des Parents. Nur die Einstellungen aufnehmen, die geändert werden sollen; für alles andere werden die Werte des Parents genutzt.
Templates lassen sich ebenfalls überschreiben, indem man Parent-HTML-Template-Dateien aus templates/ und parts/ ins Child-Theme am selben Pfad kopiert.
Der Full-Site-Editor im WordPress-Admin liest Child-Theme-Overrides und erlaubt visuelle Template-Anpassungen. Anpassungen im Editor werden in der Datenbank gespeichert und überleben Theme-Updates; das Child-Theme brauchst du nur für Dinge, die du nicht über den Editor konfigurieren kannst (etwa eigenes PHP in der functions.php).
Häufige Fehler beim Installieren eines Child-Themes
- Falscher
Template:-Name in style.css. Stimmt der Wert nicht exakt mit dem Parent-Theme-Ordnernamen überein (Groß-/Kleinschreibung beachten), behandelt WordPress das Child als kaputtes Theme. Der Ordnername zählt, nicht der Anzeigename. - Vergessenes
<?phpoben in der functions.php. Die Datei wird still als Text behandelt, Parent-Styles werden nicht enqueued, und die Seite lädt ungestylt. PHP-Dateien immer mit<?phpbeginnen. - @import in style.css zum Laden von Parent-CSS. Funktioniert, aber langsam und nicht mehr empfohlen. Den wp_enqueue_style-Ansatz in der functions.php nutzen.
- Jede Parent-Datei "zur Sicherheit" ins Child kopieren. Nicht tun. Nur Dateien kopieren, die du tatsächlich überschreiben willst. Dateien, die im Child existieren und im Parent ein Pendant haben, werden vom Child genutzt; Dateien, die nur im Parent liegen, kommen weiter vom Parent. Massen-Kopieren hebelt den Wartungsvorteil eines Child-Themes aus.
- Das Child-Theme auf einer Live-Seite ohne Staging bearbeiten. Eine schlechte Zeile in der functions.php produziert einen White Screen. Für nicht triviale PHP-Änderungen ein Staging-Setup nutzen oder zumindest ein Code-Snippet-Plugin, das PHP-Fehler vor dem Speichern abfängt.
- Den Child-Theme-Ordner mit Leerzeichen benennen. Bei Kleinbuchstaben und Bindestrichen bleiben. Leerzeichen und Sonderzeichen brechen den
Template:-Verweis auf manchen Servern. - Parent-Theme wechseln, ohne das Child zu löschen. Ein Child-Theme referenziert sein Parent über den Namen. Wechselst du das Parent-Theme, ohne das Child anzupassen, ist das Child kaputt. Entweder das Child löschen oder die
Template:-Zeile aktualisieren.
Wie aktualisiere ich ein Parent-Theme, ohne das Child zu brechen?
Genau dafür ist ein Child-Theme da: Parent-Updates sollen es nicht brechen. Drei Szenarien:
- Normale Updates. Im Admin auf "Aktualisieren" klicken. Der Parent-Theme-Ordner wird ersetzt; der Child-Ordner bleibt unangetastet. Prüfen, dass die Seite weiterhin sauber aussieht.
- Major-Version-Updates (1.x auf 2.x). Manchmal ändern sich Templates deutlich. Wenn dein Child-Theme Templates überschreibt, referenziert das Override eventuell Funktionen oder Hooks, die nicht mehr existieren. Den Changelog des Parent-Themes vor Major-Updates lesen. Auf Staging testen.
- Parent-Theme aufgegeben. Bekommt das Parent keine Updates mehr (Sicherheitsfixes), steckt dein Child auf einem verwundbaren Theme fest. Die Migration geht zu einem gepflegten Parent-Theme. Das Child-Theme macht das einfacher, weil das meiste deines Custom-CSS und PHP wiederverwendbar ist; nur Template-Overrides müssen neu gemacht werden.
Wo finde ich, welche Theme-Dateien ich überschreiben kann?
Die WordPress-Template-Hierarchie dokumentiert, welche Datei für welchen Inhaltstyp geladen wird. Häufige:
header.php— Anfang jeder Seitefooter.php— Ende jeder Seitesingle.php— Einzel-Beitrags-Layoutpage.php— Einzel-Seiten-Layoutarchive.php— Kategorie-/Schlagwort-/Autor-Archivefunctions.php— PHP-Anpassungenstyle.css— CSS
Bei Block-Themes liegen die Pendants in templates/ als .html-Dateien und in theme.json für das Styling.
Was InspectWP prüft
InspectWP erkennt anhand des Template:-Felds in der style.css, ob ein Theme ein Child-Theme ist. Der WordPress-Abschnitt des Reports listet Parent- und Child-Theme mit Versionen und letztem Update-Datum. Eine Seite, die ein Child-Theme nutzt, dessen Parent seit über einem Jahr nicht aktualisiert wurde, wird markiert, weil das Parent wahrscheinlich offene Sicherheitslücken hat. Eine Seite mit veraltetem Child-Theme auf aktuellem Parent ist nur informativ; meist bedeutet das, dass die Person, die die Seite gebaut hat, das Child nicht mehr pflegt, das Parent aber weiter Sicherheitsfixes vom Parent-Maintainer bekommt. Praktische Empfehlung: beides aktualisiert halten, die Anpassungen des Child-Themes im style.css-Header dokumentieren und Child-Themes auch auf Managed-Hosting-Setups gegenüber direkten Bearbeitungen bevorzugen, wo automatische Theme-Updates üblich sind.