Je krijgt “Error establishing a database connection” en je hele site ligt plat, inclusief je dashboard. Geen paniek: dit is geen ramp, maar een verbindingsprobleem tussen WordPress en de database. In 2026 zie ik dit nog steeds vaak, vooral na een verhuizing of een serverstoring. Hieronder lees je hoe je een WordPress database fout oplossen aanpakt zonder willekeurig van alles te proberen.
De melding is expres vaag. WordPress verbergt de echte fout om inloggegevens niet aan bezoekers te lekken. De oorzaak zit bijna altijd in een van deze vier: de databaseserver draait niet, de gegevens in wp-config.php kloppen niet, de gebruiker heeft geen rechten, of de database is beschadigd. Werk die volgorde af en je vindt het meestal binnen tien minuten.
Stap 1: draait de databaseserver eigenlijk wel?
Voordat je iets aanpast, check of MySQL of MariaDB nog leeft. Log in op cPanel, Plesk of DirectAdmin en kijk of de database actief is. Op een VPS of cloudserver gebruik je via SSH: systemctl status mysql of systemctl status mariadb. Staat de service stil of herstart hij steeds, dan zit het probleem op serverniveau en niet in WordPress.
Bij gedeelde hosting kun je hier niks aan doen. Open dan een ticket bij je provider en vraag of er onderhoud of een storing is. Dit is de enige oorzaak waarbij je zelf geen oplossing hebt, en het overkomt echt veel mensen. Een WordPress database fout oplossen begint dus altijd met de vraag: is de database zelf bereikbaar?
Stap 2: wp-config.php is de hoofdverdachte
In wp-config.php staan vier regels die je moet controleren: DB_NAME, DB_USER, DB_PASSWORD en DB_HOST. Eén spatie te veel, een verkeerd aanhalingsteken of een wachtwoord met een apostrof erin en de verbinding klapt eruit. Dit gebeurt vooral na een verhuizing naar een nieuwe host, wanneer de prefix van de databasenaam verandert van iets als wp_ naar user123_wp.
Mijn advies: open het bestand via FTP of je bestandsbeheerder en vergelijk elke waarde letterlijk met wat je hostingprovider je heeft gestuurd. Let extra op DB_HOST. Bij de meeste hosts is dat localhost, maar sommige werken met 127.0.0.1 of een socket-pad. Staat daar nog de oude hostnaam van je vorige provider, dan faalt de verbinding gegarandeerd. Dit is de meest voorkomende reden dat een WordPress database fout oplossen nodig is.
Wachtwoorden met rare tekens: escapen of vermijden
Een wachtwoord met een backslash of een dollar-teken kan de boel slopen zodra je het in de config plakt. Hosting-wachtwoorden kun je vaak niet kiezen, dus maak in je hostingpaneel een nieuwe databasegebruiker aan met een wachtwoord zonder leestekens. Kost twee minuten en scheelt een hoop gedoe.
Nog iets wat mensen missen: staat er per ongeluk een tweede set DB-regels in het bestand? Bij sommige migratietools worden gegevens onderaan toegevoegd terwijl de oude regels bovenaan blijven staan. PHP gebruikt de laatste definitie, dus je lijkt de juiste gegevens te hebben terwijl er andere worden geladen. Zoek in je editor op DB_NAME en kijk of het maar één keer voorkomt.
Zet tijdelijk WP_DEBUG aan
Met define(‘WP_DEBUG’, true); en define(‘WP_DEBUG_DISPLAY’, true); zie je soms de echte MySQL-foutmelding in plaats van de generieke boodschap. Handig, maar zet dit direct weer uit als je klaar bent: bezoekers zien anders serverpaden en gebruikersnamen. Dit is een tijdelijke diagnose, geen oplossing.
Stap 3: test handmatig met phpMyAdmin
Log in op phpMyAdmin via je hostingpaneel en probeer de database te openen met exact dezelfde gegevens die in wp-config.php staan. Lukt dat niet, dan ligt het niet aan WordPress maar aan de inloggegevens of de rechten van de gebruiker. Werkt het wel, dan is er iets anders aan de hand: selecteer alle tabellen en kies Repair table, of gebruik via de commandoregel mysqlcheck -u gebruiker -p –all-databases –auto-repair. Dit is de snelste manier om een WordPress database fout oplossen die door een beschadigde tabel komt, bijvoorbeeld na een servercrash of een volgelopen schijf.
De ingebouwde reparatie van WordPress
Je kunt WordPress ook zelf laten kijken. Voeg in wp-config.php de regel define(‘WP_ALLOW_REPAIR’, true); toe en ga naar jewebsite.nl/wp-admin/maint/repair.php. Je ziet dan twee knoppen: alleen repareren, of repareren en optimaliseren. Vergeet daarna niet die regel weer te verwijderen, want die pagina is openbaar bereikbaar zonder inlog. Dat is een lek dat je niet wilt.
Stap 4: wp-config.php hernoemen als noodoplossing
Als niks helpt, hernoem je wp-config.php naar bijvoorbeeld wp-config-oud.php en bezoek je je site. WordPress start dan de installatiewizard en vraagt om de databasegegevens. Je krijgt zo een hagelnieuw configbestand met de juiste waarden erin. Vul exact dezelfde gegevens in en je bestaande content blijft gewoon staan — WordPress raakt je database niet kwijt door alleen een configbestand opnieuw te maken.
Waar het misgaat: mensen kiezen hier per ongeluk “installeren” in plaats van verbinden en zetten zo een lege database op. Lees dus goed welke knop je indrukt.
