Wenn Ihre Website gerade ausgefallen ist, schreiben Sie noch niemandem. Beginnen Sie mit zehn Minuten, die aus der Meldung „die Website geht nicht” eine Meldung machen, auf die sich konkret antworten lässt. Dieses Zentrum führt durch diese Triage, zeigt, wo die Logs liegen und wonach Sie darin suchen, sagt genau, was Sie schicken sollen, und beschreibt, was nach Eingang Ihrer Nachricht auf unserer Seite passiert. Wenn Sie es eiliger haben als Zeit zum Lesen, springen Sie zum Abschnitt „Was in die Meldung gehört” und kopieren Sie die Liste.
Bevor Sie schreiben: zehn Minuten Triage
Vier Fragen, in dieser Reihenfolge. Ihre Antworten zeigen die Ursache meist schneller als jedes Werkzeug.
Was genau funktioniert nicht. Die gesamte Website, eine einzelne Unterseite oder nur das Adminpanel? Öffnen Sie die Adresse in einem privaten Fenster und über eine andere Verbindung, zum Beispiel auf dem Handy im Mobilfunknetz. Wenn die Website im privaten Fenster läuft, liegt das Problem im Browsercache oder in Ihrer Sitzung, nicht am Server. Wenn sie auf dem Handy läuft, im Büro aber nicht, prüfen Sie DNS und Firewall auf Ihrer Seite, bevor jemand in WordPress zu graben beginnt.
Wie lautet die genaue Meldung. „Geht nicht” sind fünf verschiedene Ausfälle. Ein weißer Bildschirm ist meist ein PHP Fehler bei ausgeschalteter Fehleranzeige. Fehler 500 ist ein Serverfehler, am häufigsten ein Plugin, ein Theme oder das Speicherlimit. „Error establishing a database connection” betrifft die Datenbank, also einen völlig anderen Pfad. Fehler 403 beim Login ist meist eine Sicherheitsregel und kein Ausfall. Notieren Sie Code und vollständigen Text, samt Zeilennummer, falls vorhanden.
Was sich kurz davor geändert hat. Ausfälle kommen selten von allein. Ein Plugin Update, ein Core Update, eine PHP Umstellung durch den Hoster, ein abgelaufenes Zertifikat, ein geänderter DNS Eintrag, eine abgelaufene Domain, ein überschrittenes Limit beim Hosting. Datum und Uhrzeit der letzten Änderung sind meist die wertvollste Angabe der ganzen Meldung.
Ob Sie eine Sicherung haben. Spielen Sie sie nicht reflexartig ein, stellen Sie aber fest, dass es sie gibt und von wann sie stammt. Wenn der Hoster nächtliche Sicherungen anlegt, prüfen Sie im Panel, wann die letzte lief. Diese Angabe entscheidet darüber, ob eine Reparatur riskant oder umkehrbar ist.
Fehlermeldung, Schicht, erster Handgriff
Diese Tabelle verkürzt die längste Phase jedes Ausfalls, nämlich das Raten, wo überhaupt zu suchen ist.
| Was Sie sehen | Wahrscheinlichste Schicht | Erster Handgriff |
|---|---|---|
| Leerer weißer Bildschirm | PHP, kritischer Fehler mit verborgener Meldung | Fehlerprotokoll in eine Datei einschalten und Seite neu laden |
| HTTP 500 | Webserver oder PHP | error_log im Verzeichnis der Website lesen |
| HTTP 502 oder 504 | PHP-FPM, Timeout, externe API | Antwortzeit und Prozesslimits prüfen |
| Error establishing a database connection | Datenbank | Zugangsdaten in wp-config.php und Status des MySQL Dienstes prüfen |
HTTP 403 bei /wp-admin | Sicherheitsregel, Web Application Firewall | Firewall Logs und IP Sperrliste prüfen |
| Seite lädt sehr lange | Datenbank, externe API, fehlender Cache | TTFB messen und Frontend mit Adminpanel vergleichen |
| Weiterleitung auf eine fremde Domain | Infektion oder ausgetauschtes Plugin | Keine Dateien löschen, Beweiskopie sichern |
| „Ihre Verbindung ist nicht privat” | TLS Zertifikat | Ablaufdatum des Zertifikats prüfen |
| Seite zeigt ein Angebot des Registrars | Domain abgelaufen | Ablaufdatum in der Whois Datenbank prüfen |
Die mittlere Spalte ist wichtiger als die rechte. Die meiste verlorene Zeit bei Ausfällen entsteht dadurch, dass die falsche Schicht repariert wird: Jemand deaktiviert Plugins, obwohl das Problem im DNS sitzt, oder wechselt den Hoster, obwohl ein einzelnes Plugin schuld ist, das eine externe API abfragt.
Wo die Logs liegen und wonach Sie darin suchen
Ohne Log ist die Diagnose Raten. Es gibt drei Orte, in dieser Reihenfolge der Nützlichkeit.
Das PHP Fehlerlog. Auf den meisten Shared Hostings liegt es als error_log im Verzeichnis der Website oder im Panel im Bereich der Protokolle. Sie suchen die letzten Einträge PHP Fatal error aus der Stunde des Ausfalls. So ein Eintrag enthält Datei und Zeilennummer, und das zeigt das schuldige Plugin meist in der ersten Sekunde.
Das WordPress Log. Wenn der Hoster kein PHP Log herausgibt, schalten Sie ein eigenes ein. In wp-config.php, oberhalb der Zeile mit dem Kommentar „That’s all, stop editing”:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Die Fehler landen in wp-content/debug.log, und Besucher sehen nichts davon. Schalten Sie es nach der Diagnose aus und löschen Sie die Datei; ein Log, das einen Monat auf der Produktion liegen bleibt, kann auf Gigabyte anwachsen und selbst zum Ausfall werden.
Das Webserver Log. Nginx und Apache schreiben Zugriffe und Fehler getrennt. Interessant ist das zweite, aus der Stunde des Vorfalls. Auf einem Hosting mit Shell Zugang genügt tail -n 100 /pfad/zu/logs/error.log. Wenn Sie nur ein Panel haben, laden Sie die Datei herunter und öffnen Sie sie in einem Texteditor, nicht in einer Tabellenkalkulation, denn dort werden lange Zeilen abgeschnitten.
Wonach Sie in allen dreien suchen: nach einem Zeitstempel, der zum Moment des Ausfalls passt, nach einer wiederholt auftretenden gleichen Zeile (das ist meist eine Schleife, kein Zufall) und nach dem Namen eines Plugin Verzeichnisses im Dateipfad. Was Sie nicht tun sollten: Fügen Sie keine zehntausend Zeilen lange Datei in die Meldung ein. Zwanzig Zeilen rund um das erste Auftreten des Fehlers sind wertvoller als der komplette Satz.
Die vier häufigsten Ausfälle und die erste Hilfe
Die folgenden Schritte sind sicher, umkehrbar und brauchen keinen Entwickler. Wenn einer davon über Ihre Komfortzone hinausgeht, brechen Sie ab und schreiben Sie uns; eine abgebrochene Reparatur lässt sich leichter zu Ende bringen als eine vertiefte.
Weißer Bildschirm oder Fehler 500 nach einem Update. Deaktivieren Sie zuerst das zuletzt aktualisierte Plugin. Wenn Sie keinen Zugang zum Panel haben, benennen Sie sein Verzeichnis in wp-content/plugins/ über den Dateimanager des Hostings oder per FTP um; WordPress deaktiviert es dann. Hilft das nicht, benennen Sie das gesamte Verzeichnis plugins in plugins-off um, prüfen Sie die Website und stellen Sie den Namen wieder her. Das klärt in einer Minute, ob ein Plugin oder das Theme schuld ist. Mit Zugang zur Kommandozeile erledigt wp plugin deactivate --all dasselbe sauberer und erlaubt es, die Plugins einzeln wieder einzuschalten.
Die Website ist plötzlich langsam. Prüfen Sie, ob das Laden der Website langsam ist oder das Adminpanel. Ein langsames Panel bei schnellem Frontend deutet meist auf die Datenbank oder eine externe API hin, zum Beispiel ein Plugin, das bei jedem Aufruf den Lizenzserver abfragt. Ein langsames Frontend bei schnellem Panel deutet meist auf Cache, Bilder oder das Hosting hin. Messen Sie, bevor Sie optimieren: PageSpeed Insights zeigt gleichzeitig das Laborergebnis und die Daten echter Nutzer aus CrUX, und die zweiten sind wichtiger, weil sie beschreiben, was Menschen erleben, und nicht eine Simulation. Prüfen Sie separat die reine Antwortzeit des Servers, zum Beispiel mit curl -o /dev/null -s -w "%{time_starttransfer}\n" https://ihredomain.de/. Ein Wert über einer Sekunde bedeutet ein Problem auf der Serverseite und nicht bei Bildern oder Skripten.
Ich kann mich nicht einloggen. Bevor Sie das als Ausfall werten, prüfen Sie drei Dinge: ob die Login Adresse von einem Sicherheitsplugin geändert wurde, ob Ihre IP nach fehlgeschlagenen Versuchen gesperrt wurde und ob die Uhr auf dem Server verstellt ist, denn das zerstört Sitzungen. Ein Passwort Reset über das Formular setzt funktionierenden Mailversand voraus, also klappt das nicht, wenn keine Mails hinausgehen. Der Notausgang: wp user update admin --user_pass=NeuesPasswort von der Kommandozeile oder eine Passwortänderung direkt in der Datenbank mit der MD5 Funktion, die WordPress beim ersten Login akzeptiert und sofort durch einen eigenen Hash ersetzt.
Verdacht auf Infektion. Symptome: Weiterleitungen auf eine fremde Domain nur aus den Suchergebnissen, neue Administratoren, die Sie nicht angelegt haben, eine Warnung in der Search Console, Spam im Inhalt, der ausschließlich für den Googlebot sichtbar ist. Prüfen Sie die Liste der Nutzer mit Administratorrolle und die Änderungsdaten der Dateien, zum Beispiel mit find . -type f -mtime -7 -name "*.php", um zu sehen, was sich in der letzten Woche geändert hat. Löschen Sie keine Dateien und spielen Sie keine Sicherung ein, solange das Datum des ersten Einstiegs nicht feststeht; eine Kopie von vor einer Woche enthält meist bereits dieselbe Lücke. Ändern Sie die Passwörter, auch für Datenbank und FTP, und schreiben Sie uns mit dem Hinweis auf die Infektion.
Ein Ausfall im WooCommerce Shop hat eine andere Reihenfolge
Im Shop ist der Reflex „alle Plugins deaktivieren” teuer, denn er schaltet zusammen mit der Diagnose auch Zahlungen, Versand und Lagerintegrationen ab. Die Reihenfolge ist umgekehrt zu der einer Visitenkartenseite.
Stellen Sie zuerst fest, ob Bestellungen eingehen. Die Bestellliste der letzten Stunde beantwortet das schneller als jedes Log. Wenn Bestellungen eingehen und Kunden trotzdem ein Problem melden, liegt der Ausfall bei den Benachrichtigungen oder bei der Zahlung und nicht im Shop selbst. Wenn gar keine eingehen, prüfen Sie Warenkorb und Kasse im privaten Fenster, denn beide sind vom Cache ausgenommen und gehen anders kaputt als der Rest der Website.
E Mail Benachrichtigungen sind ein eigener, sehr häufiger Ausfall, der wie ein Shopausfall aussieht. Prüfen Sie, ob überhaupt Post hinausgeht und ob sie nicht im Spam des Empfängers landet. Drei DNS Einträge entscheiden darüber fast vollständig: SPF, DKIM und DMARC. Wenn der Shop Mails direkt vom Hostingserver ohne diese Einträge versendet, kommt ein Teil der Nachrichten nicht an, und keine Änderung im Plugin repariert das.
Betrifft der Ausfall eine einzelne Zahlungsart, prüfen Sie im Panel des Anbieters, ob der API Schlüssel oder das Zertifikat der Integration abgelaufen ist. Das ist die Situation, in der die Website korrekt läuft, die Logs sauber sind und der Verkauf trotzdem steht, sodass man ohne Prüfung beim Anbieter stundenlang im eigenen Code suchen kann.
Wann es gar kein Ausfall der Website ist
Vier Fälle, in denen WordPress unschuldig ist und eine Diagnose auf seiner Seite nur Zeit kostet.
Die Domain ist abgelaufen. Symptom: statt der Website erscheint ein Angebot des Registrars oder eine leere Seite. Sie prüfen das mit einer einzigen Abfrage in der Whois Datenbank und sehen das Ablaufdatum. Eine Verlängerung wirkt meist innerhalb einiger Minuten, in Extremfällen geht die Domain jedoch in die Rückkaufphase und kostet ein Vielfaches der normalen Verlängerung.
Die DNS Änderung ist noch nicht verbreitet. Symptom: Ein Teil der Leute sieht die neue Website, ein Teil die alte. dig ihredomain.de +short zeigt, auf welche Adresse die Domain aus Ihrer Perspektive zeigt. Änderungen verbreiten sich gemäß dem TTL Wert, wenn ihn also jemand auf einen Tag gesetzt hat, dauert es genau so lange, und von der Seite der Website lässt sich das nicht beschleunigen.
Das Zertifikat ist abgelaufen. Symptom: Browserwarnung über eine nicht vertrauenswürdige Verbindung. Das Ablaufdatum lesen Sie mit openssl s_client -connect ihredomain.de:443 2>/dev/null | openssl x509 -noout -dates. Die automatische Erneuerung kann scheitern, wenn sich zwischenzeitlich das DNS geändert hat oder eine Weiterleitung hinzukam, die die Prüfung blockiert.
Der Hoster hat das Konto gesperrt. Symptom: eine Meldung des Hosters statt der Website, manchmal nach Überschreiten des Transferlimits oder nach einer unbezahlten Rechnung. Hier gibt es im Code nichts zu reparieren, sondern nur ein Gespräch mit dem Hoster, aber danach lohnt die Prüfung, was den Traffic erzeugt hat, denn ebenso oft ist es ein Bot und nicht Kundschaft.
Was in die Meldung gehört
Je mehr aus dieser Liste Sie gleich angeben, desto weniger Nachfragerunden gibt es und desto schneller bekommen Sie eine inhaltliche Antwort statt der Bitte um Ergänzung.
| Angabe | Warum sie gebraucht wird |
|---|---|
| Adresse der Website und der konkreten Unterseite mit dem Fehler | Wir reproduzieren das Problem bei uns, bevor wir etwas ändern |
| Name des Hosters und Art des Kontos | Limits, PHP Version und Zugang zu Logs unterscheiden sich je nach Hoster |
| Datum und Uhrzeit des Auftretens | Damit lässt sich das Ereignis in den Serverlogs finden |
| Genauer Fehlertext | Code und Meldung zeigen die Schicht: PHP, Datenbank, Webserver, Netzwerk |
| Zwanzig Logzeilen rund um den Fehler | Verkürzt die Diagnose stärker als jede verbale Beschreibung |
| Letzte Änderung vor dem Ausfall | Häufigste Ursache und schnellster Weg zurück |
| Wer sonst noch Zugang hat | Schließt paralleles Arbeiten von zwei Personen an derselben Website aus |
| Ob eine Sicherung existiert und von wann | Entscheidet, ob die Reparatur umkehrbar ist |
| Ob der Verkauf steht | Legt die Reihenfolge der Arbeiten fest, bevor wir beginnen |
Was nicht in die erste Nachricht gehört: Passwörter. Zugänge klären wir nach dem Umfang und am besten als separates Administratorkonto, das Sie nach Abschluss der Arbeiten löschen. Wenn die Sache dringend ist, schreiben Sie das offen und sagen Sie, was dringend genau bedeutet: Der Shop nimmt keine Bestellungen an ist etwas anderes als das Kontaktformular verschickt doppelt.
Was auf unserer Seite passiert
Die Meldung landet bei einer Person und nicht in einer First Level Warteschlange, Sie erklären die Sache also nicht zweimal. Die erste Antwort enthält das, was sich aus Ihrer Beschreibung feststellen ließ, und eine Frage nur zu dem, was wirklich fehlt.
Danach folgt die Diagnose. Sie ist ein eigener, begrenzter Schritt mit eigenem Preis, Sie wissen also, wozu Sie zustimmen, bevor jemand die Website anfasst. Ihr Ergebnis sind Ursache, Umfang der Reparatur und Kosten, schriftlich. Die Arbeiten starten nach Bestätigung des Umfangs, nicht nach einem mündlichen „legt los”. Kommt unterwegs etwas außerhalb des Umfangs zutage, halten wir an und geben ein separates Angebot ab, statt es nachträglich auf die Rechnung zu setzen.
Die Reparatur führen wir überall dort, wo es möglich ist, auf einer Kopie oder in einer Testumgebung durch, und Änderungen an der Produktion gehen in einem Deployment mit Rücknahmemöglichkeit live. Nach Abschluss bekommen Sie eine Beschreibung der Ursache und dessen, was zu tun ist, damit sie nicht wiederkehrt. Letzteres ist meist wichtiger als die Reparatur selbst, denn ein Ausfall, der in drei Monaten zurückkommt, kostet ein zweites Mal.
Was wir nicht machen
Wir gestalten nicht grafisch. Layout und Anordnung der Elemente in der Ansicht, also das Wireframe, liefert der Kunde; wir setzen daraus die responsive Oberfläche, die Integrationen und die Performanceschicht um. Für das Sammeln des Aufbaus haben wir eine fertige Tabellenvorlage, die wir zu Beginn verschicken.
Wir haben weder einen Nacht noch einen Wochenenddienst und verkaufen keine Reaktionszeit, die wir nicht halten können. Wenn Ihr Shop ein garantiertes Reaktionsfenster braucht, ist das ein eigener Wartungsvertrag und kein Zusatz zu einer Ausfallmeldung.
Wir machen nichts „nebenbei”. Jede neue Sache, die unterwegs auftaucht, bekommt ein eigenes Angebot. Das klingt starr, erspart in der Praxis aber beiden Seiten eine Rechnung, mit der niemand gerechnet hat.
Wir verkaufen auch keinen Neubau als Antwort auf einen Ausfall. Wenn sich die Website in ein paar Stunden reparieren lässt, sagen wir das, auch wenn ein Migrationsvorschlag für uns lukrativer wäre. Eine Migration ergibt dann Sinn, wenn die Kosten für den Betrieb der bestehenden Lösung die Kosten der Umstellung übersteigen, und das lässt sich rechnen statt erahnen.
Wenn die Website von allein zurückkam, ist die Sache nicht erledigt
Ein Ausfall, der ohne Eingriff vorbeigeht, ist schlimmer als einer, der anhält, denn er verschwindet zusammen mit den Beweisen und kehrt im schlechteren Moment zurück. Die drei häufigsten Ursachen sporadischer Ausfälle sehen von außen identisch aus.
Die erste ist ein Ressourcenlimit. Shared Hosting weist der Website eine bestimmte Zahl gleichzeitiger PHP Prozesse zu und weist nach deren Überschreitung weitere Anfragen ab, meist mit Fehler 503 oder 508. Es genügt, dass ein Bot den Shop über die Filter durchläuft, und drei Minuten lang antwortet die Website niemandem. Im Zugriffslog sehen Sie dann eine Serie von Anfragen derselben Adresse in derselben Sekunde.
Die zweite ist eine zyklische Aufgabe. WordPress startet seine eigene Aufgabenplanung anlässlich von Besuchen, eine schwere Aufgabe wie das Erzeugen eines Berichts oder die Synchronisation mit dem Lager trifft also einen zufälligen Nutzer und blockiert ihm die Website. Symptom: Ausfälle zu regelmäßigen Zeiten oder immer nach derselben Aktion im Panel.
Die dritte ist eine externe API ohne Zeitlimit. Ein Plugin fragt den Server des Anbieters ab, der Anbieter hat eine Störung, und Ihre Website wartet so lange auf die Antwort, wie es die PHP Konfiguration erlaubt. Dann ist die Website nicht kaputt, sondern wartet, und kommt von allein zurück, sobald jener Server wieder steht.
Was zu tun ist, um es beim nächsten Mal zu erwischen: Schalten Sie das Fehlerprotokoll in eine Datei ein, bevor es wiederkommt, notieren Sie die genauen Uhrzeiten der Vorfälle der letzten Tage und prüfen Sie, ob sich ein Muster ergibt. Drei Zeitstempel und ein Log sind der Satz, mit dem sich arbeiten lässt. Ohne sie bleibt nur das Warten auf das nächste Mal.
Wie es weitergeht
Wenn Sie schon wissen, was Sie brauchen, gehen Sie direkt auf die passende Seite, statt eine allgemeine Meldung zu schreiben.
- Ausfall, Fehler, etwas funktioniert nicht mehr: Reparatur, Service und technischer Support
- Laufende Betreuung, Updates, Sicherungen und Monitoring: Wartung von WordPress Websites
- Verdacht auf einen Einbruch oder Audit vor dem Livegang: WordPress Sicherheitsaudit
- Die Website läuft, ist aber langsam: WordPress Website beschleunigen
- Neues Projekt oder Neubau: Kontaktseite
Zwei Dinge, die Sie heute erledigen sollten, bevor etwas kaputtgeht
Prüfen Sie, ob sich Ihre Sicherung wiederherstellen lässt. Nicht ob sie existiert, sondern ob sie funktioniert. Ein Backup, das nie jemand eingespielt hat, ist eine Annahme und keine Absicherung, und der Moment des Ausfalls ist der schlechteste Zeitpunkt, das herauszufinden. Die Prozedur dauert eine halbe Stunde: Richten Sie beim selben Hoster eine Testumgebung ein, spielen Sie dort die letzte Sicherung ein, loggen Sie sich ins Panel ein, öffnen Sie drei zufällige Unterseiten und prüfen Sie, ob die Zahl der Beiträge und Bestellungen mit der Produktion übereinstimmt. Notieren Sie, wie lange das gedauert hat, denn das ist Ihre reale Rückkehrzeit nach einem Ausfall, und es ist besser, sie aus einer Probe zu kennen als aus dem Ernstfall.
Die zweite Sache dauert eine Minute: Schreiben Sie auf, wo die Domain liegt, wo das Hosting, wer Zugang dazu hat und wann beides abläuft. Überraschend oft ist ein Ausfall kein Ausfall, sondern eine abgelaufene Domain oder ein abgelaufenes Zertifikat, und die Antwort auf die Frage „bei wem liegt das” kostet einen halben Tag, weil die Person, die es eingerichtet hat, längst nicht mehr in der Firma arbeitet. Ergänzen Sie auf demselben Zettel, wer in WordPress Administrator ist und ob jedes dieser Konten noch gebraucht wird. Konten ehemaliger Mitarbeiter sind der häufigste Einstieg, auf den niemand achtet.
