WordPress: CSS-Snippets mit Versionierung und Rollback verwalten

Je mehr CSS sich auf einer WordPress-Seite ansammelt, desto unübersichtlicher wird ein einziges großes Feld unter „Zusätzliches CSS“. Genau darum ging es im ursprünglichen Gemini-Chat: Gesucht war eine Lösung für mehrere getrennte CSS-Schnipsel, möglichst mit Versionsverwaltung und Rollback.

Die ursprüngliche Unterhaltung ist dabei interessant, weil mehrere Lösungen durchprobiert und wieder verworfen wurden: SiteOrigin CSS, Simple Custom CSS and JS, WPCode und schließlich die Frage nach einer kostenlosen Variante mit Versionshistorie.

1. Erst klären, was wirklich benötigt wird

Es gibt drei unterschiedliche Anforderungen, die oft unter „CSS verwalten“ zusammengeworfen werden:

  • Ein globales CSS-Feld: Alles steht in einer Datei beziehungsweise einem Editor.
  • Mehrere getrennte Snippets: Header, Footer, Buttons und Mobil-CSS können einzeln aktiviert und bearbeitet werden.
  • Versionierung: Alte Stände bleiben erhalten und lassen sich vergleichen oder wiederherstellen.

Nicht jedes Plugin bietet alle drei Punkte.

2. WordPress „Zusätzliches CSS“ ist besser als sein Ruf

WordPress speichert das CSS aus dem Customizer nicht einfach als Datei im Theme. Der Core verwendet dafür den internen Post-Type custom_css. Die aktuelle WordPress-Entwicklerdokumentation zeigt ausdrücklich, dass dieser Post-Type Revisionen unterstützt.

Das ist ein wichtiger Vorteil: Änderungen am zusätzlichen CSS können intern versioniert werden und bleiben außerdem beim Theme-Update erhalten.

3. Nachteil: Es bleibt ein großes CSS-Feld

Genau das war im ursprünglichen Chat der Knackpunkt. Wenn du 30 unabhängige Anpassungen hast, kann ein einziges CSS-Feld zwar technisch funktionieren, wird aber organisatorisch schnell unangenehm.

Du kannst das mit Kommentaren strukturieren:

/* =====================
   HEADER
   ===================== */

/* =====================
   STARTSEITE
   ===================== */

/* =====================
   MOBILE
   ===================== */

Für wenige Änderungen reicht das oft völlig. Für viele getrennte Projekte sind echte Snippets angenehmer.

4. SiteOrigin CSS: guter visueller Editor, aber kein klassischer Snippet-Manager

Im ursprünglichen Chat wurde SiteOrigin CSS ausprobiert. Das Plugin eignet sich gut, wenn du CSS visuell bearbeiten und Selektoren leichter finden möchtest. Der entscheidende Einwand war aber richtig: Es ist nicht primär darauf ausgelegt, Dutzende getrennte CSS-Snippet-Boxen wie eigenständige Einträge zu verwalten.

Wenn dein Hauptziel „einzelne CSS-Bausteine separat benennen, aktivieren und pflegen“ lautet, ist ein Snippet-orientiertes Plugin passender.

5. Simple Custom CSS and JS

Das Plugin Simple Custom CSS and JS ist weiterhin aktiv gepflegt. WordPress.org listet es 2026 mit Hunderttausenden aktiven Installationen und der Möglichkeit, beliebig viele eigene Codes anzulegen.

Damit kannst du zum Beispiel getrennte Einträge anlegen:

  • Header-Abstände
  • Buttons
  • GeneratePress-Mobile-Menü
  • Kontaktseite
  • Blogkarten
  • Footer

Das ist organisatorisch wesentlich übersichtlicher als ein monolithischer CSS-Block.

6. Versionierung nicht einfach voraussetzen

Hier korrigiere ich bewusst eine Unsicherheit aus dem ursprünglichen Gemini-Chat. Dort wurde zeitweise behauptet, die kostenlose Version habe automatisch eine komfortable WordPress-Revisionsoberfläche. Das sollte man nicht pauschal versprechen.

Die aktuelle WordPress.org-Beschreibung bestätigt mehrere getrennte Custom Codes, nennt aber eine für den Nutzer sichtbare vollständige Revisions-/Rollback-Funktion nicht als zentrale Free-Funktion. Wenn Versionierung für dich zwingend ist, solltest du sie in der konkret installierten Version testen oder zusätzlich extern sichern.

7. So testest du, ob dein Snippet-Plugin Revisionen wirklich anbietet

  1. Ein Test-Snippet anlegen.
  2. Version A speichern.
  3. Code sichtbar verändern und Version B speichern.
  4. Editor erneut öffnen.
  5. Nach „Revisionen“, „History“, „Versions“ oder einem Vergleichsbereich suchen.
  6. Prüfen, ob Version A tatsächlich wiederherstellbar ist.

Nur weil ein Plugin Code als Custom Post Type speichert, heißt das nicht automatisch, dass es die WordPress-Revisionsoberfläche aktiviert oder bequem zugänglich macht.

8. WPCode und andere Snippet-Manager

WPCode und ähnliche Plugins eignen sich gut, wenn du neben CSS auch JavaScript, HTML oder PHP-Snippets verwalten möchtest. Sie bieten meist bessere Organisation, Aktivieren/Deaktivieren und Bedingungen als das reine Customizer-CSS.

Für PHP-Snippets ist ein spezialisiertes Plugin besonders sinnvoll, weil ein Syntaxfehler in einer direkt bearbeiteten functions.php die Website lahmlegen kann.

9. Für reines CSS ist weniger oft mehr

Wenn du ausschließlich CSS verwaltest, brauchst du nicht zwingend einen großen Allzweck-Code-Manager. Ein leichter CSS-Manager kann genügen. WordPress.org führt weiterhin mehrere spezialisierte Plugins für Custom CSS.

Die Auswahl sollte nach Workflow erfolgen, nicht nach Funktionsmenge.

10. Der sicherste Rollback: zusätzlich extern versionieren

Wenn dir Wiederherstellbarkeit wirklich wichtig ist, würde ich mich nicht ausschließlich auf eine Plugin-interne Historie verlassen. Sehr robust ist eine zweite Ebene:

  • CSS-Snippets regelmäßig exportieren,
  • in Dateien speichern,
  • mit Datum oder Git versionieren.

Dann bist du auch geschützt, wenn das Plugin selbst beschädigt wird, deaktiviert werden muss oder seine Datenbanktabellen verloren gehen.

11. Einfache Dateiversionierung ohne Git

Auch ohne Entwicklerwerkzeuge kannst du eine klare Struktur verwenden:

header-v01.css
header-v02.css
header-v03.css

Oder besser mit Datum:

header-2026-09-12.css

Das ist nicht elegant wie Git, aber immer noch besser als „final-neu-jetzt-wirklich.css“.

12. Git für größere Websites

Wenn du regelmäßig CSS und andere Website-Dateien entwickelst, ist Git die sauberste Versionsverwaltung. Jede Änderung kann dokumentiert, verglichen und zurückgesetzt werden.

Das muss nicht bedeuten, dass die Live-Seite direkt aus Git deployt wird. Schon ein lokales Repository mit den wichtigen Snippets schafft eine zuverlässige Historie.

13. Snippets nach Funktion benennen

Gute Namen sparen später viel Zeit:

  • gp-header-spacing
  • gb-card-grid-mobile
  • contact-buttons
  • footer-colors

Schlechte Namen sind „css1“, „test“, „neu“ oder „final“.

14. Jede Änderung kommentieren

Schreibe direkt in den Code, warum eine Regel existiert:

/* Verhindert Umbruch der Telefonnummer im Header */
.header-phone {
  white-space: nowrap;
}

Nach einem halben Jahr ist die Begründung oft wertvoller als der Code selbst.

15. Mobile Regeln zusammenhalten

Wenn ein Snippet eine bestimmte Komponente betrifft, sollten Desktop- und Mobilregeln möglichst gemeinsam darin liegen. So findest du später alles an einer Stelle.

.service-card {
  padding: 30px;
}

@media (max-width: 768px) {
  .service-card {
    padding: 20px;
  }
}

16. Vor größeren Änderungen kopieren

Wenn dein Plugin keine zuverlässige Historie bietet, kopiere den bestehenden Code vor einer größeren Änderung in eine lokale Datei. Das dauert Sekunden und kann viel Arbeit sparen.

17. Nicht gleichzeitig an fünf Stellen CSS pflegen

Ein häufiger WordPress-Fehler ist CSS-Verteilung auf:

  • Customizer
  • Child-Theme
  • Snippet-Plugin
  • GenerateBlocks
  • einzelne Seitenblöcke

Dann ist später kaum noch nachvollziehbar, welche Regel gewinnt. Lege einen klaren Standard fest, wo welches CSS hingehört.

18. Mein sinnvoller Workflow

Für eine GeneratePress-/GenerateBlocks-Seite würde ich es so aufteilen:

  • Globale Designwerte: GeneratePress/GenerateBlocks Global Styles.
  • Kleine globale CSS-Ergänzungen: Zusätzliches CSS.
  • Viele voneinander unabhängige Sonderregeln: Snippet-Manager mit getrennten Einträgen.
  • Wichtige langfristige Historie: zusätzlich externe Dateisicherung oder Git.

Fazit

Wenn du CSS-Schnipsel getrennt verwalten und bei Fehlern zurückrollen möchtest, solltest du Organisation und Versionierung getrennt betrachten. WordPress „Zusätzliches CSS“ unterstützt intern Revisionen, ist aber nur ein großes Feld. Simple Custom CSS and JS bietet viele getrennte Code-Einträge, doch eine komfortable Free-Revisionsfunktion sollte in der konkret verwendeten Version geprüft und nicht einfach vorausgesetzt werden. Für wichtige Projekte ist eine zusätzliche externe Versionssicherung die zuverlässigste Lösung.

Aktuell geprüft

Die Aussagen zu WordPress Custom CSS und Revisionen wurden mit der aktuellen WordPress-Core-Dokumentation abgeglichen. Die aktuelle WordPress.org-Seite von Simple Custom CSS and JS bestätigt die Verwaltung beliebig vieler Codes und die fortlaufende Pflege des Plugins.