error de base de datos wordpress
Identificar rápidamente lo que ves (y lo que implica)
Cuando WordPress muestra Error al establecer una conexión con la base de datos , significa que PHP (WordPress) no consigue establecer una sesión válida con MySQL/MariaDB. En concreto, el sitio ya no puede leer sus contenidos (artículos, páginas, ajustes, usuarios), ya que todo está almacenado en la base de datos.
Este mensaje es voluntariamente genérico. Las causas más frecuentes se reparten en unas pocas familias: credenciales incorrectas en wp-config.php, servidor de base de datos no disponible, base de datos corrupta, límites de recursos alcanzados, o incidente del lado del proveedor de hosting. El objetivo es, por tanto, determinar dónde la cadena se rompe: WordPress → red → servidor de BD → autenticación → tablas.
Paso 1: verificar el acceso al sitio y al back-office (indicio valioso)
Primer reflejo: prueba tanto la página de inicio como /wp-admin/. Si el front está KO pero el admin se abre, el problema puede ser parcial (caché, tabla específica, sobrecarga). Si todo está KO, oriéntate más bien hacia un problema de conexión global (credenciales, servidor de BD caído, fallo del hosting).
Otro indicio: algunos proveedores de hosting muestran una página de error diferente, o un mensaje del tipo Error establishing a database connection más bruto. Anota la hora, el contexto (actualización, pico de tráfico, migración) y cualquier cambio reciente (plugin, tema, manipulación DNS, restauración de copia de seguridad).
Paso 2: controlar los parámetros de conexión en wp-config.php
En la mayoría de los casos, el error proviene de un parámetro incorrecto en wp-config.php. Las constantes a verificar son:
DB_NAME (nombre de la base de datos), DB_USER (usuario), DB_PASSWORD (contraseña), DB_HOST (host del servidor de base de datos).
Puntos de atención sobre DB_HOST (a menudo subestimado)
En muchos alojamientos, DB_HOST vale localhost. Pero no es universal: puede tratarse de una IP, de un nombre de host interno (p. ej. mysqlXX), o de un socket específico. Tras una migración, un cambio de plan o el paso a un entorno gestionado, este valor puede cambiar.
Verificar sin equivocarse
Compare los valores de wp-config.php con los indicados en el panel de control del proveedor de alojamiento (base, usuario, contraseña, host). Si recientemente ha regenerado una contraseña de MySQL, no olvide reflejarla aquí. Un solo error tipográfico basta.
Si necesita una guía paso a paso del lado del alojamiento, puede consultar Resolver el error Error al conectar con la base de … que detalla las comprobaciones típicas y las rutas habituales en las interfaces de los proveedores de alojamiento.
Paso 3: probar la conexión MySQL fuera de WordPress
La idea es simple: determinar si el problema proviene de WordPress o de la propia base. Si puede conectarse a MySQL con las mismas credenciales, entonces WordPress falla por una razón secundaria (recursos, corrupción, plugin, etc.). Si la conexión falla, el problema está efectivamente a nivel de accesos/servidor.
Métodos posibles según su acceso:
1) Vía phpMyAdmin: intente abrir la base y recorrer las tablas.
2) Vía SSH: un comando del tipo mysql -h HOST -u USER -p (si el proveedor de alojamiento lo permite).
3) Vía la interfaz del proveedor de alojamiento: algunos ofrecen una prueba de conexión o una página de estado de MySQL.
Más información sobre nuestros servicios de mantenimiento de sitios WordPress
Si phpMyAdmin muestra un error de autenticación, se trata de un par usuario/contraseña incorrecto, un usuario sin permisos o una base de datos inexistente. Si phpMyAdmin no carga o tarda muchísimo, el servicio puede estar caído o saturado.
Paso 4: verificar el estado del servidor (caída, sobrecarga, límites)
Cuando las credenciales son correctas, el error suele aparecer durante una indisponibilidad temporal: reinicio de MySQL, mantenimiento, sobrecarga de CPU/RAM, demasiadas conexiones simultáneas, disco lleno o límite de procesos alcanzado en un hosting compartido.
Señales indicativas:
– El problema aparece de golpe sin modificaciones recientes.
– El sitio vuelve solo después de unos minutos y luego vuelve a caer.
– Otros sitios en el mismo alojamiento están afectados.
– Las páginas tardan mucho y luego terminan en error.
En este escenario, verifique el estado del proveedor de alojamiento, las incidencias en curso y las métricas si tiene acceso (CPU, RAM, I/O, número de conexiones). Puede ser necesaria una optimización o pasar a un plan más robusto si el error vuelve con regularidad.
Paso 5: activar un diagnóstico limpio (sin agravar la caída)
Si puede editar wp-config.php, puede activar temporalmente el debug para obtener indicios (con precaución en producción). El objetivo no es mostrar detalles a los visitantes, sino registrar errores.
En la práctica, se prefiere activar un registro (archivo) en lugar de la visualización. Una vez recopilada la información, restablezca los parámetros iniciales para evitar cualquier fuga de información.
Más allá del debug, piense también en los logs del servidor (error_log, logs de PHP-FPM, logs de MySQL si están disponibles). Un error Too many connections o Access denied orientará inmediatamente el diagnóstico.
Paso 6: reparar una base de datos potencialmente corrupta
Una corrupción de tablas (a menudo tras un crash, un disco saturado, un corte, o un problema de hardware) puede provocar errores de conexión o comportamientos similares. WordPress ofrece un modo de reparación, y MySQL también ofrece herramientas (según el acceso).
Reparación mediante WordPress (opción integrada)
WordPress puede iniciar una reparación de las tablas si se activa un parámetro específico en wp-config.php, Esto puede resolver tablas marcadas como crashed . Importante: desactive esta opción en cuanto termine la reparación.
Reparación mediante phpMyAdmin
En phpMyAdmin, puede seleccionar todas las tablas e iniciar Reparar la tabla . Si varias tablas están dañadas, esto puede bastar para volver a poner el sitio en línea.
Para un enfoque más amplio (y escenarios avanzados), esta guía es útil: ¿Corregir Error de conexión a la base de datos ? Explora las causas comunes, las comprobaciones del lado del servidor y las pistas cuando las soluciones simples no son suficientes.
Paso 7: aislar un conflicto de plugin/tema (cuando el servidor de BD parece OK)
Un plugin o un tema puede desencadenar una tormenta de consultas, abrir demasiadas conexiones o provocar errores fatales que se parecen a un problema de BD (por ejemplo, timeouts repetidos que acaban por tumbar MySQL en un servidor pequeño). Aunque el mensaje hable de base de datos, la causa inicial puede ser de la aplicación.
Probar sin romper: método recomendado
Si tiene un entorno de staging, reproduzca el problema y desactive los elementos uno a uno. En producción, hágalo solo si está seguro de poder volver atrás rápidamente (copia de seguridad, acceso FTP/SSH, etc.).
Para un enfoque prudente antes de añadir o modificar extensiones, puede apoyarse en un protocolo de pruebas antes de la puesta en producción, para reducir drásticamente los incidentes que acaban afectando a la base.
Eliminar o sustituir las extensiones de riesgo
Los plugins obsoletos o abandonados pueden generar consultas ineficientes, errores SQL o incompatibilidades con una versión reciente de PHP/MySQL. A la larga, esto debilita el conjunto, sobre todo si su servidor tiene recursos limitados.
Si necesita hacer limpieza, siga un procedimiento controlado: copia de seguridad, desactivación, verificación de las dependencias, eliminación y, después, observación. Al respecto, aquí tiene un recurso interno útil: un método para retirar extensiones antiguas correctamente.
Paso 8: comprobar los prefijos de las tablas y la coherencia tras una migración
Después de una migración o una restauración, puede ocurrir que el prefijo de las tablas ya no coincida con el declarado en wp-config.php,. WordPress busca entonces tablas que no existen, lo que puede interpretarse como un problema de base (o derivar en errores relacionados).
En wp-config.php, la variable $table_prefix debe corresponder exactamente a las tablas presentes (por ejemplo wp_, wp123_, etc.). Verifique en phpMyAdmin: si sus tablas empiezan por wpabc_ pero el archivo indica wp_, corrija uno de los dos (por lo general, se corrige el archivo, salvo estrategia específica).
Paso 9: asegurarse de que la base existe y de que el usuario tiene los permisos
A veces, la base se ha eliminado (error humano), renombrado, o restaurado con otro nombre. Otras veces, el usuario MySQL existe, pero no tiene privilegios sobre la base (GRANT faltante, usuario recreado, permisos restablecidos por el proveedor de hosting, etc.).
Más información sobre nuestros servicios de mantenimiento de sitios WordPress
En phpMyAdmin o en el panel del proveedor de hosting, compruebe:
– que la base listada corresponde a DB_NAME ;
– que el usuario DB_USER está bien asociado a esta base;
– que dispone de los permisos necesarios (como mínimo SELECT/INSERT/UPDATE/DELETE/CREATE/ALTER según las operaciones de WordPress).
Paso 10: distinguir el incidente puntual del problema estructural
Si el error ocurre una vez y luego desaparece, es plausible un mantenimiento o un reinicio de la BD por parte del proveedor de hosting. En cambio, si vuelve (sobre todo durante picos de tráfico), hay que tratar la causa estructural: servidor infra-dimensionado, consultas pesadas, ausencia de caché, cron que se desboca, búsqueda interna costosa o un plugin demasiado exigente.
Un plan de acción pragmático:
– Implementar una estrategia de caché adecuada (caché de página, caché de objetos según el contexto).
– Reducir las consultas costosas (plugins de estadísticas pesados, búsqueda, filtros complejos).
– Verificar las tareas programadas (WP-Cron) y las automatizaciones externas.
– Optimizar la base de datos (limpieza de revisiones, transients, tablas de plugins).
– Aumentar recursos si es necesario.
Para evitar corregir a ciegas, también puede analizar las causas recurrentes de lentitud que acaban por tumbar MySQL en configuraciones pequeñas: Los errores de rendimiento más frecuentes.
Paso 11: tener en cuenta la seguridad (intrusión, inyección, cuentas comprometidas)
Una base inaccesible también puede ser consecuencia de un incidente de seguridad: contraseña de la BD modificada, archivos alterados, creación de backdoors o consultas maliciosas saturando el servidor. No es el escenario más habitual, pero se vuelve probable si también observa: redirecciones desconocidas, nuevas cuentas admin, archivos modificados recientemente o alertas del proveedor de hosting.
En caso de duda, adopte un enfoque de incidente: cambio de contraseñas (FTP/SSH, base, WordPress), verificación de la integridad de los archivos, escaneo, auditoría de cuentas, inspección de los logs. Una checklist estructurada ayuda a no olvidar nada: Auditoría de Seguridad Qué Verificar Absolutamente.
Paso 12: cuándo pedir ayuda (y a quién)
Si ha verificado wp-config.php, probado el acceso MySQL y controlado los permisos sin resultado, es hora de implicar al proveedor de hosting o a un equipo técnico. El proveedor podrá confirmar: caída de MySQL, límite de conexiones, incidente de disco, restauración necesaria o cambio de endpoint.
Como complemento, la comunidad francófona de WordPress puede ayudar a interpretar síntomas y proponer pistas según su contexto: Problema « error al conectar con la base de datos ».
Prevenir la reincidencia: copias de seguridad, actualizaciones, supervisión
Reparar es una cosa, evitar que vuelva es otra. Las mejores protecciones contra este tipo de fallo suelen ser poco glamorosas, pero muy eficaces: copias de seguridad automáticas probadas, actualizaciones regulares, supervisión del uptime y control de recursos (CPU/RAM/IO) para anticipar la saturación.
También es útil implementar rutinas: verificar el estado de la base de datos, limpiar las tablas dejadas por plugins, vigilar los logs de errores y mantener una trazabilidad de los cambios (quién hizo qué, cuándo).
Para arbitrar entre el coste de un enfoque preventivo y el de una avería (pérdida de facturación, SEO, confianza), este análisis ayuda a encuadrar la decisión: Mantenimiento Coste vs Riesgos.
Plan de acción exprés (resumen)
1) Confirmar el alcance: front + admin, y anotar el contexto (actualización, migración, pico).
2) Verificar DB_NAME/DB_USER/DB_PASSWORD/DB_HOST en wp-config.php.
3) Probar la conexión MySQL vía phpMyAdmin/SSH, y comprobar la existencia de la base de datos.
4) Verificar los permisos del usuario sobre la base de datos.
5) Comprobar el estado del servidor (caída, límites, too many connections , disco).
6) Considerar una reparación de tablas si se sospecha corrupción.
7) Aislar un plugin/tema exigente si la base de datos está OK pero el sitio cae bajo carga.
8) Reforzar la prevención: copias de seguridad, supervisión, optimización, seguridad.
Cuándo externalizar: ahorrar tiempo sin asumir riesgos
Si su sitio es crítico (e-commerce, generación de leads, medio), cada minuto de indisponibilidad cuenta. En este caso, delegar el diagnóstico y la prevención a un equipo acostumbrado a tratar este tipo de incidente evita correcciones improvisadas y reduce el tiempo de restablecimiento.
Para una gestión recurrente (actualizaciones, copias de seguridad, vigilancia, parches), puede consultar Más información sobre nuestros servicios de mantenimiento.
