WordPress: Fehler beim Aufbau der Datenbankverbindung

Statt deiner Seite steht da nur ein nackter Satz: „Error establishing a database connection.” Sonst nichts. Kein Layout, kein Logo, keine Navigation. Das sieht nach Totalausfall aus, ist aber fast immer harmlos: WordPress findet schlicht keine Verbindung zur MySQL- bzw. MariaDB-Datenbank, in der all deine Inhalte stecken. Die Inhalte sind nicht weg — die Leitung dorthin ist nur unterbrochen. In den meisten Fällen hast du das in 20 Minuten wieder geflickt.

Soforthilfe

Bevor du an Konfigurationsdateien gehst:

1. Halt Zugang bereit. Du brauchst gleich FTP/SFTP oder den Dateimanager deines Hosters und den Zugang zum Hosting-Panel (Plesk, cPanel, o.ä.) mit phpMyAdmin.
2. Sichere wp-config.php per Download, bevor du eine Zeile änderst. So kommst du jederzeit auf den Ausgangsstand zurück.
3. Prüf, ob der Hoster gerade eine Störung hat. Lädt die Startseite und /wp-admin beide den exakt gleichen Datenbankfehler? Dann liegt es selten an dir — schau auf die Statusseite deines Hosters, bevor du tiefer gräbst.

Erst diagnostizieren: Wer ist betroffen?

Der schnellste Hinweis steckt in /wp-admin. Ruf das Backend direkt auf:

• Frontend und Backend zeigen denselben Fehler → die Verbindung selbst ist tot. Ursache liegt bei Zugangsdaten, DB-Host oder einem überlasteten Datenbankserver (siehe unten).
• Das Backend zeigt stattdessen „One or more database tables are unavailable. The database may need to be repaired” → die Verbindung steht grundsätzlich, aber eine Tabelle ist beschädigt. Dann brauchst du die Reparatur, nicht die Zugangsdaten-Prüfung.

Diese eine Unterscheidung spart dir die Hälfte der Sucherei.

Ursache 1: Falsche Zugangsdaten in wp-config.php

WordPress liest vier Werte aus der wp-config.php, um sich anzumelden: DB_NAME, DB_USER, DB_PASSWORD und DB_HOST. Stimmt einer davon nicht, ist sofort Schluss. Das passiert typischerweise nach einem Server-Umzug, einem Hoster-Wechsel oder wenn jemand das Datenbank-Passwort im Panel geändert hat, ohne es in der Konfig nachzuziehen.

Öffne die wp-config.php im Hauptverzeichnis und gleiche die Werte Zeile für Zeile mit dem ab, was im Hosting-Panel unter „Datenbanken” steht. Achte auf unsichtbare Stolperfallen: ein Leerzeichen vor dem Passwort, ein Sonderzeichen, das beim Kopieren verstümmelt wurde, oder ein Datenbankname mit Hoster-Präfix (z.B. kunde123_wp statt nur wp). Setz das Passwort im Panel zur Not neu und trag es frisch ein.

Ursache 2: DB_HOST stimmt nicht

DB_HOST ist der häufigste stille Übeltäter, weil der Wert von Hoster zu Hoster anders ist. Bei vielen Standard-Setups ist es schlicht localhost. Manche Hoster verlangen aber 127.0.0.1, einen eigenen Hostnamen wie db5012.hosting.de, einen Port (localhost:3307) oder sogar einen Socket-Pfad. Wenn localhost partout nicht greift, probier 127.0.0.1 — und umgekehrt. Den korrekten Wert findest du in der Datenbank-Übersicht deines Panels; rate hier nicht, sondern übernimm exakt das, was dort steht.

Ursache 3: Datenbankserver überlastet oder down

Manchmal liegt es gar nicht an deiner Konfig, sondern am Server. Auf günstigen Shared-Hosting-Paaketen teilen sich viele Seiten einen MySQL-Server. Schießt der Traffic hoch oder hängt ein Plugin in einer Endlosschleife, läuft der Server in „Too many connections” und weist neue Verbindungen ab — auch deine. Symptom: Der Fehler kommt sporadisch, mal lädt die Seite, mal nicht.

Hier kannst du selbst wenig drehen. Schreib den Support an, nenn den genauen Zeitpunkt und frag, ob der DB-Server am Limit war oder ob dein Konto an die Verbindungsgrenze stößt. Wenn das regelmäßig passiert, ist das Paket zu klein für deine Seite.

Ursache 4: Beschädigte Datenbank reparieren

Zeigt das Backend den „needs to be repaired”-Hinweis (siehe Diagnose), hat WordPress ein eingebautes Reparatur-Werkzeug. Du schaltest es per Konstante frei. Trag in die wp-config.php über der Zeile /* That's all, stop editing! */ ein:

define( 'WP_ALLOW_REPAIR', true );

Ruf dann https://deine-domain.de/wp-admin/maint/repair.php auf — ohne eingeloggt zu sein, das ist Absicht. Wähl „Repair Database” (oder „Repair and Optimize”, das dauert länger). WordPress geht die MyISAM-Tabellen durch und repariert beschädigte Indizes. Wichtig: Lösch die Zeile danach sofort wieder, sonst kann jeder im Netz dein Reparatur-Tool ungeschützt aufrufen.

Ursache 5: Nutzerrechte der Datenbank

Zugangsdaten und Host stimmen, trotzdem keine Verbindung? Dann hat der DB-Nutzer womöglich keine Rechte auf die Datenbank. Das kommt vor, wenn ein Nutzer nach einem Umzug zwar existiert, aber der Datenbank nicht zugewiesen wurde. Im Panel (oder in phpMyAdmin unter „Rechte”) prüfst du, ob der DB_USER der DB_NAME-Datenbank mit vollen Rechten zugeordnet ist. Fehlt die Zuordnung, weist du sie zu — fertig.

Debug: Verbindung gezielt testen

Statt zu raten, testest du die Verbindung direkt — losgelöst von WordPress. Leg eine Datei dbtest.php ins Hauptverzeichnis und trag deine vier Werte ein:

<?php
$host = 'localhost';      // exakt DB_HOST
$user = 'dein_db_user';   // exakt DB_USER
$pass = 'dein_passwort';  // exakt DB_PASSWORD
$name = 'deine_db';       // exakt DB_NAME

$mysqli = @new mysqli($host, $user, $pass, $name);
if ($mysqli->connect_errno) {
    echo 'FEHLER: ' . $mysqli->connect_error;
} else {
    echo 'OK — Verbindung steht.';
}

Die connect_error-Meldung sagt dir genau, woran es scheitert: „Access denied” → Nutzer/Passwort oder Rechte. „Unknown database” → falscher DB_NAME. „Can’t connect to MySQL server” → falscher Host oder Server down. Lösch dbtest.php danach wieder, sie enthält dein Klartext-Passwort.

Wenn du gleichzeitig sehen willst, was WordPress intern meldet, aktivier vorübergehend das Logging in der wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Die Meldungen landen dann in wp-content/debug.log, nicht auf der öffentlichen Seite.

So vermeidest du das künftig

• Automatische Backups von Dateien und Datenbank, täglich, an einem Ort außerhalb des Servers. Eine beschädigte Tabelle ist mit einem frischen Dump in Minuten ersetzt.
• Zugangsdaten dokumentieren. Wer das DB-Passwort im Panel ändert, muss wp-config.php nachziehen — schreib dir den Ablauf auf.
• Uptime-Monitoring einrichten (z.B. ein Dienst, der minütlich pingt). Du erfährst vom Datenbankfehler, bevor der erste Kunde anruft.
• Passendes Hosting wählen. Häufen sich „Too many connections”, ist nicht WordPress schuld, sondern das zu kleine Paket.

Oder: Schluss mit WordPress-Bränden

Ehrlich gesagt entsteht dieser ganze Fehler nur durch eine Bauweise, die im Hintergrund permanent eine Datenbank befragen muss. Eine mit Astro gebaute Seite arbeitet anders: Sie hat kein PHP, keine Plugins und keine Live-Datenbank — die Seiten liegen fertig als statische Dateien auf dem Server. „Error establishing a database connection” kann dort schlicht nicht auftreten, weil es nichts gibt, was eine Verbindung aufbauen müsste. Wenn dich solche Ausfälle regelmäßig kosten, lohnt der Umstieg: webAION migriert deine WordPress-Seite zu Astro zum Festpreis und übernimmt dabei deine Inhalte. Wenn du gerade mitten im Feuer stehst und erst mal nur diesen einen Fehler wegbekommen willst, findest du alle WordPress-Fehler im Überblick — und arbeitest dich oben durch die Ursachen.