Du rufst deine Seite auf und da steht nur diese eine Zeile: „Fehler beim Herstellen einer Verbindung zur Datenbank“. Kein Backend, kein Login, nichts. Genau in diesem Moment fangen die meisten an, wild in Dateien rumzustochern – und machen es schlimmer. Ich habe den WordPress Datenbank-Fehler selbst schon auf zig Kundenprojekten gehabt, von billigem Shared Hosting bis zu eigenen VPS. Die Reihenfolge, in der du vorgehst, entscheidet, ob du in 5 Minuten oder in 3 Stunden wieder online bist.
Eins vorweg, weil es die Panik sofort halbiert: In 9 von 10 Fällen ist das kein Datenverlust. Es ist ein Konfigurations- oder Serverproblem. Deine Beiträge, Nutzer und Einstellungen liegen weiter in der MySQL- bzw. MariaDB-Datenbank – WordPress kommt nur gerade nicht ran.
Was der Fehler beim Herstellen einer Verbindung zur Datenbank wirklich bedeutet
WordPress speichert alles in einer Datenbank: Beiträge, Seiten, Nutzer, Einstellungen, Plugin-Optionen. Bei jedem Seitenaufruf baut PHP im Hintergrund einen Handshake zu dieser Datenbank auf. Scheitert der, wirft PHP die Meldung aus und die Seite bleibt weiß.
Der entscheidende Punkt, den fast alle übersehen: Die Meldung sagt dir nur, dass die Verbindung nicht klappt. Warum sie nicht klappt, steht ausschließlich im Server-Log oder im WordPress-Debug-Log. Wenn du wirklich schnell sein willst, schaltest du zuerst das Debugging ein, statt blind in der wp-config.php rumzustochern.
Und noch was: Der Verbindungsaufbau passiert, bevor irgendein Plugin oder Theme geladen wird. Wer bei diesem Fehler seine Plugins durchsucht, verschwendet Zeit.
Die vier ehrlichen Ursachen für den WordPress Datenbank-Fehler
- Die Zugangsdaten in der wp-config.php stimmen nicht mehr – Passwort geändert, Datenbank umgezogen, Tippfehler beim Kopieren.
- Der Datenbankserver selbst läuft nicht oder ist überlastet (MariaDB abgestürzt, max_connections erreicht).
- Der Datenbank-User hat keine Rechte mehr, typisch nach einem Hosting-Umzug.
- Der Hostname in der wp-config.php zeigt noch auf localhost, obwohl die Datenbank längst woanders liegt.
Check 1: Läuft die Datenbank überhaupt?
Bevor du irgendeine Datei anfasst, geh ins Kontrollpanel deines Hosters (Plesk, cPanel, bei Hetzner oder IONOS oft ein eigenes Panel) und schau nach, ob der Datenbankdienst aktiv ist. Bei vielen Managed-Hosts gibt es einen Statuspunkt „MySQL/MariaDB“. Steht der auf rot, ist die Sache klar – dann liegt es nicht an deiner WordPress-Installation.
Hast du einen eigenen Server, reicht auf der Kommandozeile ein systemctl status mariadb. Läuft der Dienst nicht, startest du ihn mit systemctl start mariadb neu und prüfst sofort, ob die Seite wieder lädt. Das ist der schnellste Fix überhaupt, wenn der Dienst tatsächlich abgestürzt war.
Check 2: Stimmen die Zugangsdaten in der wp-config.php?
Öffne die wp-config.php im Hauptverzeichnis per FTP oder Dateimanager. Interessant sind genau vier Zeilen: DB_NAME, DB_USER, DB_PASSWORD und DB_HOST. Tippfehler hier sind die Nummer eins unter allen Ursachen für den WordPress Fehler beim Herstellen einer Verbindung zur Datenbank.
Vergleiche die Werte Zeichen für Zeichen mit dem, was dein Hoster in der Datenbankverwaltung anzeigt. Besonders gerne falsch: Das Passwort enthält Sonderzeichen wie $ oder `, und beim Kopieren geht ein Zeichen verloren. Setz das Passwort im Hoster-Panel neu und trag es sauber in die wp-config.php ein – das ist meist der schnellste Fix.
Der klassische localhost-Fehler
Sehr viele Umzüge scheitern an genau diesem Detail: Bei manchen Hostern (IONOS, 1&1 und Co.) gehört in DB_HOST nicht localhost, sondern eine konkrete Adresse wie db12345678.hosting-data.io. Steht bei dir noch „localhost“ und die Datenbank liegt extern, kannst du tippen bis du schwarz wirst – es wird nichts helfen.
Check 3: Manuelle Verbindung mit phpMyAdmin testen
Der ehrlichste Test überhaupt: Öffne phpMyAdmin (oder einen MySQL-Client wie DBeaver) und logge dich mit exakt denselben Daten ein, die in der wp-config.php stehen. Klappt der Login, liegt das Problem eher bei WordPress oder beim User-Recht. Klappt er nicht, weißt du mit 100 % Sicherheit: Es ist ein Problem auf Datenbank- oder Zugangsdatenebene, nicht in deiner WordPress-Installation.
Ein Hinweis, den viele übersehen: Prüfe in phpMyAdmin, ob der Datenbank-User überhaupt Rechte auf die Datenbank hat. Nach einem Umzug vergessen Hoster manchmal, den User der DB zuzuordnen – dann existieren Zugangsdaten, aber sie dürfen nichts. In dem Fall hilft nur ein Ticket beim Support oder das Neuanlegen der Zuordnung.
Check 4: Die Radikalkur mit wp-config.php umbenennen
Wenn gar nichts zieht, gibt es einen Trick, den ich bei hartnäckigen Fällen gerne nutze: Benenne die wp-config.php per FTP um, z. B. in wp-config-alt.php. Ruf jetzt deine Website auf. WordPress erkennt die fehlende Konfiguration und startet den Installationsassistenten, der dich nach Datenbankname, User und Passwort fragt.
Trägst du dort die korrekten Werte ein, erstellt WordPress eine neue wp-config.php mit den richtigen Details. Wichtig: Lösche die umbenannte alte Datei danach, sonst hast du doppelte Konfigurationsreste im Verzeichnis liegen – das kann später zu Geisterfehlern führen.
Mein ehrlicher Rat: Sichere vor jedem Eingriff in die wp-config.php die Datei und, wenn möglich, die Datenbank über phpMyAdmin als SQL-Dump. Das dauert zwei Minuten und erspart dir im schlimmsten Fall einen Totalschaden.
Was du bei diesem WordPress Fehler NICHT machen solltest
Ein WordPress Datenbank-Fehler verleitet zu hektischen Aktionen. Ich habe schon Installationen gesehen, bei denen Leute aus Panik WordPress komplett neu installiert haben – und dabei alle Inhalte verloren, obwohl nur ein Passwort falsch war. Lass die Finger von einem Neuaufsetzen, solange du nicht sicher weißt, dass die Datenbank wirklich hin ist.
Ebenfalls sinnlos: wildes Durchsuchen der Plugins. Der Verbindungsaufbau passiert lange, bevor irgendein Plugin geladen wird. Wenn du diese Meldung siehst, spielen Plugins und Theme schlicht keine Rolle.
Wenn nichts hilft: So findest du den echten Grund
Öffne in der wp-config.php den Debug-Modus, indem du define(‘WP_DEBUG’, true); und define(‘WP_DEBUG_LOG’, true); ergänzt. Nach dem nächsten Seitenaufruf findest du im Ordner wp-content eine Datei debug.log. Dort steht oft der konkrete MySQL-Fehlercode, etwa „Access denied for user“ oder „Can’t connect to MySQL server“.
Mit diesem Code kannst du gezielt googeln oder deinen Hoster kontaktieren – und kommst in zwei Minuten ans Ziel, statt stundenlang zu raten. Genau diese Methode trennt Leute, die ihre WordPress-Datenbank selbst reparieren, von denen, die auf den Support warten.
Und noch eins: Tritt der Fehler sporadisch auf, also mal geht die Seite, mal nicht, ist fast immer der Server überlastet – dann hilft kein Passwort, sondern mehr RAM oder ein Hosting-Wechsel. Aber das ist eine andere Baustelle.
Für 2026 gilt: Wer regelmäßig Backups zieht, hat bei einem WordPress Datenbank-Fehler nie wirklich Stress. Wer es nicht tut, spielt irgendwann russisches Roulette mit seiner Seite.
