Cómo solucionar el error de conexión a la base de datos

Qué es el error de conexión a la base de datos en WordPress

El error base de datos WordPress, que se muestra en pantalla con el mensaje Error establishing a database connection, es uno de los problemas más graves que puede sufrir un sitio. Cuando aparece, todo el sitio queda inaccesible: ni el frontend carga ni el panel de administración responde. El visitante ve una página con ese mensaje técnico en inglés y no entiende qué pasa. El administrador entra en pánico porque no sabe por dónde empezar.

WordPress depende absolutamente de su base de datos para funcionar. Allí se guardan los textos de las páginas, las configuraciones del tema, los datos de los usuarios, los pedidos de WooCommerce, los comentarios, las opciones de cada plugin y básicamente todo lo que no son archivos. Cuando esa conexión se rompe, el sitio simplemente no puede operar.

Lo bueno es que detrás de este error casi siempre hay una causa específica y, una vez identificada, la solución suele ser rápida. Lo malo es que, mientras dura, el sitio está completamente caído y eso significa pérdida de ventas, mala experiencia para los visitantes y posible impacto en el posicionamiento en Google si la caída se extiende muchas horas.

Causas más frecuentes del error de base de datos

Antes de empezar a tocar archivos, vale la pena entender las causas típicas. Identificar primero el motivo evita probar soluciones al azar que pueden empeorar la situación.

La causa más habitual son las credenciales incorrectas en el archivo wp-config.php. WordPress guarda allí el nombre de la base de datos, el usuario, la contraseña y el servidor al que debe conectarse. Si cualquiera de esos cuatro valores está mal, la conexión falla. Esto pasa típicamente después de migrar el sitio a un nuevo hosting sin actualizar las credenciales, después de cambiar la contraseña de la base de datos desde el panel del hosting o después de una restauración mal hecha desde un respaldo antiguo.

La segunda causa común son problemas con el servidor MySQL del hosting. Cuando el servidor de base de datos está caído, sobrecargado o ha sido reiniciado, WordPress no puede conectarse aunque las credenciales sean correctas. Esto suele pasar en hostings compartidos donde el servidor MySQL está saturado por otros sitios que consumen demasiados recursos.

La tercera causa es la corrupción de las tablas de la base de datos. WordPress usa varias tablas internas y cualquiera de ellas puede dañarse por cortes de luz en el datacenter, por escrituras incompletas, por errores de migración o por intentos de ataque. Una sola tabla corrupta puede dejar todo el sitio fuera de servicio.

La cuarta causa son los límites de conexiones simultáneas. Cada hosting asigna un número máximo de conexiones que puede abrir cada usuario contra MySQL. Cuando ese tope se supera porque hay muchos visitantes al mismo tiempo o porque un plugin abre conexiones sin cerrarlas, el error aparece y se mantiene hasta que el tráfico baja.

Una quinta causa, menos visible, son los hackeos. Si el sitio fue vulnerado, los atacantes pueden modificar el wp-config.php para romper la conexión a propósito o para redirigir el sitio a otra base de datos que ellos controlan. Por eso conviene revisar siempre integridad de archivos cuando aparece este error sin explicación.

Cómo verificar las credenciales en wp-config.php

El primer paso obligado ante este error es revisar el archivo de configuración. Es donde más rápido se descarta la causa más frecuente y donde, en muchos casos, se encuentra el problema y se resuelve en cinco minutos.

Para acceder al archivo conéctate al hosting por FTP, SFTP o desde el administrador de archivos del panel. Navega hasta la raíz del sitio donde están las carpetas wp-admin, wp-content y wp-includes. Allí mismo, al lado de esas carpetas, está el archivo wp-config.php. Descárgalo a tu computadora antes de abrirlo para tener una copia de respaldo por si algo sale mal.

Abre el archivo con un editor de texto plano como Notepad++ o Visual Studio Code. Nunca uses Word ni TextEdit con formato porque agregan caracteres invisibles que rompen la sintaxis PHP. Busca las líneas que empiezan con define y los nombres DB_NAME, DB_USER, DB_PASSWORD y DB_HOST.

El valor de DB_NAME es el nombre exacto de la base de datos que asignó el hosting. El de DB_USER es el usuario que tiene permisos sobre esa base. El de DB_PASSWORD es la contraseña de ese usuario. El de DB_HOST casi siempre es localhost pero algunos hostings usan otros valores como mysql.tuhosting.com o una IP específica.

Para confirmar que los valores son correctos entra al panel del hosting. En cPanel busca la sección de bases de datos MySQL. Allí verás el nombre de la base, los usuarios asignados y los privilegios. Compara letra por letra con los valores de wp-config.php. Una sola letra diferente o un espacio invisible es suficiente para que falle la conexión.

Cómo probar manualmente la conexión a la base de datos

Una vez revisadas las credenciales conviene verificar que el usuario realmente puede conectarse al servidor MySQL con esas credenciales. Esto descarta problemas de permisos o de servidor caído.

La forma más simple es entrar a phpMyAdmin desde el panel del hosting. Esta herramienta web permite acceder a las bases de datos sin necesidad de instalar nada. Si logras entrar y ver las tablas de tu sitio, la base existe y está operativa. Si phpMyAdmin no abre o devuelve errores, el problema está del lado del servidor MySQL del hosting y allí es el momento de contactar al soporte técnico.

Otra opción es crear un archivo PHP de prueba con un par de líneas que intenten conectarse a la base usando las mismas credenciales del wp-config.php. Si el script devuelve mensaje de conexión exitosa, las credenciales son correctas y el problema está en otro lado. Si devuelve el error de conexión, ya sabes que el problema viene de las credenciales o del servidor.

Esa prueba se puede subir por FTP a la raíz del sitio con un nombre temporal como test-db.php. Al visitar la URL del archivo verás el resultado. Es importante borrar ese archivo en cuanto termines la prueba porque deja credenciales sensibles expuestas si alguien lo descubre.

Cómo reparar tablas corruptas con la utilidad de WordPress

Cuando las credenciales son correctas pero el sitio sigue dando error, conviene revisar si hay tablas corruptas. WordPress incluye una utilidad propia para esto que se llama repair y se activa con una línea en wp-config.php.

Abre wp-config.php y agrega una línea nueva con define WP_ALLOW_REPAIR y valor true antes del comentario que pide parar de editar. Guarda el archivo y subelo por FTP. Esto activa una utilidad oculta de WordPress que está accesible en la URL del sitio agregando slash wp-admin slash maint slash repair.php al final.

Al entrar a esa URL verás una pantalla con dos botones: uno que dice Repair Database y otro que dice Repair and Optimize Database. El primero solo repara las tablas dañadas. El segundo, además, las optimiza para mejorar rendimiento. Para una primera revisión basta con el primero. La operación puede tomar entre uno y cinco minutos dependiendo del tamaño del sitio.

Esta utilidad recorre todas las tablas, identifica las que están corruptas y aplica reparaciones automáticas. La mayoría de problemas comunes se resuelven aquí. Una vez terminada la reparación, es muy importante quitar la línea WP_ALLOW_REPAIR del wp-config.php porque dejar la utilidad accesible al público es un riesgo de seguridad serio.

Cómo reparar tablas desde phpMyAdmin

Si la utilidad de WordPress no logra reparar todas las tablas, o si ni siquiera puedes activarla porque no entra al panel, la alternativa es usar phpMyAdmin directamente desde el panel del hosting.

Entra a phpMyAdmin con las credenciales del hosting. En la columna de la izquierda selecciona la base de datos del sitio. Verás la lista de todas las tablas que conforman el sitio WordPress. Las tablas estándar empiezan con el prefijo wp_ aunque puede ser otro si lo cambiaste durante la instalación por seguridad.

En la parte inferior de la lista hay una casilla que dice Check all o Marcar todas. Tildala. Luego, en el menú desplegable que aparece debajo, busca la opción Repair table o Reparar tabla. Al confirmar, phpMyAdmin ejecuta una reparación sobre todas las tablas seleccionadas y muestra el resultado de cada una.

Las tablas que estaban bien aparecen con OK. Las que estaban dañadas y se pudieron reparar muestran un mensaje de éxito. Las que no se pudieron reparar muestran error y allí sí necesitas ayuda más profunda, posiblemente del soporte del hosting o un especialista en bases de datos MySQL.

Una alternativa al repair es la opción de optimizar tabla, que también está en el mismo menú. Optimizar reorganiza los datos internamente y libera espacio fragmentado. Es útil hacerlo de vez en cuando como mantenimiento, incluso cuando no hay errores activos.

Cuándo contactar al soporte del hosting

Algunos problemas no se resuelven editando archivos ni reparando tablas porque la causa está en la infraestructura del hosting, no en tu sitio. En esos casos, lo más rápido y eficiente es contactar al soporte técnico del proveedor.

Los síntomas que indican que el problema es del hosting incluyen no poder acceder a phpMyAdmin, recibir errores genéricos al intentar conectarte al panel de MySQL, que el problema afecte varios sitios alojados en la misma cuenta o que el error aparezca y desaparezca solo sin que hayas tocado nada. Cuando ves estos patrones, no pierdas tiempo intentando soluciones internas.

Al contactar al soporte aporta información concreta para que la atención avance rápido. Incluye la URL del sitio, la hora exacta cuando empezó el problema, el mensaje literal que muestra el error, los pasos que ya intentaste y, si tienes capturas de pantalla, mejor. Esto reduce los rebotes típicos donde el soporte pide datos básicos antes de empezar a revisar.

Los hostings serios con soporte de calidad responden en menos de quince minutos cuando se trata de problemas que tumban un sitio. Si tu proveedor demora horas o días, esa lentitud es una bandera roja sobre el servicio que recibes y conviene evaluar migrar a otro hosting con mejor atención técnica.

Cómo prevenir el error de conexión a la base de datos

Como con casi todos los problemas de WordPress, la prevención cuesta menos que la reparación. Adoptar algunas prácticas reduce dramáticamente la probabilidad de que aparezca este error y, cuando aparece, permite resolverlo en minutos en lugar de horas.

El primer hábito es mantener respaldos automáticos de base de datos. La mayoría de plugins de respaldo permiten programar copias diarias o semanales que se guardan en Google Drive, Dropbox o el propio servidor. Con un respaldo reciente, ante cualquier corrupción se puede restaurar el sitio en pocos minutos.

El segundo hábito es elegir un hosting con servidor MySQL bien dimensionado. Los hostings ultra baratos suelen meter cientos de sitios en el mismo servidor MySQL y los recursos no alcanzan para todos. Pagar un poco más por un hosting con base de datos dedicada o con buenos límites suele evitar la mayoría de estos problemas de saturación.

El tercer hábito es vigilar los plugins que escriben mucho en la base de datos. Algunos plugins de estadísticas, de logs de seguridad o de respaldos generan tantos registros que sobrecargan las tablas y a la larga producen problemas de rendimiento e incluso corrupción. Revisa periódicamente qué plugins están escribiendo más y considera alternativas más livianas si encuentras alguno descontrolado.

El cuarto hábito es no editar wp-config.php sin tener respaldo. Este archivo es el más sensible de toda la instalación de WordPress. Un error de tipeo allí deja el sitio caído al instante. Antes de cualquier cambio, descarga una copia local y guárdala en un lugar seguro por si necesitas restaurarla.

El quinto hábito es monitorear el sitio con herramientas como UptimeRobot que avisan apenas la página deja de responder. Así te enteras del problema antes que los clientes y ganas tiempo para resolverlo. Configurar alertas por correo y por WhatsApp toma diez minutos y vale oro cuando una caída ocurre fuera de horario de oficina.

Restaurar desde un respaldo cuando nada funciona

Si llegaste hasta aquí y nada de lo anterior resolvió el error, la última opción razonable antes de buscar ayuda profesional es restaurar el sitio desde un respaldo reciente. Esta es exactamente la situación para la que existen los respaldos automáticos.

El procedimiento varía según el plugin de respaldos que uses, pero la lógica general es similar. Entra al panel del plugin de respaldos, selecciona el respaldo más reciente que sepas que estaba funcionando bien y ejecuta la restauración. El plugin reemplaza los archivos del sitio y las tablas de la base con las versiones del respaldo.

Si el panel de WordPress no carga porque la base está rota, muchos plugins de respaldos ofrecen una herramienta de restauración independiente que se sube por FTP y se ejecuta directamente desde el navegador. UpdraftPlus, por ejemplo, tiene esta funcionalidad y resulta vital cuando el sitio está completamente caído.

Después de restaurar, revisa todo el sitio para confirmar que funciona. Si el respaldo era de hace varios días, puedes haber perdido contenido nuevo o pedidos recientes. Anótalo y, en el caso de pedidos, contacta a los clientes para reconfirmar. Es una solución que duele pero a veces es la única forma de volver a la operación rápida.

Preguntas frecuentes

El error de base de datos puede borrar mi contenido

En la mayoría de casos no. El error solo impide la conexión pero los datos siguen existiendo en la base. Cuando se resuelve la conexión, el contenido reaparece tal como estaba. Solo en casos extremos de corrupción severa de la base o cuando se restaura desde un respaldo muy antiguo se pierde información. Por eso los respaldos diarios son tan importantes.

Por qué aparece el error después de migrar el sitio

Casi siempre porque las credenciales en wp-config.php todavía apuntan al hosting anterior. Al migrar, el nuevo hosting asigna un nombre de base, un usuario y una contraseña distintos. Hay que actualizar esos cuatro valores en wp-config.php para que el sitio se conecte a la base correcta en el nuevo servidor.

Cuánto tarda en resolverse un error típico de base de datos

Depende de la causa. Si son credenciales mal escritas, la corrección toma cinco minutos. Si son tablas corruptas, la reparación automática toma entre uno y diez minutos. Si el servidor MySQL del hosting está caído, depende del tiempo de respuesta del proveedor que puede ser desde quince minutos hasta varias horas.

Es seguro usar la utilidad de reparación de WordPress

Sí, siempre y cuando recuerdes quitar la línea WP_ALLOW_REPAIR del wp-config.php cuando termines. Mientras esa línea está activa, cualquier persona en internet que conozca la URL puede acceder a la herramienta y ejecutar reparaciones u optimizaciones sin autenticarse. Es un riesgo serio si se deja olvidada.

Puedo evitar este error cambiando de hosting

En parte sí. Un hosting con servidor MySQL dedicado, buenos límites de conexión y soporte rápido reduce mucho la frecuencia de estos errores. Sin embargo, ningún hosting elimina por completo la posibilidad de credenciales mal escritas, tablas corruptas por cortes de luz o cambios manuales que rompan la conexión.

El error puede ser causado por un plugin

Indirectamente sí. Algunos plugins mal programados abren conexiones a la base sin cerrarlas y agotan el límite de conexiones simultáneas. Otros generan tantos registros que saturan las tablas y producen corrupción. Si el error aparece después de instalar o actualizar un plugin específico, desactivarlo es buena primera prueba.

Qué hago si phpMyAdmin no carga las tablas

Si phpMyAdmin abre pero no muestra tablas o muestra un mensaje de error al seleccionar la base, lo más probable es corrupción severa. La utilidad de reparación de WordPress no va a ayudar en ese caso. Conviene contactar al soporte del hosting para que ellos ejecuten una reparación a nivel de servidor con herramientas más potentes.

Necesito conocimientos técnicos para resolver este error

Para los casos comunes como credenciales mal escritas o uso de la utilidad de reparación, no se necesita programación. Basta con saber navegar archivos por FTP y editar un archivo de texto con cuidado. Para casos más complejos como reparar tablas manualmente o restaurar desde respaldos por SSH, sí conviene tener algo de experiencia técnica o buscar ayuda profesional.

El error puede afectar mi posicionamiento en Google

Si el sitio queda caído pocas horas, el impacto es mínimo porque Google entiende que pueden ocurrir caídas. Si el sitio se mantiene caído varios días, Google empieza a desindexar páginas y el posicionamiento sufre. Por eso conviene resolver el error rápido y, si se prevé demora larga, mostrar al menos una página con código 503 que le diga a Google que es mantenimiento temporal.

Hay forma de prevenir las conexiones agotadas en horas pico

Sí. Instalar un plugin de caché como WP Rocket, W3 Total Cache o LiteSpeed Cache reduce drásticamente la cantidad de consultas a la base por cada visitante. Optimizar las consultas que hacen los plugins también ayuda. Y en sitios con tráfico alto sostenido, migrar a un hosting con servidor MySQL dedicado o a un VPS resuelve el problema de raíz.