Error al establecer conexión con la base de datos en 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 con este contenido y ábrelo en el navegador:

<?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. Borra este archivo en cuanto termines: contiene tu contraseña en texto plano.

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.

Comprueba el servidor de base de datos

Si las credenciales son correctas, el siguiente sospechoso es el propio servidor MySQL:

• Servidor caído: en un VPS puedes verificarlo con systemctl status mysql (o mariadb) y reiniciarlo con systemctl restart mysql. En hosting compartido no tienes acceso: revisa la página de estado del proveedor o abre un ticket.
• Saturación por tráfico o consultas: un pico de visitas, un plugin con consultas pesadas o un ataque de fuerza bruta contra wp-login.php pueden agotar las conexiones disponibles. El error aparece a ratos y desaparece solo: es el patrón típico. La solución de fondo es caché, optimización y, si se repite, un plan de hosting con más recursos.
• Disco lleno: si el servidor no puede escribir, MySQL puede negarse a trabajar. Revisa el uso de disco en el panel: registros gigantes y copias de seguridad acumuladas son los llenadores habituales.
• phpMyAdmin como termómetro: si phpMyAdmin abre y muestra tus tablas, el servidor vive y el problema está en credenciales o corrupción. Si phpMyAdmin tampoco conecta, el servidor está caído y la pelota está en el tejado del hosting.

Repara una base de datos corrupta

Las tablas pueden corromperse por un reinicio inesperado del servidor, un disco con problemas o escrituras interrumpidas. WordPress incluye un modo de reparación integrado. Actívalo añadiendo esta línea a wp-config.php, justo encima de la línea «¡Eso es todo, deja de editar!»:

define( 'WP_ALLOW_REPAIR', true );

Después visita esta dirección en el navegador:

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, elimina la línea de wp-config.php: esa página de reparación no pide contraseña y no debe quedar accesible.

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.

Otras causas: migraciones, hackeos y wp-config dañado

• Acabas de migrar la web: el 90 % de los errores de conexión post-migración son un wp-config.php que aún apunta a la base de datos del servidor antiguo, o un DB_HOST distinto en el nuevo proveedor. Revisa las cuatro constantes con los datos del hosting nuevo.
• La URL del sitio cambió: esto no provoca el error de conexión, pero suele confundirse; si la web carga sin estilos o redirige mal tras migrar, el problema es otro (siteurl y home en la tabla de opciones).
• Ataque o infección: hay malware que modifica wp-config.php o borra tablas. Si encuentras código extraño en el archivo, usuarios administradores que no creaste o tablas desaparecidas, trata el incidente como un hackeo: te guiamos en la guía de limpieza de un WordPress atacado y en los trucos para reforzar la seguridad de tu WordPress.
• Restaurar copia de seguridad: si tienes copia reciente de la base de datos, importarla desde phpMyAdmin (elimina antes las tablas dañadas) es a menudo la vía más rápida cuando la reparación no funciona.

Lista de comprobación rápida

1. ¿Se ve el mismo error en /wp-admin? Si el mensaje habla de reparar, ve directo al modo reparación.
2. ¿Qué cambió justo antes del fallo? (migración, contraseñas, plugins, actualizaciones).
3. Verifica DB_NAME, DB_USER, DB_PASSWORD y DB_HOST contra el panel del hosting.
4. Prueba la conexión con el script test-db.php (y bórralo después).
5. Confirma que el usuario MySQL tiene privilegios sobre la base de datos.
6. ¿phpMyAdmin conecta? Si no, contacta con el hosting: el servidor está caído.
7. Repara las tablas con WP_ALLOW_REPAIR y retira la constante al acabar.
8. Si nada funciona, restaura la última copia de seguridad y refuerza la seguridad.

Cómo prevenir el próximo susto

Una vez recuperada la web, dedica diez minutos a que no se repita. Programa copias de seguridad automáticas que incluyan la base de datos —una copia diaria de la base y semanal de los archivos es un buen punto de partida— y comprueba de vez en cuando que esas copias se pueden restaurar de verdad. Activa la caché de página para reducir drásticamente el número de consultas que llegan a MySQL: una web cacheada aguanta picos de tráfico que tumbarían a la misma web sin caché. Limita los intentos de acceso al login para que los bots no consuman conexiones, y haz limpieza periódica de la base de datos (revisiones, transients caducados, tablas de plugins eliminados), porque una base ligera se repara antes y se corrompe menos. Por último, apunta en un lugar seguro las credenciales actuales de la base de datos: la mitad del tiempo perdido en este error se va en buscar dónde estaban.

Preguntas frecuentes

¿He perdido mi contenido si aparece este error?

Casi nunca. El error significa que WordPress no puede hablar con la base de datos, no que la base de datos haya desaparecido. Corregidas las credenciales o reparadas las tablas, todo el contenido vuelve. La pérdida real solo ocurre en fallos graves de disco sin copia de seguridad, y para eso está la copia.

¿Por qué el error aparece y desaparece a ratos?

Ese patrón intermitente apunta a un servidor MySQL saturado: demasiadas conexiones simultáneas por un pico de tráfico, un plugin pesado o bots atacando el login. Mitiga con caché de página, bloquea los bots y, si persiste, necesitas más recursos de hosting.

¿El error al establecer conexión con la base de datos afecta al SEO?

Si dura minutos, no. Si se prolonga días, Google acabará desindexando páginas que devuelven error. Por eso conviene arreglarlo pronto y, en caídas largas planificadas, servir un código 503 de mantenimiento en su lugar.

¿Puede un plugin causar este error?

Directamente es raro, pero un plugin puede saturar MySQL con consultas masivas o corromper tablas propias. Si el error coincide con la instalación de un plugin concreto, desactívalo renombrando su carpeta por FTP y observa si el problema cesa.

Conclusión

El error al establecer conexión con la base de datos asusta porque tumba la web entera, pero su diagnóstico es de los más sistemáticos que hay en WordPress: credenciales, servidor, corrupción, y en ese orden. Con las cuatro constantes de wp-config.php verificadas contra el panel del hosting, el script de prueba de conexión y el modo de reparación integrado, la inmensa mayoría de los casos se resuelven en menos de una hora y sin pérdida alguna de contenido. Las dos lecciones que conviene llevarse: mantén siempre una copia de seguridad reciente de la base de datos, porque convierte el peor escenario en un trámite, y cuando el error sea intermitente no lo ignores: es el aviso de que tu hosting se está quedando pequeño o de que alguien está llamando demasiado fuerte a tu puerta.