Essa mensagem significa que o WordPress não conseguiu se conectar ao banco de dados onde ficam os seus posts, páginas e configurações. Na maioria esmagadora dos casos, a causa é uma só: as credenciais no arquivo wp-config.php estão erradas — e isso quase sempre acontece depois de uma migração, de uma troca de senha ou de uma alteração no painel.
A boa notícia é que seus dados não sumiram. O banco continua lá, com tudo dentro. O que falhou foi a conexão entre o site e ele, e resolver isso normalmente leva alguns minutos.
Comece por aqui: abra o wp-config.php pelo gerenciador de arquivos e compare os quatro valores de conexão com os do painel de hospedagem.
| O erro apareceu depois de migrar o site | Credenciais antigas no wp-config |
| Apareceu sozinho, sem você mexer | Servidor de banco fora do ar ou no limite |
| O painel avisa que as tabelas precisam de reparo | Banco corrompido |
| Acontece só em horário de pico | Limite de conexões simultâneas |
O que a mensagem significa
O WordPress guarda os arquivos (imagens, temas, plugins) no servidor, mas todo o conteúdo — posts, páginas, comentários, usuários, configurações — fica num banco de dados MySQL separado.
A cada visita, o WordPress precisa se conectar a esse banco para montar a página. Quando essa conexão falha, ele não tem o que exibir — e mostra a mensagem em vez do site.
Para conectar, ele usa quatro informações guardadas no arquivo wp-config.php: o nome do banco, o usuário, a senha e o endereço do servidor. Se qualquer uma das quatro estiver errada, a conexão falha. Nosso guia sobre o que é um banco de dados explica melhor esse funcionamento.
Causa 1: credenciais erradas no wp-config.php
É a causa de longe mais comum, e o primeiro lugar a verificar.
Abra o arquivo. No painel de hospedagem, use o gerenciador de arquivos, entre na pasta do site (geralmente public_html) e edite o wp-config.php. Procure por estas quatro linhas:
define( 'DB_NAME', 'usuario_wp123' );
define( 'DB_USER', 'usuario_wpusr' );
define( 'DB_PASSWORD', 'senha_do_banco' );
define( 'DB_HOST', 'localhost' );
Compare com o painel. No cPanel, abra Bancos de Dados MySQL. Ali você vê o nome exato do banco e os usuários associados a ele. Confira letra por letra — o prefixo da conta costuma ser igual, e a diferença está no que vem depois.
Os erros mais frequentes:
- Depois de uma migração, o nome do banco e do usuário mudam, porque o prefixo é o da nova conta. O wp-config.php continua apontando para os antigos.
- Alguém trocou a senha do usuário do banco pelo painel e esqueceu de atualizar o arquivo.
- O usuário existe, mas não está associado ao banco. No cPanel, criar o usuário e criar o banco são passos separados — falta o terceiro, que é vincular um ao outro com todos os privilégios.
Se precisar redefinir a senha: no cPanel, em Bancos de Dados MySQL, altere a senha do usuário e cole exatamente o mesmo valor no wp-config.php.
Antes de alterar o wp-config.php, baixe uma cópia dele para o seu computador. Um caractere apagado por engano nesse arquivo derruba o site inteiro — e sem a cópia, recuperar exige refazer a configuração do zero. Vale o mesmo cuidado com o banco: nosso tutorial mostra como fazer backup pelo phpMyAdmin.
Causa 2: DB_HOST incorreto
O valor localhost funciona na maioria das hospedagens compartilhadas, porque o banco fica no mesmo servidor do site. Mas nem sempre.
Algumas configurações usam 127.0.0.1, um caminho de socket, ou o endereço de um servidor de banco separado — às vezes com porta específica, como mysql.seudominio.com.br:3306.
Se as credenciais estão certas e o erro persiste, esse é o valor a confirmar com o suporte. É o campo que a documentação genérica quase sempre erra, porque assume localhost.
Causa 3: banco de dados corrompido
O sintoma é característico: além do erro no site, o painel administrativo mostra uma mensagem dizendo que uma ou mais tabelas do banco precisam ser reparadas.
O WordPress tem uma ferramenta embutida para isso. Acrescente esta linha ao wp-config.php, antes da linha que diz “That’s all, stop editing”:
define( 'WP_ALLOW_REPAIR', true );
Depois acesse seudominio.com.br/wp-admin/maint/repair.php e escolha Reparar banco de dados. Ao terminar, remova a linha — enquanto ela estiver lá, qualquer pessoa consegue acessar a ferramenta sem estar logada.
Alternativamente, o phpMyAdmin faz o mesmo: selecione o banco, marque todas as tabelas e escolha “Reparar tabela” no menu inferior.
Causa 4: limite de conexões atingido
Se o erro aparece de forma intermitente, e principalmente em horários de maior movimento, o problema não é configuração — é capacidade.
Cada visita simultânea abre uma conexão com o banco. Quando o número de conexões passa do limite do plano, as novas são recusadas — e o visitante recebe exatamente essa mensagem.
Como reconhecer: o site funciona, cai por alguns minutos, volta sozinho. Ninguém mexeu em nada.
O que fazer:
- Instale um plugin de cache. É o que mais resolve: com cache, a maioria das visitas nem chega a consultar o banco
- Verifique o consumo no painel, na área de uso de recursos — o CloudLinux mostra quando você está batendo no teto do plano
- Procure plugins pesados, que fazem muitas consultas por página
- Considere subir de plano, se o site cresceu
Causa 5: o servidor de banco está fora do ar
Menos comum, mas acontece: o serviço MySQL do servidor caiu ou está sobrecarregado.
Como identificar: se outros sites da mesma conta também estão fora, ou se o phpMyAdmin no painel não abre, o problema é do servidor. Nesse caso não há nada a fazer do seu lado além de acionar o suporte da hospedagem. Se o erro estiver acontecendo no seu ambiente local com XAMPP, e não num site em produção, o caminho é outro — veja Error: MySQL shutdown unexpectedly.
Causa 6: um plugin ou atualização quebrou algo
Mais raro, mas possível — especialmente se o erro apareceu logo depois de instalar ou atualizar alguma coisa.
Como o painel está inacessível, a desativação precisa ser feita por fora: renomeie a pasta wp-content/plugins pelo gerenciador de arquivos, e o WordPress desativa todos de uma vez. Nosso guia sobre como desativar plugins do WordPress mostra os dois caminhos, inclusive pelo phpMyAdmin.
Se o site voltar, reative um a um até identificar o culpado.
Se o seu site usa Cloudflare
Um detalhe que confunde bastante: atrás de uma CDN, esse erro pode aparecer como um erro 500 genérico em vez da mensagem do WordPress.
Isso acontece porque o Cloudflare repassa o erro da origem, e a página que o visitante vê é a dele, não a sua. A causa continua sendo o banco — mas você não consegue diagnosticar pelo painel do Cloudflare. Nosso guia sobre erro 500 no Cloudflare explica como identificar de onde o erro veio.
Quando é da hospedagem
Vale saber distinguir, porque muda quem resolve.
É seu quando o erro apareceu depois de uma alteração: migração, troca de senha, edição de arquivo, instalação de plugin. As credenciais são o primeiro lugar a olhar.
É da hospedagem quando nada mudou do seu lado, outros sites da mesma conta também falham, ou o problema é recorrente sem explicação. Um servidor de banco constantemente sobrecarregado, ou limites apertados demais para o tamanho do site, são problemas de infraestrutura — e nenhuma configuração no WordPress resolve isso.
Erro de banco recorrente costuma ser servidor sobrecarregado ou limites apertados. Na Homehost, cada conta tem recursos isolados pelo CloudLinux, armazenamento NVMe e servidor no Brasil — com suporte em português que verifica o servidor por você. A partir de R$ 7,90/mês, com migração gratuita.
Ver planos de hospedagemPerguntas frequentes
Vou perder o conteúdo do meu site?
Não. O erro significa que o WordPress não conseguiu se conectar ao banco, não que os dados foram apagados. Seus posts, páginas, comentários e configurações continuam lá, e reaparecem assim que a conexão for restabelecida.
Qual a causa mais comum desse erro?
Credenciais incorretas no arquivo wp-config.php — nome do banco, usuário, senha ou host errados. Acontece principalmente depois de uma migração de servidor, quando os nomes mudam de prefixo, ou quando alguém altera a senha do usuário do banco pelo painel sem atualizar o arquivo.
Onde encontro as credenciais do meu banco de dados?
No wp-config.php, dentro da pasta do site, nas linhas DB_NAME, DB_USER, DB_PASSWORD e DB_HOST. Para comparar com os valores corretos, abra Bancos de Dados MySQL no painel de hospedagem, onde aparecem o nome do banco e os usuários vinculados a ele.
O DB_HOST é sempre “localhost”?
Não. É o valor mais comum em hospedagem compartilhada, mas algumas configurações usam 127.0.0.1, um socket ou o endereço de um servidor de banco separado, às vezes com porta. Se as outras credenciais estiverem corretas e o erro persistir, confirme esse valor com o suporte.
O painel avisa que as tabelas precisam de reparo. O que faço?
Isso indica banco corrompido. Acrescente define( 'WP_ALLOW_REPAIR', true ); ao wp-config.php, acesse seudominio.com.br/wp-admin/maint/repair.php, execute o reparo e depois remova a linha — deixá-la ativa permite que qualquer pessoa use a ferramenta sem estar logada.
O erro aparece e some sozinho. Por quê?
É o padrão típico de limite de conexões atingido: em horários de pico, o número de visitas simultâneas ultrapassa o que o plano permite, e as conexões extras são recusadas. Instalar um plugin de cache costuma resolver, porque reduz drasticamente as consultas ao banco.
Como acesso o site se nem o wp-admin abre?
Pelo painel de hospedagem. O gerenciador de arquivos permite editar o wp-config.php e renomear a pasta de plugins, e o phpMyAdmin dá acesso ao banco — tudo sem depender do WordPress estar funcionando.
Mudei de hospedagem e o erro apareceu. É normal?
É a situação mais comum de todas. Ao migrar, o nome do banco e do usuário costumam mudar, porque incluem o prefixo da conta no novo servidor. O wp-config.php vem com os valores antigos e precisa ser atualizado com os novos.
Veja também
Sobre outros erros que deixam o site fora do ar, veja HTTP erro 500 e erro 503. Se você não consegue acessar o painel, veja login no WordPress e como resetar a senha.
Conclusão
A mensagem assusta porque parece perda de dados, e não é — o banco está intacto, só ficou inacessível. Comece sempre pelo wp-config.php, comparando as quatro credenciais com o que aparece no painel de hospedagem, porque é ali que está a resposta na maioria dos casos. Se nada mudou do seu lado e o erro aparece e some sozinho, o problema é de capacidade, não de configuração — e aí a solução passa por cache ou por um plano com mais recursos.
