WordPress CSS Änderungen werden nicht angezeigt: Ursachen und Lösungen

Du hast eine CSS-Regel in WordPress angepasst, gespeichert und die Seite anschließend neu geladen – trotzdem ist keine Veränderung sichtbar? Wenn WordPress CSS Änderungen nicht angezeigt werden, liegt das häufig nicht an der CSS-Syntax selbst. Caches, falsche Selektoren, überschreibende Regeln, ein nicht geladenes Stylesheet oder Änderungen an der falschen Datei können dafür verantwortlich sein. In diesem Leitfaden gehst Du die Ursachen systematisch durch und findest eine möglichst updatefähige Lösung.

Passende WordPress Hilfe zum Thema

Warum WordPress CSS Änderungen nicht angezeigt werden

CSS wird nicht direkt von WordPress gestaltet, sondern vom Browser interpretiert. WordPress, das Theme und verschiedene Plugins liefern HTML und verknüpfte Stylesheets aus. Der Browser liest diese Regeln und entscheidet anhand von Selektoren, Spezifität, Reihenfolge und gegebenenfalls !important, welche Darstellung gilt.

Wenn eine Anpassung scheinbar wirkungslos bleibt, muss daher an mehreren Stellen geprüft werden: Ist die geänderte Datei tatsächlich aktiv? Wird die neue Version vom Browser geladen? Trifft der Selektor auf das gewünschte Element? Wird die Regel von einer anderen Regel überstimmt? Oder erzeugt ein Plugin die betreffende Ausgabe nachträglich?

Eine vorschnelle Änderung an mehreren Dateien erschwert die Fehlersuche. Besser ist ein klarer Ablauf: Cache ausschließen, Element untersuchen, aktive CSS-Regel prüfen, Ursache eingrenzen und erst danach die dauerhafte Anpassung speichern.

Die häufigsten Ursachen im Überblick

Beobachtung	Wahrscheinliche Ursache	Erster Prüfschritt
Im privaten Browserfenster ist die Änderung sichtbar	Browser- oder Seiten-Cache	Cache leeren und Cache-Busting prüfen
Die Regel erscheint nicht in den Entwicklertools	Stylesheet wird nicht geladen oder falsche Datei bearbeitet	Quelltext und Netzwerk-Tab kontrollieren
Die Regel ist sichtbar, aber durchgestrichen	Andere Regel mit höherer Priorität	Spezifität, Reihenfolge und Inline-Stile vergleichen
Nur eingeloggte Nutzer sehen die Änderung	Cache oder optimierte Auslieferung	Ausgeloggten Zustand und Cache-Ausnahmen prüfen
Die Änderung verschwindet nach einem Update	Anpassung in einer updategefährdeten Datei	Customizer, Child Theme oder eigenes Stylesheet verwenden

Schritt 1: Browser- und WordPress-Cache leeren

Die einfachste Ursache ist ein alter Cache. Dein Browser kann CSS-Dateien lokal gespeichert haben. Zusätzlich können WordPress-Plugins für Seiten- und Objekt-Caching, Optimierung oder die Zusammenfassung von CSS sorgen. Auch der Webserver oder ein vorgeschaltetes Content Delivery Network kann eine ältere Version ausliefern.

Browser-Cache ausschließen

Lade die betroffene Seite zunächst mit einer erzwungenen Aktualisierung. Je nach Betriebssystem und Browser funktioniert das beispielsweise mit Strg + F5 oder einer vergleichbaren Tastenkombination. Noch aussagekräftiger ist ein Test in einem privaten Fenster oder in einem zweiten Browser. Bedenke dabei, dass ein privates Fenster nicht automatisch jeden serverseitigen Cache umgeht.

Wenn Du die Entwicklertools geöffnet hast, kannst Du im Netzwerk-Bereich die Option für deaktiviertes Caching während der geöffneten Entwicklertools verwenden. Diese Einstellung wirkt normalerweise nur für diesen Prüfzeitraum und ersetzt kein korrektes Cache-Konzept.

WordPress- und Server-Cache prüfen

Leere anschließend den Cache des verwendeten Cache- oder Optimierungsplugins. Die Bezeichnungen unterscheiden sich je nach Plugin. Suche nach Funktionen wie „Cache leeren“, „Alle Caches löschen“ oder „CSS regenerieren“. Wenn CSS-Dateien zusammengeführt, minimiert oder statisch zwischengespeichert werden, muss die optimierte Ausgabe ebenfalls neu erzeugt werden.

Bei einem Hosting mit serverseitigem Cache oder einer CDN-Auslieferung kann zusätzlich eine Invalidierung erforderlich sein. Prüfe nach einer Änderung immer die ausgeloggte Ansicht, weil eingeloggte Administratoren oft eine andere Cache-Ausnahme erhalten als normale Besucher.

Schritt 2: Mit den Entwicklertools die aktive Regel finden

Achte im Styles-Bereich darauf, ob Deine Regel aktiv, ungültig oder durchgestrichen ist. Die Dateiangabe neben der Deklaration hilft Dir außerdem zu erkennen, aus welchem Stylesheet die wirksame Regel stammt.

Die Entwicklertools des Browsers sind das wichtigste Werkzeug, wenn CSS-Änderungen nicht sichtbar sind. Öffne die betreffende Seite, klicke mit der rechten Maustaste auf das betroffene Element und wähle „Untersuchen“ oder „Element untersuchen“. Im HTML-Baum wird nun genau das Element markiert, dessen Darstellung Du ändern möchtest.

Im Bereich „Styles“ richtig lesen

Im Bereich für Styles siehst Du alle Regeln, die auf das Element passen. Aktive Eigenschaften werden normal dargestellt. Durchgestrichene Eigenschaften wurden zwar gefunden, aber durch eine Regel mit höherer Priorität oder durch eine später geladene Regel überstimmt. So erkennst Du, ob Dein CSS grundsätzlich greift.

Prüfe außerdem, aus welcher Datei eine Regel stammt. Neben der CSS-Deklaration zeigt der Browser normalerweise den Dateinamen und die Zeilennummer an. Findest Du Deine neue Regel dort nicht, bearbeitest Du möglicherweise eine falsche Datei, sie wird nicht geladen oder die Änderung wird nicht gespeichert.

Das berechnete Ergebnis kontrollieren

Der Bereich „Computed“ oder „Berechnet“ zeigt die am Ende verwendeten Werte. Das ist besonders hilfreich, wenn mehrere Regeln für dieselbe Eigenschaft existieren. Bei display, position, width, margin oder color kannst Du nachvollziehen, welche Deklaration tatsächlich gewinnt.

Untersuche auch die Eltern- und Kindelemente. Manchmal wird nicht das sichtbare Element selbst verändert, sondern ein innerer Container, ein Pseudo-Element wie ::before oder ::after oder ein Element, das nur bei einem bestimmten Zustand erscheint. Eine Regel für den falschen Knoten bleibt syntaktisch korrekt und zeigt trotzdem keine Wirkung.

Schritt 3: CSS-Selektoren und HTML-Struktur überprüfen

Ein häufiger Fehler ist ein Selektor, der nicht zur tatsächlichen HTML-Struktur passt. Angenommen, Du verwendest .button a, aber die Klasse button sitzt direkt auf dem Link. Dann trifft die Regel nicht auf das gewünschte Element zu. Ebenso können sich Klassen durch Theme-, Block- oder Plugin-Updates ändern.

Kopiere den relevanten Klassennamen aus dem inspizierten HTML und vergleiche ihn Zeichen für Zeichen mit Deinem CSS. Achte auf Bindestriche, Unterstriche, Groß- und Kleinschreibung sowie Leerzeichen. Ein Leerzeichen zwischen zwei Selektoren bedeutet eine Verschachtelung, während mehrere Klassen ohne Leerzeichen dasselbe Element meinen.

Typische Selektorfehler

• Die Klasse wird mit einem Punkt zu wenig oder zu viel geschrieben.
• Ein Element liegt nicht innerhalb des angenommenen Elterncontainers.
• Der Selektor bezieht sich auf einen Desktop-Container, während mobil ein anderer Block ausgegeben wird.
• Ein Gutenberg-Block besitzt zusätzliche Klassen, die im CSS nicht berücksichtigt wurden.
• Ein Plugin erzeugt das Element erst per JavaScript nach dem initialen Laden.

Beginne beim Testen mit einem möglichst einfachen, eindeutig passenden Selektor. Wenn beispielsweise die Klasse produktbox direkt am gewünschten Container sitzt, kann .produktbox { ... } zunächst besser zur Fehlersuche geeignet sein als eine lange Kette aus mehreren Vorfahren. Ist die Ursache gefunden, kannst Du den Selektor für die dauerhafte Verwendung so präzise wie nötig, aber nicht unnötig kompliziert formulieren.

Schritt 4: Spezifität und Reihenfolge von CSS-Regeln verstehen

CSS arbeitet nicht nach dem Prinzip „die letzte Änderung gewinnt“ allein. Entscheidend ist zunächst, wie spezifisch ein Selektor ist. Ein ID-Selektor ist in der Regel stärker als eine Klasse, eine Klasse stärker als ein reiner Elementselektor. Inline-Styles besitzen eine besondere Priorität. Erst bei vergleichbarer Spezifität spielt die Reihenfolge eine entscheidende Rolle.

Wenn Deine Regel im Browser durchgestrichen ist, vergleiche sie mit der aktiven Regel. Ein Theme kann zum Beispiel .header .navigation a verwenden, während Du nur a definierst. Deine Regel ist dann möglicherweise zu allgemein. Eine moderate Präzisierung wie .header .navigation a kann ausreichen.

!important sollte nicht die erste Lösung sein. Es kann eine bestehende Kaskade erschweren und spätere Anpassungen unübersichtlich machen. Verwende es nur begründet, etwa wenn ein Drittanbieter-Plugin unvermeidbar Inline-Stile setzt und keine sauberere Erweiterungsmöglichkeit vorhanden ist. Dokumentiere eine solche Ausnahme am besten direkt im CSS.

Schritt 5: Prüfen, wo die CSS-Anpassung gespeichert wurde

WordPress bietet mehrere Stellen für zusätzliches CSS. Welche davon sinnvoll ist, hängt vom Theme und der Art der Änderung ab.

Ort	Geeignet für	Wichtiger Hinweis
Customizer: Zusätzliches CSS	Kleine, themebezogene Designanpassungen	Themewechsel und manche Theme-Strukturen können die Wirkung beeinflussen
Website-Editor bei Block-Themes	Globale Stile und blockbezogene Gestaltung	Die konkrete Priorität hängt von Theme und Block-Struktur ab
Child-Theme-Stylesheet	Dauerhafte Anpassungen am Theme	Ein korrekt eingebundenes Child Theme ist erforderlich
Eigenes Plugin oder Snippet	Von einem Theme unabhängige Funktionen und Styles	Ausgabe und Abhängigkeiten müssen sauber registriert werden
Theme-Hauptdatei	Nur in besonderen, kontrollierten Fällen	Direkte Änderungen können bei Updates überschrieben werden

Bearbeite nach Möglichkeit keine Dateien des WordPress-Kerns und vermeide direkte Anpassungen an der Hauptdatei eines Themes, wenn eine updatefähige Alternative vorhanden ist. Bei einem klassischen Theme ist ein Child Theme oft der richtige Ort für eigene Styles. Bei einem Block Theme können globale Stile und zusätzliche CSS-Regeln im Website-Editor passender sein.

Warum Änderungen in der falschen Datei oft verwirren

Viele Themes laden mehrere Stylesheets: ein Grundstylesheet, responsive Regeln, Block-Stile und gegebenenfalls zusätzliche Dateien für einzelne Komponenten. Wenn Du eine Datei bearbeitest, die auf der aktuellen Seite nicht geladen wird, bleibt die Änderung ohne sichtbare Wirkung. Die Entwicklertools zeigen Dir, welche Datei tatsächlich aktiv ist.

Bei individuell entwickelten Themes sollten Styles über WordPress-Funktionen wie wp_enqueue_style() eingebunden werden. So lassen sich Abhängigkeiten, Versionen und Ladebedingungen kontrollieren. Eine CSS-Datei sollte nicht einfach in jeder Vorlage manuell eingebunden werden, wenn WordPress dafür eine verwaltbare Enqueue-Struktur bereitstellt.

Schritt 6: Media Queries und responsive Ansichten kontrollieren

Eine CSS-Regel kann auf dem Desktop funktionieren, aber auf dem Smartphone scheinbar ignoriert werden. Häufig liegt die gewünschte Eigenschaft in einer Media Query, deren Bedingung für die aktuelle Fensterbreite nicht erfüllt ist. In den Entwicklertools kannst Du verschiedene Gerätegrößen simulieren und sehen, ob die Regel aktiviert oder ausgeblendet ist.

Prüfe dabei nicht nur die Breite, sondern auch die Reihenfolge der Media Queries. Eine allgemeine Regel kann später von einer spezielleren mobilen Regel überschrieben werden. Auch ein gespeicherter Browser-Zoom oder die tatsächlich verfügbare Breite des Viewports kann die Beurteilung beeinflussen.

Ein praxisnahes Beispiel: Du änderst die Schriftgröße eines Navigationslinks außerhalb einer Media Query. Das Theme setzt innerhalb eines später geladenen mobilen Bereichs jedoch eine andere Schriftgröße. Die Desktop-Ansicht verändert sich, die mobile Ansicht nicht. Die Lösung besteht nicht zwingend in !important, sondern zunächst in einer passenden mobilen Regel an der richtigen Stelle der Kaskade.

Schritt 7: Optimierung, Minimierung und Cache-Busting prüfen

Performance-Plugins können CSS minimieren, zusammenfassen oder verzögert laden. Das ist grundsätzlich nützlich, erschwert aber die Kontrolle, wenn die optimierte Datei nach einer Änderung nicht neu erstellt wird. Leere deshalb den Optimierungscache und prüfe, ob die generierte CSS-Datei ein aktuelles Änderungsdatum oder eine neue Versionskennung besitzt.

Bei einer eigenen CSS-Einbindung sollte die Versionierung nachvollziehbar sein. WordPress kann eine Versionsnummer an die Stylesheet-URL anhängen. Wird bei jeder Änderung dieselbe URL mit langen Cache-Zeiten ausgeliefert, sehen Besucher unter Umständen noch die ältere Datei. Eine an den Dateiänderungszeitpunkt gekoppelte Version kann beim Entwicklungsprozess helfen; in produktiven Umgebungen sollte die konkrete Cache-Strategie zum Hosting passen.

Beachte außerdem, dass manche Optimierer CSS-Regeln umsortieren oder ungenutzte Regeln entfernen. Wenn eine Regel dynamisch erzeugte Klassen betrifft, kann eine automatische Bereinigung sie fälschlich als ungenutzt einstufen. In diesem Fall muss die betreffende Datei oder Klasse in der Optimierung berücksichtigt werden.

Schritt 8: Syntaxfehler und ungültige CSS-Werte ausschließen

Ein kleiner Syntaxfehler kann dazu führen, dass der Browser einen Teil des Stylesheets nicht wie erwartet verarbeitet. Kontrolliere geschweifte Klammern, Doppelpunkte, Semikolons, Anführungszeichen und Kommentare. Ein fehlendes Semikolon ist nicht immer problematisch, ein fehlendes schließendes Zeichen kann jedoch nachfolgende Regeln beeinflussen.

Prüfe auch, ob der verwendete Wert für die Eigenschaft gültig ist. margin: 10; ist beispielsweise nicht mit einer Einheit versehen und wird normalerweise verworfen. Verwende bei Längenwerten passende Einheiten wie px, rem oder %, sofern die Eigenschaft diese erwartet. Browser zeigen fehlerhafte Deklarationen in den Entwicklertools häufig als ungültig oder ausgegraut an.

CSS-Variablen können eine weitere Fehlerquelle sein. Wenn eine Regel color: var(--meine-farbe) nutzt, aber die Variable im betreffenden Gültigkeitsbereich nicht definiert ist, greift der deklarierte Wert möglicherweise nicht. Suche dann nach der Variablendefinition auf dem Element selbst oder einem übergeordneten Container.

Typische Fehler bei der Fehlersuche

Zu viele Änderungen gleichzeitig

Wenn Du Selektor, Farbe, Abstände und Template-Datei gleichzeitig änderst, ist später nicht erkennbar, welcher Schritt die Wirkung verursacht hat. Ändere zunächst nur eine Eigenschaft und teste sie direkt. So bleibt die Ursache nachvollziehbar.

Nur die angemeldete Ansicht testen

Administratoren sehen oft ungecachte Inhalte oder zusätzliche Werkzeugleisten. Teste daher auch im ausgeloggten Zustand und in einem privaten Browserfenster. Bei WooCommerce oder Mitgliederbereichen können unterschiedliche Nutzerzustände zusätzlich verschiedene HTML-Strukturen ausgeben.

Den Cache immer wieder leeren, ohne die Regel zu prüfen

Cache-Leeren ist sinnvoll, aber kein Ersatz für die Entwicklertools. Wenn die Regel im aktiven Stylesheet fehlt oder im Bereich „Styles“ durchgestrichen ist, wird ein weiteres Leeren des Caches die eigentliche Ursache nicht beheben.

Die Browseransicht mit einem echten Layoutproblem verwechseln

Manchmal ist die CSS-Regel aktiv, aber das Element bleibt unsichtbar, weil ein Elterncontainer display: none, eine begrenzte Höhe, overflow: hidden oder eine andere Positionierung verwendet. Prüfe deshalb das gesamte relevante Element und nicht nur die eine geänderte Eigenschaft.

Ein systematischer Praxisablauf

Angenommen, Du möchtest den Hintergrund eines Call-to-Action-Buttons ändern, aber die neue Farbe erscheint nicht. Gehe so vor:

1. Öffne die Seite im privaten Fenster und prüfe, ob die Farbe dort sichtbar ist.
2. Untersuche den Button und ermittle, ob die Hintergrundfarbe am Link, am Button-Container oder an einem Pseudo-Element gesetzt wird.
3. Suche im Styles-Bereich nach der eigenen Regel und prüfe, ob sie aktiv, ungültig oder durchgestrichen ist.
4. Vergleiche den Selektor mit den tatsächlich vorhandenen Klassen im HTML.
5. Prüfe im berechneten Bereich, welche background– oder background-color-Deklaration gewinnt.
6. Wenn die eigene Regel fehlt, kontrolliere die richtige Datei, die WordPress-Einbindung und den Optimierungscache.
7. Wenn sie überschrieben wird, passe die Spezifität oder Reihenfolge moderat an und vermeide eine unnötig komplexe Selektorkette.
8. Teste anschließend Desktop, mobile Ansicht, ausgeloggten Zustand und eine zweite Seite mit demselben Button.

Dieser Ablauf trennt Auslieferungsprobleme von CSS-Problemen. Erst wenn feststeht, dass die aktuelle Regel geladen wird und das richtige Element trifft, lohnt sich eine detaillierte Anpassung der Kaskade.

Technische Hinweise für updatefähige WordPress-Anpassungen

Für kleine Designänderungen reicht häufig das Feld für zusätzliches CSS. Bei umfangreicheren Anpassungen ist eine sauber verwaltete eigene CSS-Datei sinnvoller. Sie sollte über ein Child Theme oder ein eigenes Plugin eingebunden und nicht bei jedem Theme-Update manuell wiederhergestellt werden müssen.

Wenn Styles nur auf bestimmten Seiten benötigt werden, können Ladebedingungen die Auslieferung steuern. Dabei muss allerdings geprüft werden, ob der betreffende Block auch über dynamische Inhalte, Shortcodes oder AJAX nachgeladen wird. Ein Stylesheet, das nur auf der initialen URL berücksichtigt wird, deckt nicht automatisch jede später erzeugte Komponente ab.

Bei Block-Themes kommen zusätzlich globale Stile, Block-Variationen und vom Editor erzeugte CSS-Regeln hinzu. Änderungen im Editor können daher andere Prioritäten besitzen als Regeln aus einer klassischen Theme-Datei. Dokumentiere bei umfangreichen Projekten, wo globale Farben, Abstände und blockbezogene Ausnahmen definiert sind.

Vor Änderungen an produktiven Websites solltest Du ein aktuelles Backup besitzen. Bei umfangreichen Theme-, Plugin- oder Optimierungsanpassungen ist eine Staging-Umgebung sinnvoll, damit ein fehlerhaftes Stylesheet nicht unmittelbar die öffentliche Darstellung beeinflusst. Ein Backup ersetzt jedoch nicht die Prüfung, ob es sich wiederherstellen lässt.

Wann professionelle WordPress Hilfe sinnvoll ist

Wenn eine einzelne Farbe oder ein Abstand trotz der beschriebenen Prüfung nicht geändert wird, lässt sich die Ursache oft noch mit den Entwicklertools finden. Komplexer wird es, wenn mehrere Themes, Page Builder, dynamische Komponenten, Optimierungsdienste oder selbst entwickelte Plugins zusammenspielen.

Professionelle Unterstützung kann sinnvoll sein, wenn die Änderung nach einem Update regelmäßig verloren geht, die CSS-Ausgabe nur bei bestimmten Rollen fehlerhaft ist, mobile und Desktop-Ansichten widersprüchlich reagieren oder die Optimierung die Styles unzuverlässig verändert. Wichtig ist eine nachvollziehbare Diagnose: Welche Datei wird geladen, welches Element ist betroffen, welche Regel gewinnt und an welcher Stelle sollte die dauerhafte Änderung liegen?

Eine gute technische Lösung behebt nicht nur die sichtbare Abweichung, sondern berücksichtigt auch Wartbarkeit, Theme-Updates, Performance und mögliche Wechselwirkungen mit Plugins. Besonders bei sicherheits- oder geschäftskritischen Websites sollten Änderungen zunächst kontrolliert getestet und anschließend dokumentiert werden.

FAQ

Warum werden meine CSS-Änderungen in WordPress erst später sichtbar?

Wahrscheinlich wird eine ältere Version aus dem Browser-, WordPress-, Server- oder CDN-Cache ausgeliefert. Leere die beteiligten Caches, prüfe die Seite im privaten Fenster und kontrolliere in den Entwicklertools, ob das aktuelle Stylesheet geladen wird.

Was bedeutet es, wenn meine CSS-Regel durchgestrichen ist?

Die Regel wurde gefunden, aber eine andere Deklaration hat Vorrang. Vergleiche Selektor, Spezifität, Reihenfolge und mögliche Inline-Stile. Eine moderate Präzisierung ist meist besser als ein pauschales !important.

Warum funktioniert CSS im Customizer, aber nicht in der mobilen Ansicht?

Eine Media Query oder eine später geladene mobile Regel kann Deine Anpassung überschreiben. Prüfe die aktuelle Viewport-Breite und untersuche im Styles-Bereich, welche Regel innerhalb der mobilen Bedingungen aktiv ist.

Ist „Zusätzliches CSS“ im WordPress-Customizer eine gute Lösung?

Für kleinere, themebezogene Designänderungen ist es häufig praktisch. Bei umfangreichen oder themeunabhängigen Anpassungen sind ein Child Theme, ein eigenes Stylesheet oder ein eigenes Plugin oft besser wartbar. Die passende Lösung hängt von Theme, Umfang und gewünschter Update-Sicherheit ab.

Kann ein Plugin meine CSS-Regel verhindern?

Ja. Plugins können eigene Styles laden, Inline-Stile ausgeben, Inhalte dynamisch erzeugen oder CSS-Dateien optimieren. Untersuche das betroffene Element und prüfe, aus welcher Datei die aktive Regel stammt. Änderungen sollten möglichst über vorgesehene Hooks, Einstellungen oder updatefähige Erweiterungen erfolgen.

Warum wirkt eine Änderung an der CSS-Datei überhaupt nicht?

Die Datei wird möglicherweise nicht geladen, Du bearbeitest eine nicht verwendete Kopie oder die optimierte Version wird aus dem Cache geliefert. Die Netzwerk- und Styles-Bereiche der Entwicklertools zeigen, welche CSS-Dateien tatsächlich angefordert und angewendet werden.

Sollte ich für jede CSS-Anpassung !important verwenden?

Nein. !important kann kurzfristig helfen, macht die Kaskade aber schwerer wartbar. Prüfe zuerst Selektor, Reihenfolge und die Struktur des HTML. Setze die Ausnahme nur ein, wenn sie technisch begründet und nachvollziehbar dokumentiert ist.

Kann ein WordPress-Update meine CSS-Änderung löschen?

Direkte Änderungen an Theme-Dateien können bei Updates überschrieben werden. Nutze für dauerhafte Anpassungen möglichst zusätzliches CSS, ein Child Theme, ein eigenes Stylesheet oder ein eigenes Plugin – abhängig davon, ob die Änderung an ein bestimmtes Theme gebunden ist.

Fazit

Wenn WordPress CSS Änderungen nicht angezeigt werden, ist die Ursache meistens nachvollziehbar: ein veralteter Cache, ein unpassender Selektor, eine überschreibende Regel, eine Media Query oder eine falsche beziehungsweise nicht geladene Datei. Mit den Entwicklertools kannst Du unterscheiden, ob Deine Regel fehlt, ungültig ist oder lediglich in der Kaskade verliert.

Arbeite Schritt für Schritt, teste ausgeloggt und in verschiedenen Ansichten und speichere dauerhafte Anpassungen an einer updatefähigen Stelle. So behebst Du nicht nur die aktuelle Darstellung, sondern reduzierst auch das Risiko, dass die Änderung beim nächsten Theme- oder Plugin-Update wieder verschwindet.