Erreur lors de l'établissement de la connexion avec la base de données dans WordPress

El mensaje “error al establecer conexión con la base de datos” es de los pocos que WordPress muestra sin rodeos: la web entera desaparece y en su lugar queda esa frase sobre fondo blanco, tanto para tus visitantes como para ti. Significa exactamente lo que dice: el código PHP de WordPress no consigue comunicarse con la base de datos MySQL o MariaDB donde viven tus entradas, páginas, usuarios y ajustes. Sin esa conexión no hay nada que mostrar. Las causas caben en cuatro grupos —credenciales incorrectas en wp-config.php, servidor de base de datos caído o saturado, base de datos corrupta y, con menos frecuencia, disco lleno o un ataque—, y todas tienen solución sin perder contenido. En esta guía las revisamos en orden, del diagnóstico rápido a la reparación, con los fragmentos de configuración exactos que necesitas tocar.

Qué significa el error al establecer conexión con la base de datos

WordPress está dividido en dos mitades: los archivos PHP (el motor) y la base de datos (el contenido). En cada visita, PHP se conecta a MySQL usando cuatro datos guardados en el archivo wp-config.php: nombre de la base de datos, usuario, contraseña y servidor. Si cualquiera de los cuatro es incorrecto, o si el servidor de base de datos no responde, la conexión falla y aparece el error.

Primer diagnóstico en 30 segundos: intenta abrir tudominio.com/wp-admin.

• Si ahí ves un mensaje distinto, del tipo “una o más tablas de la base de datos no están disponibles”, la conexión funciona pero la base de datos está corrupta: salta directamente a la sección de reparación.
• Si ves el mismo error de conexión en todas partes, el problema está en las credenciales o en el servidor: sigue en orden.

Y una pregunta clave antes de tocar nada: ¿qué cambió justo antes? ¿Migraste la web, cambiaste la contraseña del hosting, instalaste algo? El error rara vez aparece solo; en los errores comunes al instalar WordPress, equivocarse con los datos de la base de datos ocupa el primer puesto.

Revisa las credenciales en wp-config.php

Conéctate por FTP o abre el gestor de archivos de tu hosting y localiza wp-config.php en la carpeta raíz de WordPress. Dentro verás cuatro constantes como estas:

/** El nombre de tu base de datos de WordPress */
define( 'DB_NAME', 'nombre_basedatos' );

/** Tu nombre de usuario de MySQL */
define( 'DB_USER', 'usuario_bd' );

/** Tu contraseña de MySQL */
define( 'DB_PASSWORD', 'contraseña_bd' );

/** Host de MySQL (casi siempre localhost) */
define( 'DB_HOST', 'localhost' );

Compara esos valores con los que muestra el panel de tu hosting (en cPanel: sección “Bases de datos MySQL”; en Plesk: “Bases de datos”). Los fallos típicos:

• Prefijos omitidos: en hosting compartido, el nombre real suele ser usuario_nombre (por ejemplo c1234_wp), no solo wp.
• Contraseña cambiada: si alguien regeneró la contraseña del usuario de MySQL desde el panel, wp-config.php sigue guardando la antigua. Crea una nueva desde el panel y actualiza la constante.
• DB_HOST incorrecto: en la mayoría de hostings es localhost, pero algunos (IONOS, SiteGround en ciertos planes, servidores con MySQL separado) usan un host propio del estilo db5001234567.hosting-data.io o una IP, a veces con puerto: 127.0.0.1:3306. El valor correcto aparece en el panel del hosting.

Para comprobar las credenciales sin depender de WordPress, sube por FTP un archivo temporal test-db.php 60. avec ce contenu et ouvrez-le dans le navigateur :

<?php
$conexion = mysqli_connect( 'localhost', 'usuario_bd', 'contraseña_bd', 'nombre_basedatos' );
if ( ! $conexion ) {
    die( 'Fallo de conexión: ' . mysqli_connect_error() );
}
echo 'Conexión correcta';

Si dice “Conexión correcta”, las credenciales están bien y el problema es otro (sigue leyendo). Si falla, el propio mensaje te orienta: “Access denied” apunta a usuario o contraseña incorrectos, y “Unknown database” a un nombre de base de datos equivocado. 58. Supprimez ce fichier dès que vous avez terminé : 57. contient votre mot de passe en texte clair.

Comprueba también que el usuario tiene permisos sobre la base de datos: en cPanel, en “Bases de datos MySQL”, el usuario debe aparecer asignado a la base con todos los privilegios. Tras una migración es habitual crear la base y el usuario pero olvidar vincularlos.

55. Vérifiez le serveur de base de données

54. Si les identifiants sont corrects, le prochain suspect est le serveur MySQL lui-même :

• 53. Serveur en panne : 52. sur un VPS, vous pouvez le vérifier avec systemctl status mysql (ou mariadb51. ) et le redémarrer avec systemctl restart mysql50. . En hébergement mutualisé, vous n'avez pas accès : consultez la page d'état du fournisseur ou ouvrez un ticket.
• 49. Saturation due au trafic ou aux requêtes : 48. un pic de visites, un plugin avec des requêtes lourdes ou une attaque par force brute contre wp-login.php 47. peuvent épuiser les connexions disponibles. L'erreur apparaît par intermittence et disparaît d'elle-même : c'est le schéma typique. La solution de fond est le cache, l'optimisation et, si cela se répète, un plan d'hébergement avec plus de ressources.
• 46. Disque plein : 45. si le serveur ne peut pas écrire, MySQL peut refuser de fonctionner. Vérifiez l'utilisation du disque dans le panneau : les journaux géants et les sauvegardes accumulées sont les remplisseurs habituels.
• 44. phpMyAdmin comme thermomètre : 43. si phpMyAdmin s'ouvre et affiche vos tables, le serveur est en vie et le problème vient des identifiants ou de la corruption. Si phpMyAdmin ne se connecte pas non plus, le serveur est en panne et la balle est dans le camp de l'hébergeur.

42. Réparez une base de données corrompue

41. Les tables peuvent être corrompues par un redémarrage inattendu du serveur, un disque défectueux ou des écritures interrompues. WordPress inclut un mode de réparation intégré. Activez-le en ajoutant cette ligne à wp-config.php, justo encima de la línea “¡Eso es todo, deja de editar!”:

define( 'WP_ALLOW_REPAIR', true );

39. Ensuite, visitez cette adresse dans le navigateur :

https://tudominio.com/wp-admin/maint/repair.php

Verás dos botones: “Reparar base de datos” y “Reparar y optimizar”. Usa el primero (el segundo tarda bastante más). Al terminar, 37. supprimez la ligne de wp-config.php36. : cette page de réparation ne demande pas de mot de passe et ne doit pas rester accessible.

La alternativa manual es phpMyAdmin: selecciona la base de datos, marca todas las tablas y en el desplegable inferior elige “Reparar tabla”. Verás además qué tabla concreta estaba dañada. Antes de reparar nada, si el hosting te lo permite, exporta una copia de la base de datos tal cual está: incluso corrupta, es tu red de seguridad si algo va a peor.

34. Autres causes : migrations, piratages et wp-config endommagé

• 33. Vous venez de migrer le site : 32. 90 % des erreurs de connexion post-migration sont un wp-config.php qui pointe toujours vers la base de données de l'ancien serveur, ou un DB_HOST différent chez le nouveau fournisseur. Vérifiez les quatre constantes avec les données du nouvel hébergement.
• 31. L'URL du site a changé : 30. cela ne provoque pas l'erreur de connexion, mais est souvent confondu ; si le site se charge sans styles ou redirige mal après une migration, le problème est autre (siteurl et home dans la table des options).
• 29. Attaque ou infection : 28. il existe des malwares qui modifient wp-config.php ou suppriment des tables. Si vous trouvez du code étrange dans le fichier, des utilisateurs administrateurs que vous n'avez pas créés ou des tables disparues, traitez l'incident comme un piratage : nous vous guidons dans le 27. guide de nettoyage d'un WordPress attaqué 26. et dans les astuces pour renforcer la sécurité de votre WordPress.
• 25. Restaurer une sauvegarde : 24. si vous avez une copie récente de la base de données, l'importer depuis phpMyAdmin (supprimez d'abord les tables endommagées) est souvent le moyen le plus rapide lorsque la réparation ne fonctionne pas.

23. Liste de contrôle rapide

1. 22. Voyez-vous la même erreur dans /wp-admin21. ? Si le message parle de réparer, allez directement au mode de réparation.
2. 20. Qu'est-ce qui a changé juste avant la panne ? (migration, mots de passe, plugins, mises à jour).
3. 19. Vérifiez DB_NAME, DB_USER, DB_PASSWORD et DB_HOST par rapport au panneau d'hébergement.
4. 18. Testez la connexion avec le script test-db.php (et supprimez-le ensuite).
5. 17. Confirmez que l'utilisateur MySQL a les privilèges sur la base de données.
6. 16. phpMyAdmin se connecte-t-il ? Si non, contactez l'hébergeur : le serveur est en panne.
7. 15. Réparez les tables avec WP_ALLOW_REPAIR et retirez la constante une fois terminé.
8. 14. Si rien ne fonctionne, restaurez la dernière sauvegarde et renforcez la sécurité.

13. Comment prévenir la prochaine frayeur

12. Une fois le site récupéré, consacrez dix minutes à ce que cela ne se reproduise plus. Programmez des sauvegardes automatiques qui incluent la base de données — une copie quotidienne de la base et hebdomadaire des fichiers est un bon point de départ — et vérifiez de temps en temps que ces copies peuvent réellement être restaurées. Activez le cache de page pour réduire drastiquement le nombre de requêtes qui arrivent à MySQL : un site mis en cache supporte des pics de trafic qui mettraient à terre le même site sans cache. Limitez les tentatives d'accès à la connexion pour que les bots ne consomment pas de connexions, et nettoyez régulièrement la base de données (révisions, transients expirés, tables de plugins supprimés), car une base légère se répare plus vite et se corrompt moins. Enfin, notez dans un endroit sûr les identifiants actuels de la base de données : la moitié du temps perdu avec cette erreur est consacrée à chercher où ils se trouvaient.

Questions fréquentes

11. Ai-je perdu mon contenu si cette erreur apparaît ?

10. Presque jamais. L'erreur signifie que WordPress ne peut pas communiquer avec la base de données, pas que la base de données a disparu. Une fois les identifiants corrigés ou les tables réparées, tout le contenu revient. La perte réelle ne se produit que lors de pannes graves de disque sans sauvegarde, et c'est à cela que sert la sauvegarde.

9. Pourquoi l'erreur apparaît-elle et disparaît-elle par intermittence ?

8. Ce schéma intermittent indique un serveur MySQL saturé : trop de connexions simultanées dues à un pic de trafic, un plugin lourd ou des bots attaquant la connexion. Atténuez avec le cache de page, bloquez les bots et, si cela persiste, vous avez besoin de plus de ressources d'hébergement.

7. L'erreur de connexion à la base de données affecte-t-elle le SEO ?

6. Si cela dure quelques minutes, non. Si cela se prolonge des jours, Google finira par désindexer les pages qui renvoient une erreur. C'est pourquoi il convient de le réparer rapidement et, lors de longues pannes planifiées, de servir un code 503 de maintenance à la place.

5. Un plugin peut-il causer cette erreur ?

4. C'est rare directement, mais un plugin peut saturer MySQL avec des requêtes massives ou corrompre ses propres tables. Si l'erreur coïncide avec l'installation d'un plugin spécifique, désactivez-le en renommant son dossier par FTP et observez si le problème cesse.

Conclusion

3. L'erreur de connexion à la base de données fait peur car elle met le site entier hors service, mais son diagnostic est l'un des plus systématiques qui soient dans WordPress : identifiants, serveur, corruption, et dans cet ordre. Avec les quatre constantes de wp-config.php vérifiées par rapport au panneau d'hébergement, le script de test de connexion et le mode de réparation intégré, l'immense majorité des cas sont résolus en moins d'une heure et sans aucune perte de contenu. Les deux leçons à retenir : gardez toujours une copie de sauvegarde récente de la base de données, car cela transforme le pire scénario en une simple formalité, et lorsque l'erreur est intermittente, ne l'ignorez pas : c'est le signe que votre hébergement devient trop petit ou que quelqu'un frappe trop fort à votre porte.