Error al establecer una conexión con la base de datos en WordPress
Tu sitio muestra una línea de texto sobre fondo blanco y nada más. Ni diseño, ni menú, ni panel de administración. Solo esa frase.
Lo que significa es más concreto de lo que parece: WordPress sigue ahí, en el servidor, y funciona. Los archivos están. Lo que no consigue es hablar con la base de datos, que es donde viven tus entradas, tus páginas, tus pedidos y tus usuarios.
El sitio no se borró; se quedó sin poder leer su contenido. Por eso el pánico habitual —"perdí todo"— casi nunca es cierto. Lo que sí es cierto es que mientras dure este error, no hay sitio, no hay panel, y si vendes, no hay ventas.
Por qué aparece este error
Son seis causas posibles y se distinguen entre sí en minutos. Esta tabla es para que entiendas qué te vamos a decir cuando nos contactes, no para que intentes arreglarlo a ciegas y rompas algo.
| Causa probable | Qué pasó en el servidor | Señal que lo delata |
|---|---|---|
| Credenciales cambiadas | El usuario, la contraseña o el nombre de la BD en wp-config.php ya no coinciden. | Pasó justo después de migrar, de cambiar de hosting o de que alguien "ordenara" el panel. |
| Servidor de BD caído | El servicio de MySQL o MariaDB se apagó o bloqueó en el servidor central. | Otros sitios alojados en el mismo servidor también fallan. Muy común en hosting compartido. |
| Se agotaron las conexiones | Demasiadas peticiones simultáneas, o procesos que no cierran lo que abren (Timeout). | Va y viene. A ratos carga bien y a ratos no. Suele empeorar abruptamente en horas pico. |
| Tablas corruptas | Una o varias tablas SQL se dañaron, casi siempre tras una caída súbita o un disco lleno. | El sitio carga a medias, o falla solo el panel de administración, o da error de "Reparación". |
| Disco lleno (Espacio) | No hay espacio para escribir nuevos datos, y la base de datos se protege apagándose. | Hubo lentitud extrema y errores raros al subir imágenes los días previos a la caída. |
Alguien tocó wp-config.php | Edición manual con un error de sintaxis (una comilla de menos), o archivo alterado. | Pasó después de que alguien editara archivos a mano, o hay sospecha de infección de malware. |
La causa que más veces resulta ser es el servidor de base de datos caído o saturado, no las contraseñas. Pero la que más veces intentan "arreglar" primero es el wp-config.php — y ahí es donde empiezan los problemas de verdad.
Qué revisar antes de tocar nada
Haz estas tres comprobaciones. No rompen nada y te ahorran horas de frustración:
¿Falla el sitio o falla el servidor completo?
Si tienes otros sitios web alojados en el mismo plan de hosting, ábrelos. Si todos muestran exactamente el mismo error, el problema no es de tu WordPress: el servidor de bases de datos de tu proveedor se cayó. La llamada es para ellos.
¿Falla también el panel de administración?
Intenta entrar a tudominio.com/wp-admin/. Si el panel te da un mensaje distinto (por ejemplo, que "la base de datos necesita reparación"), la causa es corrupción de tablas. Si da exactamente el mismo error que la portada, la conexión está rota desde la raíz.
¿Qué cambió en las últimas 48 horas?
Piensa: ¿Hubo una migración? ¿Un cambio de contraseña en el panel de tu hosting (cPanel)? ¿Una actualización grande de plugins? ¿Importaste miles de productos? En este error, el "qué cambió" acierta la causa nueve de cada diez veces.
Con esas tres respuestas, quien te atienda ya sabe por dónde empezar. Si nos escribes al WhatsApp, esas son justo las tres cosas que te vamos a preguntar primero.
Lo que NO hay que hacer
Esta sección vale más que la anterior. Aquí es donde un error técnico recuperable se convierte en la pérdida total de tu sitio.
No hagas esto bajo ninguna circunstancia:
- No reinstales WordPress. Es la reacción más frecuente en pánico y la más destructiva. WordPress no está roto; está buscando una base de datos que no responde. Reinstalar no arregla la base de datos y sí sobrescribe tu configuración actual.
- No "restaures" un respaldo sin saber de cuándo es. Si el respaldo es de hace una semana y tu tienda de WooCommerce tuvo pedidos desde entonces, acabas de borrar esos pedidos para siempre. Hay que saber qué se perdió y desde cuándo antes de restaurar a ciegas.
- No cambies contraseñas al azar en
wp-config.php. Si las credenciales originales eran correctas y las sustituyes por otras inventadas probando suerte, pierdes el único dato fiable que teníamos para diagnosticar el problema real. - No ejecutes la "reparación" sin hacer una copia antes. WordPress trae una herramienta de reparación (activada vía
WP_ALLOW_REPAIR). Funciona, pero también puede terminar de destruir una tabla que estaba dañada a medias. Primero se copia, después se repara. (Además, si olvidas quitar la constante, dejas la herramienta expuesta a ataques públicos). - No borres carpetas para "hacer espacio" en caliente. Si el disco de tu hosting está lleno y empiezas a borrar a ciegas, te llevarás por delante archivos críticos. El resultado es que sumarás un problema de 404 masivos encima de tu problema de base de datos.
Cómo atendemos este error
| Paso | Qué hacemos | Por qué importa |
|---|---|---|
| 1. Confirmación externa | Revisamos qué responde tu dominio y las cabeceras HTTP antes de pedirte una sola contraseña. | Aislamos si el problema es de tu código o de la infraestructura del hosting. |
| 2. Protección (Backup) | Copia de seguridad del estado actual. Archivos y BD, tal como estén de rotos, antes de tocar nada. | Si un intento de reparación falla, tenemos cómo volver al punto de partida. Apostar sin red es negligencia. |
| 3. Diagnóstico Forense | Auditoría de credenciales, estado del servicio MySQL, conexiones concurrentes y espacio en disco. | Encontramos la causa real, no solo parches temporales. |
| 4. Reparación Activa | Restablecemos credenciales, reparamos tablas corruptas, o escalamos el ticket al hosting con evidencia. | El sitio vuelve a cargar y conecta correctamente. |
| 5. Verificación | Comprobamos que el panel carga y, más importante, que no falte contenido ni pedidos. | Que el sitio cargue no significa que esté íntegro. |
| 6. Causa Raíz | Determinamos por qué pasó y qué ajustes evitan que vuelva a ocurrir en el futuro. | Si fue saturación de procesos, reparar sin ajustar el servidor significa que se volverá a caer en horas. |
El paso 2 no es burocracia técnica. Quien entra a reparar una base de datos MySQL sin extraer una copia de seguridad primero está jugando a la ruleta con tu negocio.
Cuándo esto NO es lo tuyo
Te lo decimos rápido para que no pierdas tiempo si tu pantalla no dice exactamente "Error al establecer una conexión...":
Preguntas frecuentes
Casi con absoluta seguridad, NO. Este error significa que el código de WordPress "perdió la comunicación" con la base de datos, no que la base haya desaparecido. En la enorme mayoría de los casos, tu contenido está intacto esperando que reparemos la conexión.
A veces, y esa es precisamente la trampa. Si la causa fue una saturación momentánea de tráfico o procesos, el sitio volverá a la vida en cuanto baje la carga... y volverá a caerse en el siguiente pico. Que "se arregle solo" no significa que esté resuelto.
Pasa seguido, y a veces tienen razón. La diferencia la hace la evidencia técnica: cuando extraemos los registros de error (logs) y medimos los procesos SQL en el momento del fallo, la conversación con tu hosting deja de ser "opinión contra opinión" y se vuelve un dato duro innegable.
Sí. Este error bloquea el acceso al panel /wp-admin/ por definición, pero no bloquea el servidor. Con el acceso a tu panel de hosting (cPanel/Plesk/SFTP) se trabaja directamente en la base. Si no tienes acceso al hosting, háznoslo saber de inmediato.
No siempre, y jamás lo recomendamos "en caliente" en medio de una caída. Si la causa es que tu servidor actual se quedó muy pequeño para el tráfico que recibes, te lo diremos con números. Cambiar de servidor durante una crisis solo añade riesgos innecesarios.
Depende 100% de la causa raíz, por lo que no damos plazos mágicos sin auditar primero. Lo que sí garantizamos es el tiempo de reacción: primera respuesta humana por WhatsApp en menos de 30 minutos (en horario de atención) con un primer análisis.
Entonces la caída no era el problema, era solo el síntoma de un mal mayor. Un sitio que tira la base de datos recurrentemente necesita vigilancia proactiva y perfilado de consultas, no reparaciones aisladas. Eso lo resolvemos mediante un plan de mantenimiento y administración.
¿Qué necesitas ahora mismo?
Tu sitio web está caído ahora mismo. Mándanos el dominio por WhatsApp. Revisamos qué responde tu servidor y te decimos qué vemos, antes de pedirte un solo acceso.
Escribir por WhatsAppEl sitio carga a ratos, o ya se recuperó pero quieres saber por qué pasó para que no se repita. El diagnóstico aísla la causa raíz real de tu servidor.
Pedir diagnóstico técnicoLas bases de datos rara vez colapsan sin avisar: dejan rastros durante días. Lo que falta es alguien que esté monitoreando esas señales por ti.
Mantenimiento WebÚltima revisión del procedimiento: octubre de 2026.