fixeador

Guía práctica

WordPress no conecta con la base de datos

Cuando WordPress muestra error al establecer conexión con la base de datos, separa credenciales, servidor MySQL y estado del hosting.

Síntoma y contexto

WordPress muestra Error establishing a database connection o Error al establecer conexión con la base de datos. La web deja de cargar porque PHP no puede hablar con MySQL o MariaDB, que es donde WordPress guarda entradas, páginas, usuarios, opciones y configuración. El servidor web puede estar vivo y responder, pero WordPress no puede completar la consulta inicial que necesita para arrancar.

Este error no es lo mismo que una pantalla blanca. En una pantalla blanca puede haber un fatal error de PHP, un plugin incompatible o falta de memoria. En el error de base de datos, el problema está en la conexión, en el servidor MySQL, en las credenciales o en el estado de las tablas. Si tu síntoma es distinto, mira WordPress pantalla blanca o la guía general de web caída.

La causa suele aparecer después de una migración, cambio de contraseña del usuario MySQL, restauración incompleta, actualización del hosting, disco lleno o caída temporal del servicio de base de datos. Antes de editar wp-config.php a ciegas, conviene capturar el mensaje exacto, saber si afecta al frontend y al panel /wp-admin, y revisar qué cambió en las últimas horas. No pegues contraseñas de base de datos ni accesos al hosting en mensajes o formularios.

Causas probables

  1. Credenciales incorrectas en wp-config.php. DB_NAME, DB_USER, DB_PASSWORD o DB_HOST no coinciden con la base de datos real. Puede pasar tras migrar o cambiar contraseña en el panel.
  2. Servidor MySQL o MariaDB caído. El hosting puede estar activo, pero el servicio de base de datos detenido, reiniciándose o saturado.
  3. Host de base de datos equivocado. No todos los hostings usan localhost. Algunos requieren un hostname interno como mysql.tudominio.com o una IP privada.
  4. Disco lleno o cuota agotada. MySQL puede dejar de escribir tablas temporales o logs si el disco, inodos o cuota de base de datos están llenos.
  5. Usuario sin permisos suficientes. El usuario existe, pero perdió permisos sobre la base de datos o se restauró una copia sin grants correctos.
  6. Tablas corruptas. Cortes de servidor, falta de disco o caídas durante escritura pueden dañar tablas, especialmente en instalaciones antiguas o con mucho tráfico.
  7. Prefijo de tablas no coincide. El $table_prefix de wp-config.php apunta a un prefijo que no existe en la base de datos restaurada.
  8. Firewall o red interna entre web y base de datos. En arquitecturas separadas, el servidor web puede no alcanzar el host MySQL por reglas de red o cambio de IP.

Checklist copiable

DIAGNÓSTICO WORDPRESS BASE DE DATOS - [dominio.com]
Fecha: ___________  Hora: ___________

1. SÍNTOMA
   [ ] Error al establecer conexión con la base de datos
   [ ] Frontend afectado
   [ ] wp-admin afectado
   [ ] Intermitente

2. CAMBIOS RECIENTES
   [ ] Migración hosting
   [ ] Cambio contraseña MySQL
   [ ] Restauración copia
   [ ] Actualización WordPress / plugins
   [ ] Ninguno conocido

3. WP-CONFIG (sin pegar secretos)
   DB_NAME existe: Sí / No
   DB_USER existe: Sí / No
   DB_HOST esperado: ___________
   Table prefix esperado: ___________
   [ ] No he compartido DB_PASSWORD

4. SERVIDOR BASE DE DATOS
   Proveedor: ___________
   MySQL/MariaDB activo: Sí / No / No sé
   phpMyAdmin abre: Sí / No

5. RECURSOS
   Disco lleno: Sí / No / No sé
   Cuota DB superada: Sí / No / No sé
   Inodos llenos: Sí / No / No sé

6. LOGS
   Error principal: ___________
   Access denied / connection refused / table crashed / otro

7. NO ENVIAR
   [ ] Sin contraseñas de wp-config.php
   [ ] Sin acceso al hosting
   [ ] Sin dumps completos con datos personales

Qué capturar antes de escribir

Captura la pantalla del error, la URL exacta y si también falla /wp-admin. Anota proveedor de hosting, tipo de panel (cPanel, Plesk, WordPress gestionado, VPS), y cualquier cambio reciente. Si tienes acceso a archivos, revisa wp-config.php pero no copies el valor de DB_PASSWORD. Puedes indicar si DB_HOST es localhost u otro hostname, y si los nombres de base de datos y usuario parecen coincidir con el panel.

Si hay logs, guarda las líneas relevantes: Access denied for user, Connection refused, Unknown database, Too many connections o mensajes de tabla dañada. No adjuntes un dump completo de la base de datos salvo que se haya acordado un canal seguro y una necesidad concreta. Para una primera revisión basta con capturas del panel censuradas y errores textuales sin credenciales.

Comandos y paneles útiles

En hosting con panel, revisa:

  • cPanel -> MySQL Databases: Nombre de base de datos, usuario asociado y permisos.
  • cPanel -> phpMyAdmin: Si la base abre y las tablas existen. No ejecutes reparaciones sin copia.
  • Plesk -> Databases: Usuario, host, cuota y acceso a phpMyAdmin.
  • WordPress gestionado: Estado del entorno, logs PHP, herramientas de reparación o restauración.
  • VPS: Estado de MariaDB/MySQL, disco, memoria y logs del servicio.

En un VPS, si tienes acceso SSH:

# Estado de MySQL o MariaDB
sudo systemctl status mysql
sudo systemctl status mariadb

# Espacio disponible
df -h
df -i

# Logs recientes de base de datos
sudo journalctl -u mysql -n 80 --no-pager
sudo journalctl -u mariadb -n 80 --no-pager

# Probar conexión, escribe la contraseña solo en el prompt local
mysql -h DB_HOST -u DB_USER -p DB_NAME

Si WordPress está en hosting compartido, evita comandos que el proveedor no documenta. Usa phpMyAdmin, el panel de bases de datos y los logs disponibles. Si el panel indica cuenta suspendida, cuota excedida o mantenimiento del servidor, anótalo antes de cambiar archivos.

Pasos de diagnóstico por escenario

Access denied for user

El servidor MySQL responde, pero rechaza el usuario o la contraseña. Compara DB_USER y DB_NAME con el panel. En cPanel, los nombres suelen tener prefijo de cuenta, por ejemplo cuenta_wp. Si cambias la contraseña del usuario MySQL en el panel, actualiza DB_PASSWORD en wp-config.php, pero no la compartas por correo ni formulario. Si no estás seguro, crea un usuario nuevo con permisos mínimos sobre esa base y actualiza WordPress durante una ventana controlada.

Unknown database o base no encontrada

WordPress intenta abrir una base que no existe o no está asignada al usuario. Tras una migración, puede haberse importado el dump con otro nombre o haber restaurado archivos sin restaurar base de datos. Verifica en phpMyAdmin que la base contiene tablas como wp_options, wp_posts y wp_users, o el prefijo personalizado que use tu instalación. Si el prefijo no coincide, revisa $table_prefix.

Connection refused o timeout al host MySQL

El servidor web no puede llegar al host de base de datos. Si usas localhost, confirma que MySQL corre en la misma máquina. Si el proveedor exige un host específico, usa el valor documentado en el panel. En VPS separados, revisa firewall interno, grupos de seguridad y que MySQL escucha en la interfaz correcta. No abras MySQL públicamente sin necesidad; si debe ser remoto, limita origen y usa credenciales específicas.

Too many connections o fallo intermitente

El sitio conecta a veces y falla en picos. Puede haber demasiadas peticiones, consultas lentas, bots, plugins pesados o límite bajo del hosting. Revisa logs de acceso, procesos PHP y uso de recursos. En WordPress, plugins de estadísticas, builders y tareas cron pueden saturar la base. Si también hay formularios que fallan durante esos picos, revisa formulario que no envía porque puede ser el mismo origen saturado.

Disco lleno o cuota de base de datos agotada

Un disco al 100 por cien puede impedir que MySQL escriba archivos temporales o repare tablas. Libera espacio con cuidado: logs rotados, copias antiguas y cachés pueden ocupar mucho, pero no borres la carpeta de datos de MySQL. En hosting compartido, revisa cuota de archivos y cuota específica de base de datos. Después de liberar espacio, reinicia el servicio solo si tienes claro el impacto o si el proveedor lo indica.

Tablas dañadas

Si el log menciona marked as crashed, repair o errores de tabla, haz copia antes de reparar. WordPress tiene una herramienta con WP_ALLOW_REPAIR, y phpMyAdmin permite reparar tablas MyISAM. En InnoDB, la reparación puede requerir otro enfoque y conviene no improvisar en producción. Si el daño viene de disco lleno o cortes repetidos, arregla primero la causa para que no vuelva a romperse.

Cuándo escalar

Escala o escribe por el formulario con categoría Web o despliegue cuando el error persiste tras confirmar que la base existe, el usuario tiene permisos y MySQL está activo. También conviene pedir revisión si el sitio está en producción, si hay que tocar wp-config.php sin copia reciente, si el hosting muestra disco lleno, o si los logs apuntan a corrupción de tablas.

Envía URL, proveedor, hora del fallo, cambios recientes, mensaje de log y capturas censuradas del panel. No envíes contraseñas de base de datos, credenciales de WordPress, accesos de hosting ni dumps completos con datos personales. Relacionado: WordPress pantalla blanca, web caída, formulario no envía.

¿Sigues atascado después de la checklist?

Escribir el problema Volver al triage