Site WordPress fora do ar: causas e como resolver

Atualizado em 19/06/2026

Poucas coisas dão tanto frio na barriga quanto abrir o próprio site e ele não carregar. A boa notícia: na imensa maioria dos casos o WordPress sai do ar por um motivo identificável e reversível, sem perda de conteúdo. O segredo é não agir no susto e seguir uma ordem lógica de verificação.

Como o problema costuma aparecer

• Erro HTTP 500 (Internal Server Error) ou "Há um problema técnico".
• Mensagem do navegador "Este site não pode ser acessado" / tempo limite esgotado (timeout).
• Página totalmente branca, sem nada — a tela branca da morte.
• "Erro ao estabelecer uma conexão com o banco de dados".
• Site preso em "Em manutenção. Verifique novamente em instantes" após uma atualização.
• Aviso de conta suspensa da hospedagem ou de certificado SSL expirado.
• O site abre, mas todas as páginas internas dão 404 — aí o caso é outro: erro 404 e links permanentes.

Código de erro e causa provável

O que o navegador ou a hospedagem mostram já estreita muito o diagnóstico. Use a tabela abaixo para ligar o código que você está vendo à causa mais provável — e ao próximo passo:

As causas mais comuns

• Atualização problemática: um plugin, o tema ou o próprio núcleo do WordPress foi atualizado e gerou incompatibilidade. É a causa nº 1.
• Conflito de plugins: dois plugins que não se entendem, ou um plugin mal codificado.
• Limite de memória PHP estourado: o site cresce, mas o memory_limit da hospedagem continua baixo — veja memória esgotada.
• Excesso de CPU / plano de hospedagem pequeno: picos de acesso ou processos pesados derrubam o site em hospedagem compartilhada.
• Arquivo .htaccess ou wp-config.php corrompido.
• Problema na hospedagem: manutenção, queda do servidor, fatura em atraso, domínio ou SSL vencidos.
• Invasão / malware: o site foi comprometido — veja WordPress hackeado.

O que você pode verificar agora (sem riscos)

1. É só você? Abra o site nos dados do celular ou em uma aba anônima. Se carregar, pode ser cache/DNS do seu lado, não o site.
2. O /wp-admin abre? Teste seusite.com.br/wp-admin. Anote se o painel abre, mesmo que o site não.
3. Qual é a mensagem exata? Tire um print. "Erro 500", "tela branca" e "erro de banco" levam a caminhos diferentes.
4. A hospedagem está no ar? Verifique e-mails de aviso (suspensão, fatura, manutenção) e o painel da sua hospedagem.
5. Domínio e SSL estão válidos? Um certificado ou registro de domínio vencido tira o site do ar.
6. O que mudou por último? Atualização, plugin novo, mudança de servidor, edição de código? Essa é a pergunta de ouro.

Como eu resolvo

Com os acessos em mãos, o trabalho é metódico e seguro:

• Ativo o modo de depuração (WP_DEBUG) e leio os logs de erro do servidor para encontrar a causa real.
• Faço backup de arquivos e banco antes de qualquer alteração de risco.
• Desativo plugins com segurança (via FTP/gerenciador de arquivos) para isolar conflitos, e testo o tema padrão do WordPress.
• Ajusto memory_limit, reviso .htaccess e wp-config.php e verifico permissões de arquivos.
• Se necessário, restauro a partir de um backup e converso com a hospedagem sobre limites de recurso.
• Por fim, corrijo a causa raiz e oriento como evitar a reincidência.

Ativar a depuração para ver o erro real

Quando a página só mostra "erro 500" ou fica branca, o primeiro passo técnico é fazer o WordPress gravar o erro em um arquivo em vez de escondê-lo. Edite o wp-config.php (via FTP/SFTP ou gerenciador de arquivos), logo acima da linha /* That's all, stop editing! */, e acrescente:

// Grava os erros em wp-content/debug.log sem exibi-los ao visitante
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

Com isso, recarregue o site e abra o arquivo wp-content/debug.log: ele costuma indicar o arquivo e a linha exata da falha (um plugin, o tema ou um trecho no functions.php). Manter WP_DEBUG_DISPLAY em false evita expor caminhos do servidor a visitantes — importante em produção. Terminado o diagnóstico, volte WP_DEBUG para false.

Isolar conflito de plugin pelo FTP

Sem acesso ao painel, dá para desativar todos os plugins de uma vez sem perder nada: pelo FTP/SFTP, renomeie a pasta de plugins. Se o site voltar, o culpado é um plugin.

# Pelo terminal/SSH (ou renomeie a pasta no gerenciador de arquivos)
cd wp-content
mv plugins plugins-off
# Site voltou? Reverta e reative um a um pelo painel:
mv plugins-off plugins

Renomear a pasta apenas desativa os plugins — nenhuma configuração é apagada. Se o problema for o tema, a mesma lógica vale para wp-content/themes: renomeie a pasta do tema ativo para o WordPress cair em um tema padrão (Twenty Twenty-Something). Caso o erro persista mesmo com tudo desativado, a causa está no servidor, no .htaccess ou no banco de dados — não nos plugins.