WordPress: Fehler beim Aufbau der Datenbankverbindung

Statt Ihrer 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 Ihre Inhalte stecken. Die Inhalte sind nicht weg, die Leitung dorthin ist nur unterbrochen. In den meisten Fällen haben Sie das in 20 Minuten wieder geflickt.

Soforthilfe

Bevor Sie an Konfigurationsdateien gehen:

1. Halten Sie Zugang bereit. Sie brauchen gleich FTP/SFTP oder den Dateimanager Ihres Hosters und den Zugang zum Hosting-Panel (Plesk, cPanel, o.ä.) mit phpMyAdmin.
2. Sichern Sie wp-config.php per Download, bevor Sie eine Zeile ändern. So kommen Sie jederzeit auf den Ausgangsstand zurück.
3. Prüfen Sie, 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 Ihnen, schauen Sie auf die Statusseite Ihres Hosters, bevor Sie tiefer graben.

Erst diagnostizieren: Wer ist betroffen?

Der schnellste Hinweis steckt in /wp-admin. Rufen Sie 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 brauchen Sie die Reparatur, nicht die Zugangsdaten-Prüfung.

Diese eine Unterscheidung spart Ihnen 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.

Öffnen Sie die wp-config.php im Hauptverzeichnis und gleichen Sie die Werte Zeile für Zeile mit dem ab, was im Hosting-Panel unter „Datenbanken” steht. Achten Sie 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). Setzen Sie das Passwort im Panel zur Not neu und tragen Sie 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, probieren Sie 127.0.0.1, und umgekehrt. Den korrekten Wert finden Sie in der Datenbank-Übersicht Ihres Panels; raten Sie hier nicht, sondern übernehmen Sie exakt das, was dort steht.

Ursache 3: Datenbankserver überlastet oder down

Manchmal liegt es gar nicht an Ihrer 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 Ihre. Symptom: Der Fehler kommt sporadisch, mal lädt die Seite, mal nicht.

Hier können Sie selbst wenig drehen. Schreiben Sie den Support an, nennen Sie den genauen Zeitpunkt und fragen Sie, ob der DB-Server am Limit war oder ob Ihr Konto an die Verbindungsgrenze stößt. Wenn das regelmäßig passiert, ist das Paket zu klein für Ihre Seite.

Ursache 4: Beschädigte Datenbank reparieren

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

define( 'WP_ALLOW_REPAIR', true );

Rufen Sie dann https://ihre-domain.de/wp-admin/maint/repair.php auf, ohne eingeloggt zu sein, das ist Absicht. Wählen Sie „Repair Database” (oder „Repair and Optimize”, das dauert länger). WordPress geht die MyISAM-Tabellen durch und repariert beschädigte Indizes. Wichtig: Löschen Sie die Zeile danach sofort wieder, sonst kann jeder im Netz Ihr 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üfen Sie, ob der DB_USER der DB_NAME-Datenbank mit vollen Rechten zugeordnet ist. Fehlt die Zuordnung, weisen Sie sie zu, fertig.

Debug: Verbindung gezielt testen

Statt zu raten, testen Sie die Verbindung direkt, losgelöst von WordPress. Legen Sie eine Datei dbtest.php ins Hauptverzeichnis und tragen Sie Ihre 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 Ihnen 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öschen Sie dbtest.php danach wieder, sie enthält Ihr Klartext-Passwort.

Wenn Sie gleichzeitig sehen wollen, was WordPress intern meldet, aktivieren Sie 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 vermeiden Sie 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, schreiben Sie sich den Ablauf auf.
• Uptime-Monitoring einrichten (z.B. ein Dienst, der minütlich pingt). Sie erfahren 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 solche Ausfälle Sie regelmäßig kosten, lohnt der Umstieg: webAION migriert Ihre WordPress-Seite zu Astro zum Festpreis und übernimmt dabei Ihre Inhalte. Wenn Sie gerade mitten im Feuer stehen und erst mal nur diesen einen Fehler wegbekommen wollen, finden Sie alle WordPress-Fehler im Überblick und arbeiten sich oben durch die Ursachen.

Weiterlesen: Wenn die Seite danach dauerhaft langsam oder anfällig bleibt, hilft der Ratgeber WordPress langsam und ein Blick auf Webseite ohne WordPress, was geht.