Eigene CSS-Anpassungen in WordPress sauber verwalten: Stile, Customizer und eigenes Plugin

Fast jede Unternehmenswebsite hat sie: ein paar Zeilen CSS, die den Abstand im Kopfbereich korrigieren, die Firmenfarbe in einen Hinweiskasten bringen oder ein störendes Element ausblenden. Solange diese Zeilen irgendwo funktionieren, fragt niemand, wo sie liegen. Das rächt sich beim nächsten Theme-Wechsel, bei einem Relaunch oder wenn ein neuer Dienstleister die Website übernimmt und nicht weiß, warum ein Button plötzlich grün ist. WordPress bietet heute mehrere Orte für eigenes CSS, und je nach Theme-Art sehen sie im Backend unterschiedlich aus. Diese Anleitung zeigt, wo Ihr CSS gerade liegt, welcher Ort für welchen Zweck taugt und wie Sie Ihre Anpassungen an einer Stelle bündeln, die Theme-Updates und Theme-Wechsel übersteht.

Voraussetzungen

• WordPress: Version 7.1 oder eine aktuelle Vorgängerversion; die Menüpfade in dieser Anleitung entsprechen dem deutschen Backend von WordPress 7.1.
• Theme: ein Block-Theme wie Twenty Twenty-Five oder ein klassisches Theme; die Unterschiede werden in den Schritten erklärt.
• Rolle: Administrator. Das Bearbeiten von CSS erfordert die Berechtigung edit_css, die WordPress nur Administratoren gibt, in einer Multisite nur Super-Administratoren.
• Dateizugriff per SFTP oder SSH für Schritt 4, alternativ der Upload eines Plugins als ZIP über das Backend.
• Backup: eine aktuelle Sicherung der Datenbank, bevor Sie CSS verschieben oder löschen, denn das CSS aus dem Backend liegt nur dort.
• Webspace: keine besonderen Anforderungen. Gewöhnliches Webhosting mit aktueller PHP-Version genügt.

Schritt 1: Bestandsaufnahme, wo Ihr CSS heute liegt

Eigenes CSS kann an bis zu fünf Stellen stecken: im Customizer unter Zusätzliches CSS, in den Stilen des Website-Editors, in einzelnen Blöcken als Klasse, in einem Child-Theme oder in einem Plugin für Code-Schnipsel. Die beiden Backend-Varianten landen in der Datenbank, jeweils gebunden an das aktive Theme. Mit WP-CLI sehen Sie beide auf einen Blick:

wp post list --post_type=custom_css,wp_global_styles --fields=ID,post_type,post_name

ID	post_type	post_name
14	wp_global_styles	wp-global-styles-twentytwentyfive
7	custom_css	twentytwentyfive

Der Beitragstyp custom_css enthält das CSS aus dem Customizer, sein Name ist der Ordnername des Themes. wp_global_styles enthält die Stile aus dem Website-Editor, darunter im Feld styles.css das dort eingetragene CSS. Den Inhalt zeigen Sie so an:

wp eval 'echo wp_get_custom_css();'
wp eval 'echo wp_get_global_stylesheet( array( "custom-css" ) );'

Ohne Kommandozeile finden Sie das CSS im Quelltext der Startseite: Klassische Themes geben es in einem Block <style id="wp-custom-css"> aus, Block-Themes hängen es an den Block global-styles-inline-css an. Prüfen Sie außerdem das Child-Theme auf eine style.css mit eigenen Regeln und die Liste der Plugins auf Code-Schnipsel-Plugins.

Verifizieren: Sie haben eine Liste aller Orte mit eigenem CSS und deren Inhalt als Textdatei gesichert.

Schritt 2: Die Speicherorte richtig einordnen

Jeder Ort hat eine Stärke und eine Grenze. Die Tabelle fasst zusammen, was wir im Test beobachtet haben:

Ort	Gespeichert	Nach Theme-Wechsel	Geeignet für
Customizer, Zusätzliches CSS	Datenbank, pro Theme	wirkt nicht mehr	kleine Korrekturen in klassischen Themes
Website-Editor, Stile, Zusätzliches CSS	Datenbank, pro Theme	wirkt nicht mehr	kleine Korrekturen in Block-Themes
Child-Theme, style.css	Datei im Theme-Ordner	wirkt nicht mehr	umfangreiche Theme-Anpassungen
Eigenes Plugin mit CSS-Datei	Datei im Plugin-Ordner	wirkt weiter	dauerhafte Firmen-Anpassungen

Wichtig ist die Spalte „Nach Theme-Wechsel“: Das CSS aus dem Backend wird nicht gelöscht, sondern bleibt beim alten Theme gespeichert. Aktivieren Sie das alte Theme wieder, ist es zurück. Das ist praktisch, führt aber dazu, dass nach einem Wechsel Formatierungen ohne Fehlermeldung fehlen.

Ein zweiter Punkt betrifft Block-Themes: Das Customizer-Menü „Anpassen“ zeigt WordPress bei Block-Themes nur noch, wenn ein Plugin es benötigt. Früher dort eingetragenes CSS gibt WordPress trotzdem weiter aus, und zwar vor dem CSS aus den Stilen. Wer von einem klassischen Theme auf ein Block-Theme gewechselt ist, hat so unter Umständen zwei Stellen mit CSS, von denen eine im Backend nicht mehr sichtbar ist. Die Abfrage aus Schritt 1 deckt das auf.

Verifizieren: Für jedes gefundene Stück CSS haben Sie entschieden, ob es zum Theme gehört (bleibt, wo es ist) oder zur Firma (wandert in Schritt 4 in ein eigenes Plugin).

Schritt 3: CSS im Website-Editor pflegen

Bei Block-Themes öffnen Sie Design → Editor → Stile. Oben im Stile-Bereich öffnet das Menü mit den drei Punkten („Mehr“) den Eintrag Zusätzliches CSS. Hier gilt das CSS für die gesamte Website. Speichern Sie mit dem Button oben rechts.

Für einzelne Blocktypen gibt es einen gezielteren Weg: Unter Stile → Blöcke wählen Sie zum Beispiel „Absatz“ und finden unter Erweitert ein eigenes Feld für Zusätzliches CSS, das nur für diesen Blocktyp gilt. Das hält Regeln übersichtlich, weil sie dort stehen, wo sie wirken.

Für einzelne Blöcke auf einer Seite schreiben Sie kein CSS in den Block. Wählen Sie den Block aus, öffnen Sie in der Seitenleiste Erweitert und tragen Sie unter Zusätzliche CSS-Klasse(n) einen Namen ein, etwa firma-hinweis. Die Gestaltung dieser Klasse steht dann einmal zentral:

.firma-hinweis {
	border-left: 4px solid #0F8B8D;
	padding: 1rem;
}

Jede Änderung an den Stilen legt WordPress als Revision ab. Über die Revisionen im Stile-Bereich kehren Sie zu einem früheren Stand zurück, wenn eine Regel das Layout zerlegt hat. Bei klassischen Themes nutzen Sie Design → Anpassen → Zusätzliches CSS; der Customizer zeigt Änderungen in einer Vorschau, bevor Sie sie veröffentlichen.

WordPress prüft das CSS beim Speichern. Die Zeichenfolge </style> lehnt es mit der Meldung Das CSS darf „</style>“ nicht enthalten. ab, damit sich kein HTML in die Seite einschleusen lässt.

Verifizieren: Öffnen Sie eine Seite im Frontend, markieren Sie das Element mit Rechtsklick und „Untersuchen“ und prüfen Sie in den Entwicklerwerkzeugen des Browsers, dass Ihre Regel angewendet wird.

Schritt 4: Dauerhaftes CSS in ein eigenes Plugin verlagern

Regeln, die zu Ihrem Unternehmen gehören, etwa Hinweiskästen, Tabellen in der Firmenfarbe oder eine Anpassung für ein Formular-Plugin, sollen jeden Theme-Wechsel überstehen. Dafür genügt ein kleines Plugin, das eine CSS-Datei lädt. Es ist schnell angelegt und gehört Ihnen, nicht dem Theme-Hersteller. Legen Sie den Ordner wp-content/plugins/firma-css/ mit zwei Dateien an. Die erste heißt firma-css.php:

<?php
/**
 * Plugin Name: Firma CSS
 * Description: Eigene CSS-Anpassungen der Firmenwebsite, unabhängig vom Theme.
 * Version: 1.0.0
 */
defined( 'ABSPATH' ) || exit;

add_action( 'wp_enqueue_scripts', function () {
	$datei = plugin_dir_path( __FILE__ ) . 'firma.css';
	wp_enqueue_style(
		'firma-css',
		plugins_url( 'firma.css', __FILE__ ),
		array( 'global-styles' ),
		filemtime( $datei )
	);
}, 20 );

Die zweite ist firma.css mit Ihren Regeln. Drei Details sind absichtlich so gewählt. wp_enqueue_style ist der vorgesehene Weg, Stylesheets einzubinden, damit WordPress und Caching-Plugins die Datei kennen. Die Abhängigkeit von global-styles sorgt dafür, dass Ihre Datei nach den Theme-Stilen geladen wird und diese überschreiben kann. Und filemtime hängt das Änderungsdatum als Version an die Adresse, sodass Browser nach jeder Änderung die neue Datei laden statt einer zwischengespeicherten.

Aktivieren Sie das Plugin unter Plugins → Installierte Plugins oder per WP-CLI:

php -l wp-content/plugins/firma-css/firma-css.php
wp plugin activate firma-css

Verschieben Sie danach die betreffenden Regeln aus dem Backend in firma.css und löschen Sie sie dort erst, wenn das Frontend mit der Datei korrekt aussieht. Ein Plugin für Code-Schnipsel erfüllt denselben Zweck, speichert aber wieder in der Datenbank und ist ein weiteres Plugin, das Updates braucht.

Verifizieren: Im Quelltext der Startseite steht eine Zeile mit id='firma-css-css' und der Adresse Ihrer Datei mit ?ver=, und die Datei selbst liefert beim Aufruf im Browser den Status 200.

Schritt 5: Dokumentieren und bei Updates prüfen

Eigenes CSS hängt an Klassen und Strukturen des Themes und der Plugins. Ändert ein Update die Klassennamen, greifen Ihre Regeln ins Leere, ohne dass WordPress eine Warnung zeigt. Halten Sie deshalb in der Website-Dokumentation fest, wo welches CSS liegt und wozu es dient; ein Kommentar über jedem Regelblock in firma.css hilft dem nächsten Bearbeiter. Nach Theme-Updates lohnt ein kurzer Blick auf die Seiten, deren Gestaltung vom eigenen CSS abhängt.

Damit wird aus einer einmaligen Anpassung eine laufende Aufgabe: Updates einspielen, danach die betroffenen Seiten prüfen, vorher sichern. Wer diese Routine nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt die Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung und legt wöchentliche Backups auf externem Speicher ab.

Verifizieren: Ihre Website-Dokumentation nennt alle Orte mit eigenem CSS, und in der Datenbank steht nur noch CSS, das bewusst beim Theme bleiben soll.

Typische Fehler

• Nach dem Theme-Wechsel fehlen Formatierungen: Das CSS aus Customizer oder Stilen gehört zum alten Theme. Kopieren Sie es mit dem Befehl aus Schritt 1, solange das alte Theme noch installiert ist, und übernehmen Sie es in das eigene Plugin.
• Menü „Zusätzliches CSS“ fehlt: In wp-config.php ist DISALLOW_UNFILTERED_HTML auf true gesetzt. Dann fehlt auch Administratoren die Berechtigung edit_css. Das ist eine bewusste Härtung; nutzen Sie in diesem Fall den Weg über das eigene Plugin.
• Regel greift nicht: Eine spezifischere Regel des Themes gewinnt. Die Entwicklerwerkzeuge des Browsers zeigen durchgestrichene Eigenschaften; machen Sie den Selektor genauer, statt !important zu stapeln.
• Alte Datei im Browser: Ohne Versionsparameter hält der Browser die CSS-Datei zwischengespeichert. Der Parameter aus filemtime behebt das; leeren Sie zusätzlich den Page-Cache.
• Doppeltes CSS nach Umstieg auf ein Block-Theme: Altes Customizer-CSS wirkt weiter, ist aber im Menü nicht mehr zu sehen. Die Abfrage aus Schritt 1 zeigt es.

Häufige Fragen

Wird das CSS beim Theme-Update gelöscht?

Nein. Zusätzliches CSS aus dem Backend liegt in der Datenbank und bleibt bei Updates erhalten. Verloren geht nur, was Sie direkt in die Dateien des Eltern-Themes schreiben; dafür gibt es das Child-Theme.

Brauche ich ein Child-Theme nur für ein paar Zeilen CSS?

Nein. Für einige Regeln reicht das Zusätzliche CSS im Backend oder das eigene Plugin. Ein Child-Theme lohnt sich, wenn Sie Vorlagen oder PHP-Funktionen des Themes ändern.

Macht zusätzliches CSS die Website langsamer?

Einige Kilobyte fallen nicht ins Gewicht. Eine eigene Datei kann der Browser zwischenspeichern, eingebettetes CSS wird mit jeder Seite neu übertragen. Bei wenigen Zeilen ist beides unkritisch.

Dürfen Redakteure CSS bearbeiten?

Standardmäßig nicht, weil die Berechtigung edit_css Administratoren vorbehalten ist. Redakteure können aber vorhandene Klassen über „Zusätzliche CSS-Klasse(n)“ an Blöcke vergeben.

Testumfang

Auf einer Testinstallation mit WordPress 7.1.2 zeigte sich, dass Customizer-CSS und Stile-CSS am Theme hängen, während das kleine Plugin nach einem Wechsel weiterläuft. Auffällig war, dass altes Customizer-CSS im Block-Theme weiter ausgegeben wird, obwohl es im Menü nicht mehr auftaucht. Page-Builder und Multisite-Netzwerke haben wir nicht geprüft. Nutzen Sie so etwas, testen Sie den Umzug Ihres CSS zuerst auf einer Kopie der Website.

Fazit

Eigenes CSS wird dann zum Problem, wenn niemand weiß, wo es liegt. Trennen Sie Theme-Korrekturen, die ruhig im Backend bleiben dürfen, von Firmen-Anpassungen, die in ein eigenes kleines Plugin gehören, und schreiben Sie auf, was wo steht. Mit einer Bestandsaufnahme vor jedem Theme-Wechsel und einem Blick auf die betroffenen Seiten nach Updates bleibt das Erscheinungsbild stabil. Wenn Sie die Updates rund um Theme und Plugins lieber abgeben, übernimmt das die WordPress-Wartung von Marcel Schönfelder mit persönlicher Betreuung.

Weiterführende Anleitungen und Quellen

• Theme-Updates ohne Verlust eigener Anpassungen: Child-Theme richtig nutzen
• Block-Theme anpassen mit theme.json
• Website-Dokumentation für WordPress
• WordPress Developer Reference: wp_enqueue_style()
• Plugin Handbook: Header Requirements
• WordPress-Dokumentation: Styles Overview