Você abre o site e ele não carrega. Ou pior: o cliente liga dizendo que o site WordPress caiu e você não consegue nem entrar no wp-admin para desativar plugins. É exatamente aí que a receita comum de “desative os plugins” não serve: se o painel está fora, você não tem como executar isso. O caminho é outro. Antes de qualquer coisa, é preciso descobrir se a queda é do servidor, do DNS, da rede ou do próprio WordPress.
Este artigo entrega uma ordem de diagnóstico pensada para ser executada de fora do site, com testes que não dependem do painel. No fim, você vai saber dizer se o problema é seu ou do provedor antes de abrir ticket.
Os sintomas que mudam o diagnóstico de um site WordPress caiu
Nem toda queda é igual. O jeito como o site falha já indica onde procurar.
| O que aparece | Onde costuma estar o problema |
|---|---|
| Página em branco, sem erro | Erro fatal no PHP, geralmente plugin ou tema |
| Erro 500 Internal Server Error | PHP fatal, .htaccess ou limite do servidor |
| Erro 502 ou 504 Bad Gateway | Servidor de aplicação ou banco fora do ar |
| Erro 403 Forbidden | Permissões de arquivo ou regra de firewall |
| “Erro ao estabelecer conexão com o banco de dados” | MySQL/MariaDB inacessível ou credenciais erradas |
| Página não encontrada ou DNS não resolve | DNS, domínio expirado ou apontamento errado |
| Site carrega para uns e não para outros | Cache de CDN, DNS propagando ou bloqueio regional |
Se o erro é 502 ou 504, a chance de ser servidor é alta. Se é 500 com o site respondendo, provavelmente é o WordPress. Se nada responde, comece pelo DNS.
Antes de tudo: teste de fora para dentro
A ordem importa. Testar de dentro para fora faz você perder tempo procurando plugin quando o problema é a hospedagem.
1. O domínio resolve?
No terminal, rode dig seudominio.com.br ou, no Windows, nslookup seudominio.com.br. Você precisa ver um endereço IP na resposta. Se não vier nada, o problema é DNS: domínio expirado, nameservers trocados ou registro A removido.
Confirme também com um resolvedor público, como dig @8.8.8.8 seudominio.com.br. Se o público resolve e o seu não, é cache local ou do provedor.
2. O servidor responde?
Use ping seudominio.com.br. Se o ping falha, pode ser que o host bloqueie ICMP (comum), então isso sozinho não prova nada. O teste mais confiável é curl -I https://seudominio.com.br. Você quer ver a linha de status HTTP.
- Sem resposta nenhuma: servidor ou rede fora do ar.
- 200 OK: o servidor responde, o problema pode estar em cache ou em parte do site.
- 500, 502, 503, 504: servidor responde, mas a aplicação falha.
3. O problema é só com você?
Abra o site no celular usando dados móveis, sem Wi-Fi. Se funciona no 4G e falha na sua rede, o problema é local: DNS do provedor, firewall corporativo ou VPN. Também vale testar por um serviço externo de verificação de disponibilidade, que acessa de outra rede.
Se o servidor responde, o problema é o WordPress
Aqui você já sabe que a infraestrutura está de pé. O passo seguinte é achar o que quebrou dentro do site, sem depender do wp-admin.
Ativar debug via FTP ou SSH
Edite o wp-config.php e adicione:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Isso grava os erros em wp-content/debug.log. Leia o arquivo pelo gerenciador de arquivos da hospedagem ou por SSH. A última linha antes da queda costuma apontar o plugin ou tema culpado. Se você ainda não sabe ler esse arquivo, vale entender como usar os logs de erro do WordPress para achar a causa.
Renomear a pasta de plugins
Sem acesso ao painel, o jeito é pelo FTP: renomeie wp-content/plugins para wp-content/plugins-off. O WordPress desativa todos os plugins automaticamente. Se o site voltar, o problema é um plugin. Renomeie de volta e ative um por vez para identificar qual.
Atenção: isso pode quebrar temporariamente áreas do site que dependem de plugin. Faça em horário de baixo tráfego e avise quem precisa saber.
Trocar o tema para o padrão
Renomeie a pasta do tema ativo em wp-content/themes. O WordPress cai para um tema padrão. Se o site volta, o problema está no tema. Cuidado: você perde customizações visuais enquanto o tema estiver renomeado.
Verificar o banco de dados
Se aparecer erro de conexão com o banco, teste pelo phpMyAdmin da hospedagem. Se o banco não abre, é problema de servidor, não de WordPress. Se abre, confira as credenciais em wp-config.php e se o host do banco mudou (algumas hospedagens alteram o hostname em migrações).
Quando o problema é do provedor
Alguns sinais apontam direto para a hospedagem, e insistir no WordPress só atrasa a solução.
- Vários sites na mesma conta caíram ao mesmo tempo.
- O painel da hospedagem também está fora.
- O erro é 502 ou 504 persistente.
- O banco de dados não abre nem pelo phpMyAdmin.
- O site responde em HTTP mas não em HTTPS, ou o certificado expirou.
Nesses casos, abra ticket com evidências: a saída do curl -I, o horário exato da queda e os sites afetados. Ticket com print de erro genérico demora mais para ser resolvido.
Se o problema for certificado, veja como instalar e evitar erros de certificado SSL no WordPress.
Quem monitora vários sites precisa de outra abordagem
Administrar um site é uma coisa. Administrar dez é outra. Quando o site WordPress caiu, a primeira pergunta deixa de ser “o que quebrou?” e passa a ser “o problema é só meu ou é do provedor?”.
Um monitor de uptime responde isso em segundos. Ele checa o site de fora, registra o horário da queda e avisa por e-mail ou outro canal. Se vários sites do mesmo provedor caem no mesmo minuto, o padrão fica visível e você abre o ticket já com o dado na mão, sem ficar testando site por site.
Para configurar isso em vários sites ao mesmo tempo, vale ver como configurar alertas de monitoramento de uptime em vários sites. O 100% WP faz esse monitoramento junto com backups e atualizações em um painel único, o que ajuda justamente quando o problema se multiplica por dez.
Se o site caiu por causa de uma atualização mal aplicada, o histórico de mudanças ajuda a datar o problema. Veja como gerenciar atualizações contínuas sem travar o site.
Quando NÃO seguir essa ordem
O roteiro acima pressupõe que você tem acesso a FTP ou SSH e que o site é seu. Em alguns cenários, ele não se aplica:
- Site de cliente com contrato de hospedagem gerenciada: o provedor pode proibir alteração em wp-config.php ou renomear pastas. Nesse caso, abra ticket primeiro.
- Site em manutenção programada: se o provedor avisou janela de manutenção, espere terminar antes de mexer.
- Suspeita de invasão: se há arquivos estranhos ou redirecionamentos, não fique ativando e desativando plugin. Trate como incidente de segurança e preserve evidências.
- Sem backup recente: antes de renomear pastas e mexer em arquivos, confirme que existe backup. Se não existe, o risco de piorar é real.
Erros comuns no desespero
Quando o site cai, a pressa faz estrago. Os tropeços mais frequentes:
- Apagar plugin pelo FTP em vez de renomear. Você perde o plugin e não descobre se era ele o culpado.
- Restaurar backup sem antes identificar a causa. Se a causa foi invasão, o backup antigo também pode estar comprometido.
- Editar o banco de dados direto sem backup. Um
UPDATEerrado emwp_optionsderruba o site de vez. - Abrir ticket sem evidência. “O site está fora” não ajuda o suporte a agir.
- Testar só do próprio computador. Cache local e DNS do provedor mascaram o diagnóstico.
Prevenção que evita a próxima vez que o site WordPress caiu
Não existe site que nunca cai. Existe site que volta rápido porque o dono sabia o que fazer.
- Mantenha backup automático fora do servidor, de preferência em nuvem. Veja como escolher um plugin de backup em nuvem para WordPress.
- Ative monitoramento de uptime com alerta por e-mail. Saber da queda antes do cliente é metade do trabalho.
- Anote o horário de cada atualização de plugin ou tema. Isso vira linha do tempo quando algo quebra.
- Guarde as credenciais de FTP, SSH e banco em local seguro e acessível fora do site.
- Teste a restauração de backup de vez em quando. Backup que nunca foi testado não é backup, é esperança.
Quando chamar alguém
Se depois dos testes o servidor responde, o banco abre, os plugins foram renomeados e o site continua fora, o problema pode estar em algo mais fundo: corrupção de tabelas, arquivos do core alterados ou limite de recursos da hospedagem. Nesse ponto, abrir ticket com o provedor e, se for site de cliente, acionar quem cuida da infraestrutura é mais rápido do que continuar tentando no escuro.
O importante é não tratar toda queda como se fosse a mesma coisa. Separar servidor de site logo no início economiza horas e evita mexer no que não precisava.
