Eine Anleitung pro Fehler, für alle, deren Website gerade nicht erreichbar ist. Jede beginnt mit der Originalmeldung und führt die Ursachen in sinnvoller Prüfreihenfolge auf.
Vergleichen Sie den genauen Wortlaut. Eine leere Seite und ein 500-Fehler sehen im Browser ähnlich aus, haben aber verschiedene Ursachen.
WordPress geladen, lesen wp-config.php, und konnte keine Antwort von MySQL erhalten. Jede Seite auf der Website ist leer, bis sie kann.
Eine völlig leere Seite ohne Fehler und ohne HTML. PHP stoppte mitten in der Anfrage und die Nachricht ging zu einem Protokoll, das Sie noch nicht gelesen haben.
Der Webserver versuchte, die Seite zu produzieren, etwas ging schief innerhalb, und es gab einen Statuscode statt eines Grundes.
Der Webserver erreichte PHP und PHP antwortete nicht. Nginx oder Apache berichtet von einer Konversation, die endete, bevor sie begann.
PHP funktionierte noch, als der Webserver das Warten aufgab. Nichts stürzte ab - es dauerte einfach länger als das Timeout erlaubte.
PHP erreichte die Grenze, die es gegeben wurde und stoppte. Die Zahl in der Nachricht ist das Limit, nicht der Betrag, den Ihre Website benötigt.
PHP stoppte ein Skript, das länger lief als es erlaubt war. Das Limit hat seinen Job gemacht; die Frage ist, ob der Job in eine Web-Anfrage gehörte.
Der Browser folgte der Weiterleitung nach der Weiterleitung und stoppte. Zwei Dinge stimmen nicht überein, wo diese URL leben soll, und jeder ist zuversichtlich.
WordPresss eigener fataler Fehler-Handler. Es fing einen Absturz, ersetzte die Seite mit diesem Satz und erzählte niemandem außer der Admin-E-Mail.
WordPress schreibt eine .maintenance Datei vor einem Update und entfernt sie danach. Das Update wurde nicht beendet, also ist die Datei immer noch da.
PHP lehnte die Datei ab, bevor WordPress ein Byte davon sah. Die Nummer in der Nachricht ist PHPs Decke, nicht WordPress.
Die Datei wurde übertragen, dann scheiterte etwas, während WordPress die Miniaturansichten generierte. Die Nachricht ist die gleiche, egal was das war.
Die Seite kam über HTTPS an und bat dann um etwas über HTTP. Browser blockieren die aktiven Teile und lassen das Vorhängeschloss für den Rest fallen.
Die Veröffentlichungszeit verging und nichts passierte. WP-Cron ist keine Uhr – sie läuft, wenn eine Anfrage eintrifft, und keine Anfrage eingetroffen ist.
WordPress hatte eine funktionierende Datenbankverbindung und verlor sie mitten in der Anfrage. Die Abfrage ist selten fehlerhaft; die Verbindung ist es.
WordPress hat eine HTTP-Anfrage an seine eigene Adresse gestellt und keine Antwort erhalten. Mehrere Funktionen hängen davon ab, dass es funktioniert.
Etwas beantwortete die Anfrage, die nicht WordPress war, oder beantwortete sie mit HTML. Der Editor hört auf zu arbeiten, weil es für alles von der API abhängt.
Der Upload wurde abgelehnt, bevor etwas geschrieben wurde. Entweder steht die Erweiterung nicht auf der erlaubten Liste oder der Inhalt der Datei stimmt nicht mit der Erweiterung überein.
Die Anfrage wurde verstanden und abgelehnt. Die Ablehnung kam vom Webserver, einer Firewall oder einer Berechtigungsregel - WordPress ist selten involviert.
Ein sehr spezifisches Muster mit einer sehr kurzen Liste von Ursachen. Ihre Posts existieren immer noch; der Router davor ist kein Routing.
Die meisten dieser Fehler entstehen durch die Konfiguration. Verwaltetes Hosting mit täglichen Backups, Staging auf Knopfdruck und Limits pro Website nimmt Ihnen häufige Ursachen ab.