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 ejemploc1234_wp), no solowp. - 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 estilodb5001234567.hosting-data.ioo 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(omariadb) y reiniciarlo consystemctl 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.phppueden 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 e nei trucchi per rafforzare la sicurezza del tuo WordPress.
- Ripristina backup: se hai un backup recente del database, importarlo da phpMyAdmin (elimina prima le tabelle danneggiate) è spesso la via più rapida quando la riparazione non funziona.
Lista di controllo rapida
- Si vede lo stesso errore in
/wp-admin? Se il messaggio parla di riparare, vai direttamente alla modalità di riparazione. - Cosa è cambiato poco prima del guasto? (migrazione, password, plugin, aggiornamenti).
- Verifica DB_NAME, DB_USER, DB_PASSWORD e DB_HOST rispetto al pannello del hosting.
- Prova la connessione con lo script test-db.php (e cancellalo dopo).
- Conferma che l'utente MySQL ha i privilegi sul database.
- phpMyAdmin si connette? Se no, contatta l'hosting: il server è inattivo.
- Ripara le tabelle con WP_ALLOW_REPAIR e rimuovi la costante al termine.
- Se nulla funziona, ripristina l'ultimo backup e rafforza la sicurezza.
Come prevenire il prossimo spavento
Una volta recuperato il sito web, dedica dieci minuti a fare in modo che non si ripeta. Programma backup automatici che includano il database —una copia giornaliera del database e settimanale dei file è un buon punto di partenza— e controlla di tanto in tanto che questi backup possano essere effettivamente ripristinati. Attiva la cache di pagina per ridurre drasticamente il numero di query che arrivano a MySQL: un sito web con cache regge picchi di traffico che metterebbero offline lo stesso sito senza cache. Limita i tentativi di accesso al login affinché i bot non consumino connessioni, e fai una pulizia periodica del database (revisioni, transient scaduti, tabelle di plugin eliminati), perché un database leggero si ripara prima e si corrompe meno. Infine, annota in un luogo sicuro le credenziali attuali del database: la metà del tempo perso in questo errore si impiega a cercare dove fossero.
Preguntas frecuentes
Ho perso il mio contenuto se appare questo errore?
Quasi mai. L'errore significa che WordPress non può comunicare con il database, non che il database sia scomparso. Corrette le credenziali o riparate le tabelle, tutto il contenuto torna. La perdita reale si verifica solo in caso di gravi guasti al disco senza backup, e per questo c'è il backup.
Perché l'errore appare e scompare a tratti?
Questo schema intermittente indica un server MySQL saturo: troppe connessioni simultanee a causa di un picco di traffico, un plugin pesante o bot che attaccano il login. Mitiga con la cache di pagina, blocca i bot e, se persiste, hai bisogno di più risorse di hosting.
L'errore nello stabilire la connessione al database influisce sul SEO?
Se dura minuti, no. Se si prolunga per giorni, Google finirà per deindicizzare le pagine che restituiscono errore. Per questo conviene risolverlo presto e, in caso di lunghi down pianificati, servire un codice 503 di manutenzione al suo posto.
Un plugin può causare questo errore?
Direttamente è raro, ma un plugin può saturare MySQL con query massive o corrompere le proprie tabelle. Se l'errore coincide con l'installazione di un plugin specifico, disattivalo rinominando la sua cartella via FTP e osserva se il problema cessa.
Conclusión
L'errore nello stabilire la connessione al database spaventa perché mette offline l'intero sito web, ma la sua diagnosi è tra le più sistematiche che ci siano in WordPress: credenziali, server, corruzione, e in quest'ordine. Con le quattro costanti di wp-config.php verificate rispetto al pannello del hosting, lo script di test della connessione e la modalità di riparazione integrata, la stragrande maggioranza dei casi si risolve in meno di un'ora e senza alcuna perdita di contenuto. Le due lezioni da imparare sono: mantieni sempre un backup recente del database, perché trasforma lo scenario peggiore in una semplice pratica, e quando l'errore è intermittente non ignorarlo: è il segnale che il tuo hosting sta diventando insufficiente o che qualcuno sta bussando troppo forte alla tua porta.