Borlabs Cache leeren und zurücksetzen: Anleitung für WordPress

Nach einem Theme-Wechsel, einem Plugin-Update oder einer CSS-Änderung zeigt Ihre Seite noch die alte Version? Dann liefert Borlabs Cache eine gespeicherte Kopie aus, die nicht mehr aktuell ist. In dieser Anleitung leeren Sie den Cache in Sekunden, bauen den Preload sauber neu auf und beheben die typischen Anzeigefehler nach einem Reset – ohne dass Besucher eine kaputte Seite sehen.

Cache leeren oder zurücksetzen – wo der Unterschied liegt

„Cache leeren” und „Cache zurücksetzen” meinen in der Praxis zwei verschiedene Dinge:

• Cache leeren (Flush): Borlabs löscht die gespeicherten HTML-Dateien. Ihre Einstellungen bleiben unverändert; die Seiten werden beim nächsten Aufruf – oder durch den Preload – neu erzeugt.
• Reset der Konfiguration: Sie setzen die Optionen auf ein Preset zurück (z. B. „Default”) und bauen den Cache anschließend komplett neu auf. Das ist der richtige Weg, wenn nicht nur Inhalte veraltet sind, sondern die Optimierung selbst Probleme macht.

In den allermeisten Fällen genügt das reine Leeren. Ein vollständiger Reset ist nur nötig, wenn Optimierungen wie das Zusammenfassen von CSS/JS Ihre Seite zerschießen.

Cache leeren: die schnellen Wege

Über die WordPress-Adminleiste

Sobald Borlabs Cache aktiv ist, ergänzt das Plugin in der oberen WordPress-Adminleiste ein eigenes Menü „Borlabs Cache”. Darüber verwerfen Sie den kompletten Seiten-Cache mit einem Klick und stoßen den Neuaufbau an – praktisch, wenn Sie gerade eine Seite bearbeiten und die Änderung sofort live sehen wollen.

Über das Borlabs-Cache-Dashboard

Melden Sie sich als Administrator im WordPress-Backend an und öffnen Sie im linken Menü Borlabs Cache → Dashboard. Nehmen Sie Ihre Änderungen vor und klicken Sie auf „Anwenden und Cache aktualisieren” (englische Oberfläche: „Apply changes and refresh cache”). Borlabs verwirft den alten Cache und startet den Neuaufbau. Diesen Weg nutzen Sie, wenn Sie ohnehin Einstellungen angepasst haben.

Einzelne Seiten gezielt leeren

Sie müssen nicht immer den gesamten Cache verwerfen. Über die Cache-Übersicht „View Cache” – so heißt das Feature auch in der deutschsprachigen Oberfläche – sehen Sie, welche URLs mit welchem Status zwischengespeichert sind, und können einzelne Einträge entfernen. Das ist schonender für die Performance, weil der Rest des Caches erhalten bleibt und nur die geänderte Seite neu erzeugt wird. Ergänzend leert Borlabs den Cache einer Seite automatisch, sobald Sie den zugehörigen Beitrag oder die Seite aktualisieren.

Kompletter Reset: Cache und Konfiguration

Wenn nach einem Update Kacheln verrutschen, Schriften fehlen oder Skripte streiken, hilft ein Reset auf ein sauberes Preset:

1. Öffnen Sie Borlabs Cache → Dashboard.
2. Wählen Sie unter Cache Presets die Voreinstellung „Default”. Für die Fehlersuche gibt es zusätzlich „Test CSS” und „Test JS” – diese deaktivieren gezielt die CSS- bzw. JS-Optimierung.
3. Klicken Sie auf „Alle Einstellungen speichern” („Save all settings”).
4. Bestätigen Sie mit „Anwenden und Cache aktualisieren”.

Damit stehen alle Optimierungen wieder auf einem erprobten Ausgangspunkt und der Cache wird frisch aufgebaut. Erst danach schalten Sie die aggressiveren Optionen (Merging, Defer JS) Schritt für Schritt wieder zu – so erkennen Sie sofort, welche Einstellung ein Problem verursacht.

Preload nach dem Reset: warum die Seite kurz langsamer ist

Direkt nach dem Leeren ist der Cache leer – die erste Anfrage jeder Seite wird wieder dynamisch von WordPress erzeugt und ist entsprechend langsamer. Borlabs’ Cache Preloading (ein Crawler) ruft Ihre URLs im Hintergrund selbst auf und legt die statischen Dateien an, bevor echte Besucher kommen. Wie viele Seiten der Crawler pro Tag aufruft, hängt von Ihrer Lizenz ab: Die Personal-Lizenz ist auf 25 Seiten pro Tag begrenzt, die Commercial-Lizenz auf bis zu 1.000 Seiten pro Tag (Stand: Juli 2026). Ist das Tageslimit erreicht, pausiert der Crawler bis zum nächsten Tag – die Obergrenze bezieht sich dabei nur auf die täglich aufgerufenen Seiten, nicht auf die Zahl der Seiten im Cache-Index. Als Quelle für die URL-Liste dient in der Regel Ihre XML-Sitemap („Cache Indexing through Sitemap”).

Zwei Dinge sollten Sie wissen:

• Der Crawler läuft als zeitgesteuertes WP-Cron-Ereignis im Hintergrund. Läuft WP-Cron auf Ihrem Server nicht zuverlässig, stockt auch der Preload – dann hilft ein per Server eingerichteter, echter Cronjob, der wp-cron.php regelmäßig (z. B. alle 1–5 Minuten) aufruft.
• Bei sehr großen Seiten kann der vollständige Neuaufbau einige Zeit dauern. In dieser Phase ist die Time-to-First-Byte einzelner Seiten höher – das ist normal und legt sich, sobald der Cache gefüllt ist.

Typische Fehler nach dem Cache-Reset – und wie Sie sie lösen

Layout oder Schriften kaputt. Meist liegt es an der Zusammenfassung/Minifizierung von CSS und JavaScript. Schalten Sie das Preset auf „Test CSS” bzw. „Test JS”, um die jeweilige Optimierung zu isolieren. Bleibt die Seite dann heil, deaktivieren Sie „Merging & Minification” gezielt für die betroffene Datei oder tragen sie in die Ausnahmen ein.

Änderungen sind trotz Leeren nicht sichtbar. Dann liefert eine weitere Ebene noch die alte Version aus. Prüfen Sie der Reihe nach:

• Server-Cache (z. B. LiteSpeed, Varnish oder der Cache Ihres Hosters bzw. in Plesk),
• CDN wie Cloudflare (dort zusätzlich den Cache leeren, notfalls kurz den Development Mode aktivieren),
• Object Cache (Redis/Memcached) – hier den Objekt-Cache flushen,
• Browser-Cache: mit Strg + F5 hart neu laden.

Dynamische Inhalte (Warenkorb, Login-Status) sind eingefroren. Solche Bereiche gehören nicht in den statischen Cache. Nutzen Sie Fragment Caching, um dynamische Teile innerhalb einer gecachten Seite auszunehmen, oder legen Sie eine Cache-Ausnahme für die betroffenen Seiten an (typisch: Warenkorb, Kasse, „Mein Konto”).

Nach jedem Deploy wieder alte Inhalte. Automatisieren Sie das Leeren: Borlabs invalidiert bei Beitrags-Updates die betroffenen Seiten selbst. Einen eigenen WP-CLI-Befehl bringt Borlabs Cache allerdings nicht mit (Stand: Juli 2026); für Deployments greifen Sie stattdessen auf die Entwickler-Schnittstelle des Plugins zurück und stoßen den Cache-Neuaufbau programmatisch über \Borlabs\Factory::get('Cache\Frontend\Garbage')->refreshCache() an – zum Beispiel an einen WordPress-Hook (etwa save_post) oder an Ihren Deploy-Ablauf gekoppelt.

Borlabs Cache ist nicht Borlabs Cookie

Ein häufiger Stolperstein: Borlabs Cache (Performance/Caching) und Borlabs Cookie (DSGVO-Cookie-Consent) sind zwei getrennte Plugins desselben Herstellers. Wenn Sie eigentlich das Consent-Banner meinen – etwa weil Einwilligungen oder das Banner klemmen –, hilft nicht das Leeren des Seiten-Caches, sondern das Zurücksetzen von Borlabs Cookie. Einen Überblick über beide Produkte gibt unser Borlabs-Ratgeber. Wer parallel WP Rocket einsetzt, sollte zudem Konflikte zwischen Caching und Borlabs im Blick behalten.

FAQ

Verliere ich beim Cache-Leeren meine Einstellungen? Nein. Beim Leeren werden nur die gespeicherten HTML-Dateien verworfen. Ihre Borlabs-Konfiguration bleibt bestehen. Nur wenn Sie bewusst ein Preset laden und speichern, ändern sich Optionen.

Wie oft sollte ich den Cache leeren? Im Normalbetrieb gar nicht manuell – Borlabs leert geänderte Seiten automatisch, und der Preload hält alles aktuell. Leeren Sie gezielt nach größeren Änderungen (Theme-/Plugin-Update, globale CSS-Anpassung) oder wenn eine Änderung partout nicht erscheint.

Der Cache lässt sich nicht leeren bzw. baut sich nicht neu auf – was tun? Prüfen Sie die Schreibrechte im Cache-Verzeichnis, ob WP-Cron läuft und ob ein Server- oder CDN-Cache dazwischenfunkt. Häufig ist nicht Borlabs das Problem, sondern eine darüberliegende Cache-Ebene.

Brauchen Sie Unterstützung bei DSGVO & Cookie-Consent (Borlabs & Co.)? Ypsilon.dev ist Ihre Webagentur aus Regensburg – jetzt kostenlose Erstberatung anfragen.