Weiße Seite — und im Shop zählt jede Minute.

Erst einordnen.

Die Frage „was wurde zuletzt geändert“ beantwortet die meisten Fälle. Bei einem Shop kommt eine zweite dazu: Wurde etwas importiert? Ein fehlerhafter Produktimport kann einzelne Seiten lahmlegen, ohne dass jemand am System gearbeitet hat.

Die Protokolle.

Shopware schreibt Fehler in ein Protokollverzeichnis innerhalb des Projekts, getrennt nach Umgebung. Die jüngsten Einträge stehen am Ende der Datei — dort steht die Meldung samt Datei und Zeilennummer.

Daneben protokolliert der Webserver alles, was auftritt, bevor Shopware startet: Syntaxfehler, Speicherüberschreitungen, Rechteprobleme. Wenn das Shopware-Protokoll leer bleibt, ist das die richtige Stelle.

Eine dritte Quelle, die Shopware mitbringt: In der Verwaltung gibt es eine Protokollansicht für Systemereignisse. Die ist nützlich, wenn das Backend noch läuft — und nutzlos, wenn nicht. Für den Ernstfall ist das Dateiprotokoll die verlässlichere Quelle.

Fehleranzeige einschalten.

Shopware unterscheidet zwischen Produktiv- und Entwicklungsumgebung. Die Einstellung steht in einer Umgebungsdatei im Hauptverzeichnis, zusammen mit den Zugangsdaten.

Dort lässt sich die Umgebung umstellen, so dass Fehler im Klartext angezeigt werden statt einer allgemeinen Meldung. Das geht auch dann, wenn das Backend nicht mehr erreichbar ist — es ist eine Textdatei.

Zwei Regeln: nur vorübergehend, und niemals dauerhaft auf einem öffentlich erreichbaren Shop. Die Entwicklungsumgebung zeigt Pfade, Konfiguration und Abfragen — und sie ist deutlich langsamer. Nach der Fehlersuche sofort zurückstellen und den Cache leeren (Debug-Modus).

Cache und Theme.

Die beiden häufigsten Ursachen nach einer Änderung — und beide in Minuten behoben.

Shopware speichert aufbereitete Konfiguration, Routen und kompilierte Dienste zwischen. Ein widersprüchlicher Zustand nach einem Update oder einer Plugin-Installation führt zu Abbrüchen. Das Leeren geht über die Kommandozeile und notfalls über das Dateisystem (Cache leeren).

Das Theme ist der zweite Kandidat: Shopware erzeugt die Gestaltungsdateien aus Quelldateien. Nach einem Update oder einer Plugin-Änderung müssen sie neu gebaut werden. Ohne diesen Schritt läuft der Shop mit alten Dateien — das sieht je nach Umfang nach kaputtem Layout oder nach weißer Seite aus.

Dasselbe gilt für die Verwaltungsoberfläche: Auch sie wird gebaut. Wenn das Backend ohne Gestaltung lädt, ist das der fehlende Schritt.

Nach einem Update.

1. Cache leeren über die Kommandozeile.
2. Datenbankmigrationen prüfen — vollständig durchgelaufen?
3. Theme und Verwaltung neu bauen.
4. Protokoll lesen und die Datei einem Plugin zuordnen.
5. Verdächtiges Plugin deaktivieren.
6. Warteschlange prüfen.

Punkt zwei ist bei Shopware besonders wichtig: Wenn die Migrationen über die Weboberfläche gestartet wurden und die Anfrage abgebrochen ist, steht die Datenbank zwischen zwei Zuständen. Das äußert sich in schwer zuzuordnenden Fehlern und gehört über die Kommandozeile nachgeholt (Update durchführen).

Plugin eingrenzen.

Wenn das Backend läuft, lassen sich Plugins dort einzeln deaktivieren — einzeln, nicht alle auf einmal.

Ohne Backend geht es über die Kommandozeile: Plugins lassen sich dort deaktivieren und deinstallieren. Das ist der Vorteil eines Systems mit ordentlichem Kommandozeilenwerkzeug — und ein weiterer Grund, diesen Zugriff zu haben.

Als Notweg bleibt der Eingriff über die Datenbank in der Plugin-Tabelle. Danach unbedingt den Cache leeren, sonst wirkt die Änderung nicht.

Ein Hinweis zur Reihenfolge: Bei Shopware verdächtige ich zuerst Plugins, die in den Seitenaufbau eingreifen oder die Kasse betreffen — sie wirken an vielen Stellen gleichzeitig (Plugins).

Die Warteschlange.

Ein Shopware-spezifisches Thema, das bei Ausfällen oft übersehen wird. Shopware arbeitet vieles asynchron ab: Mailversand, Indexierung, Bildverarbeitung, Datenaktualisierungen laufen über eine Nachrichtenwarteschlange.

Wenn die nicht abgearbeitet wird — weil der zuständige Vorgang nicht läuft oder in einen Fehler gelaufen ist — staut sie sich. Die Folgen sind zunächst unauffällig: Bestätigungsmails kommen nicht, die Suche findet neue Produkte nicht, Bilder werden nicht erzeugt.

Bei starker Last kann eine überfüllte Warteschlange auch Ressourcen binden und zu Abbrüchen führen. Prüf nach jedem Vorfall, wie viele Nachrichten dort warten und ob fehlgeschlagene Einträge liegen geblieben sind (Wartung).

Ohne erkennbaren Anlass.

• Festplatte voll? Protokolle, Cache und erzeugte Bilder wachsen (Webspace voll).
• Datenbank antwortet nicht oder Verbindungsgrenze erreicht.
• Arbeitsspeicher erschöpft — Shopware braucht mehr als einfachere Systeme.
• Hoster hat umgestellt — PHP-Version, Grenzen, Erweiterungen.
• Lastspitze, etwa nach einem Newsletter.
• Zeitgesteuerter Vorgang hängt und bindet Ressourcen.

Der fünfte Punkt ist bei Shops real: Ein Newsletter an zehntausend Empfänger erzeugt einen Ansturm, den ein knapp bemessener Server nicht verträgt. Das ist kein Fehler, sondern eine Kapazitätsfrage (Shopware langsam).

Datenbank.

Fehlende Verbindung meldet Shopware deutlich. Weiße Seiten entstehen eher durch Strukturprobleme: nicht vollständig durchgelaufene Migrationen, eine beschädigte Tabelle oder ein Datenbestand, der eine Abfrage zum Abbruch bringt.

Der letzte Fall ist shopspezifisch: Ein fehlerhafter Produktimport kann Datensätze erzeugen, an denen die Ausgabe scheitert — etwa ein Produkt ohne gültige Preiszuordnung. Dann funktioniert der Shop, aber eine Kategorie bleibt weiß.

Das grenzt man ein, indem man prüft, welche Produkte auf der betroffenen Seite liegen, und den zuletzt importierten Bestand ansieht (Importfehler).

Nur die Kasse betroffen.

Der teuerste Fall, weil er direkt Umsatz kostet und oft spät auffällt — der Shop sieht ja normal aus.

Übliche Ursachen: ein Zahlungs-Plugin nach einem Update, eine Regel für Versand oder Zahlung, die ins Leere greift, eine Steuerkonfiguration mit Lücke, oder ein Dienst des Zahlungsanbieters, der nicht antwortet.

Vorgehen: Protokoll zum Zeitpunkt eines fehlgeschlagenen Versuchs ansehen, einen Testkauf mit jeder Zahlungsart durchführen, und prüfen, ob die Regeln vollständig definiert sind — eine Versandart ohne gültige Regel für ein bestimmtes Land lässt die Kasse scheitern, ohne dass es einen Programmfehler gibt.

Mein Rat für den Betrieb: einen automatischen Testkauf oder zumindest eine Überwachung, die meldet, wenn über mehrere Stunden keine Bestellung eingeht. Das ist die einzige Form, einen stillen Kassenausfall rechtzeitig zu bemerken.

Prüfweg.

1. Was wurde zuletzt geändert — inklusive Importen?
2. Serverprotokoll und Shopware-Protokoll lesen.
3. Cache leeren über die Kommandozeile.
4. Theme und Verwaltung neu bauen.
5. Migrationen nachholen, falls offen.
6. Fehleranzeige einschalten, wenn nötig und abgesichert.
7. Plugin eingrenzen, einzeln.
8. Warteschlange und Speicherplatz prüfen.
9. Sicherung einspielen, wenn der Verkauf nicht warten kann.

Schritt neun ist bei einem Shop keine Niederlage, sondern eine Rechnung: Jede Stunde Ausfall kostet Umsatz. Die Ursachensuche kann danach in einer Kopie stattfinden, während der Shop wieder verkauft.

Wenn du nicht weiterkommst.

Wenn dein Shop steht und jede Stunde Umsatz kostet. Ich finde die Ursache, behebe sie und erkläre dir, was passiert ist. Wenn gerade keine Bestellungen durchgehen, hilft der Notfall-Support, dauerhaft begleitet die Shopware-Wartung.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. Content-Management- und Shopsysteme sind mein Fachgebiet — ich arbeite seit Jahren damit, unterrichte das Thema als Dozent und kenne die Systeme von innen: Datenmodell, Rechtekonzept, Templating, Plugin-Architektur, Caching, Betrieb.

Bei Shopware 6 zahlt sich das besonders aus, weil es auf demselben professionellen Unterbau aufsetzt wie andere ausgewachsene Systeme: Abhängigkeitsverwaltung, Dienste-Container, eine getrennte Verwaltungsoberfläche und eine Schnittstelle für alles. Wer dieses Modell verstanden hat, findet Fehler schnell — und sieht auch, wo ein Shop gegen das Modell gebaut wurde.

Was du bekommst: eine Diagnose in verständlicher Sprache, eine Behebung, die hält, und eine ehrliche Einschätzung dazu, ob dein Shop weiterbetrieben, aktualisiert oder abgelöst gehört — auch wenn die Antwort lautet, dass alles so bleiben kann.