Error al establecer una conexión con la base de datos en WordPress: cómo solucionarlo

Cargas tu sitio y cada página —tanto la portada como wp-admin— queda reemplazada por una sola frase gris: Error al establecer una conexión con la base de datos. No se renderiza nada, porque no puede. WordPress ni siquiera llegó a construir una página.

Este es el modelo mental que lo convierte en un arreglo rápido. WordPress guarda todo tu contenido —entradas, páginas, ajustes, usuarios— en una base de datos MySQL, no en archivos. En cada petición lee cuatro datos de acceso de wp-config.php, se conecta a esa base de datos y saca lo que necesita. Este error significa que se intentó esa conexión y fue rechazada. La solución consiste en averiguar por qué fue rechazada, y solo hay tres posibilidades.

Las tres causas, por orden de probabilidad

1. Una credencial incorrecta en wp-config.php: el resultado habitual de cambiar de hosting.
2. El servidor de base de datos está caído o sobrecargado: el resultado habitual de que no hayas cambiado nada por tu parte.
3. La base de datos está dañada: menos frecuente, y se manifiesta de otra forma.

Repásalas en ese orden.

Paso 1: revisa las cuatro credenciales

Abre wp-config.php en la raíz de tu sitio por SFTP o con el administrador de archivos de tu hosting. Cuatro líneas definen la conexión:

define( 'DB_NAME', 'your_database_name' );
define( 'DB_USER', 'your_database_user' );
define( 'DB_PASSWORD', 'your_database_password' );
define( 'DB_HOST', 'localhost' );

Cada una de ellas debe coincidir exactamente con lo que te asignó tu hosting. Abre la sección de bases de datos del panel de control de tu hosting (en cPanel es “MySQL Databases”) y compara carácter por carácter:

• DB_NAME: los alojamientos suelen anteponer al nombre el de tu cuenta, como cpaneluser_wpdb. El prefijo forma parte del nombre.
• DB_USER: se aplica el mismo prefijo, y el usuario debe estar asignado a esa base de datos, no solo existir.
• DB_PASSWORD: el culpable más frecuente con diferencia. Si tienes dudas, restablécela en el panel de control y pega el nuevo valor. Vigila los espacios finales y las comillas tipográficas.
• DB_HOST: no des por hecho localhost. Muchos alojamientos usan un servidor de base de datos dedicado con una dirección como mysql.yourhost.com, a veces con un :port. El panel de control muestra el valor correcto.

Como este archivo es justo donde viven esos cuatro valores, la forma más segura de regenerar un wp-config.php limpio y con las comillas correctas es el generador de wp-config.php: rellena los cuatro campos de la base de datos y pega el resultado sobre el bloque antiguo.

Este paso, por sí solo, soluciona el error después de casi cualquier migración, porque unas credenciales que eran correctas en el hosting antiguo son incorrectas en el nuevo.

Paso 2: confirma que el servidor de base de datos está realmente activo

Si las credenciales son correctas y el error persiste —sobre todo si apareció solo, sin ningún cambio por tu parte—, el sospechoso es el propio servidor de base de datos.

En alojamiento compartido esto es habitual y casi siempre temporal: el servicio MySQL se satura durante un pico de tráfico o alcanza su límite de conexiones por cuenta y empieza a rechazar las nuevas conexiones. Suele recuperarse en unos minutos. Recarga tras esperar un poco antes de hacer nada drástico.

Para comprobar si las credenciales son válidas al margen de WordPress, deja un pequeño script junto a wp-config.php:

<?php
$link = mysqli_connect('localhost', 'your_database_user', 'your_database_password');
if (!$link) {
    die('Connection failed: ' . mysqli_connect_error());
}
echo 'Connected — the server and credentials are fine.';

Usa tu DB_HOST, DB_USER y DB_PASSWORD reales. Si imprime Connected, tus datos de acceso funcionan y el problema está en otra parte (una base de datos dañada, Paso 3). Si imprime un error de conexión, el mensaje te dice cuál: “Access denied” significa un usuario o una contraseña incorrectos; “Can’t connect to MySQL server” significa un host incorrecto o un servicio realmente caído: es el momento de contactar con tu hosting. Borra el script en cuanto termines.

Paso 3: repara una base de datos dañada

Una señal separa la corrupción de un problema de conexión: la portada carga pero wp-admin muestra el error, o al revés. Si la conexión estuviera realmente rechazada, ambas estarían caídas. Una diferencia así apunta a tablas dañadas.

WordPress tiene una herramienta de reparación integrada. Añade una línea a wp-config.php, por encima del comentario “stop editing”:

define( 'WP_ALLOW_REPAIR', true );

Después visita esta URL directamente en tu navegador:

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

Se carga sin inicio de sesión —esa es la idea, ya que puedes estar bloqueado fuera— y ofrece “Repair Database” y “Repair and Optimize Database”. Ejecútala.

Después borra de inmediato esa línea de wp-config.php. Mientras esté presente, cualquiera en internet puede acceder a esa URL y ejecutar una reparación de tu base de datos. Esto no es una limpieza opcional; es cerrar un agujero que acabas de abrir.

Paso 4: cuando la reparación ni siquiera conecta

Si la propia página de reparación muestra el error de conexión, no hay nada que reparar: no se puede acceder a la base de datos en absoluto, así que vuelves al Paso 1 o al Paso 2. Llegado ese punto, la jugada fiable es restaurar la base de datos desde la copia de seguridad más reciente de tu hosting. La mayoría de los paneles de control guardan instantáneas diarias automáticas de la base de datos; una restauración de anoche es casi siempre más rápida y segura que perseguir una corrupción a la que no te puedes conectar.

Consejos que puedes ignorar tranquilamente

“Reinstala WordPress y ya”. Este error tiene que ver con la conexión a la base de datos, no con los archivos del núcleo. Reinstalar reemplaza precisamente los archivos que funcionan bien y no toca nada de lo que está roto.

“Sube el límite de memoria de PHP”. El agotamiento de memoria es un error distinto, con un mensaje distinto. Subir el límite no hace nada por una conexión de base de datos rechazada y solo tapa el hecho de que nunca revisaste las credenciales.

“Vacía la caché”. El fallo ocurre en PHP antes de que ninguna caché pueda servir una página. Vaciar la caché no cambia nada mientras la conexión esté rechazada; solo merece la pena hacerlo después de que el sitio vuelva.

“Edita la base de datos directamente para arreglarlo”. Recurrir a phpMyAdmin para editar tablas a mano antes de haber confirmado siquiera que la conexión funciona es la manera de que una caída temporal se convierta en una pérdida de datos permanente. Confirma primero la conexión; toca los datos al final, y solo desde una copia de seguridad.

¿Sigues atascado?

Si las credenciales se verifican con el script de prueba, el servidor está activo, y la reparación conecta y no informa de errores, pero el sitio sigue mostrando el mensaje, el sospechoso que queda es un plugin que habla con la base de datos por su propia conexión: un plugin de caché o de base de datos que guardó un host obsoleto. Renombra wp-content/plugins a plugins-off por SFTP para descartarlo. Si el error desaparece, ve reintroduciendo los plugins de uno en uno hasta que vuelva.