Um site fora do ar raramente é um problema único. Na maior parte dos chamados que a Forpes Digital recebe, a causa está em uma de quatro frentes: uma atualização de plugin que conflitou, o limite de memória do PHP estourado, o certificado SSL vencido ou uma invasão que derrubou arquivos do núcleo.
A boa notícia é que as primeiras checagens não exigem conhecimento técnico e separam, em poucos minutos, o problema que você resolve sozinho daquele que precisa de alguém no servidor.
Antes de mexer em qualquer coisa
O primeiro reflexo costuma ser reinstalar plugins ou restaurar um backup antigo. Os dois podem apagar a evidência do que aconteceu e transformar um problema de trinta minutos em uma reconstrução de dois dias.
Comece registrando o que você vê: a mensagem exata na tela, o horário em que o site parou e o que foi feito nas horas anteriores. Se alguém atualizou um plugin ontem à noite, essa informação vale mais do que qualquer diagnóstico automático.
Vale tirar um print da tela de erro antes de qualquer coisa. Mensagens de erro mudam quando o cache expira, e a que você viu às nove da manhã pode não estar mais lá ao meio-dia.
Descobrir se o problema é só seu
Antes de concluir que o site caiu, confirme que ele caiu para todo mundo. Cache do navegador, DNS local e até a rede do escritório fazem uma página parecer fora do ar quando ela está no ar para o resto do mundo.
Três testes rápidos resolvem essa dúvida. Abra o site numa janela anônima, depois pelo celular com dados móveis em vez do wi-fi, e por último em algum serviço que testa a disponibilidade a partir de outro país.
Se o site abre no celular com 4G e não abre no computador do escritório, o problema é da sua rede, não do servidor. Se não abre em lugar nenhum, siga para a próxima etapa.
O que a mensagem na tela está dizendo
Cada erro aponta para um lugar diferente. Saber ler a mensagem economiza a maior parte do tempo de diagnóstico.
| O que aparece | Onde costuma estar a causa | Primeira checagem |
|---|---|---|
| Erro 500, ou erro interno do servidor | Aplicação: plugin em conflito, memória do PHP estourada, arquivo .htaccess quebrado | Log de erros do PHP no painel da hospedagem |
| Tela branca, sem mensagem nenhuma | Erro fatal de PHP com a exibição de erro desligada, que é o padrão em produção | O mesmo log: a informação existe, só está escondida |
| Erro ao estabelecer conexão com o banco de dados | Banco fora do ar, senha alterada ou tabela corrompida | Se o painel da hospedagem abre o banco normalmente |
| Não foi possível encontrar o servidor | DNS ou domínio: registro apontando para o lugar errado, ou domínio vencido | Data de vencimento do domínio no registrador |
| Sua conexão não é particular | Certificado SSL vencido ou emitido para outro domínio | Clicar no cadeado e olhar a data de validade |
| Tela vermelha do Google antes do site | Invasão: o buscador encontrou conteúdo malicioso no domínio | Relatório de Problemas de segurança no Search Console |
As duas últimas linhas não são queda de servidor, e sim problema de configuração e de segurança. Tratamos cada uma delas em detalhe nos artigos sobre aviso de site não seguro e sobre site com vírus.
A sequência que costuma resolver
Com o registro em mãos, a ordem importa. Verificar se o domínio ainda resolve, se o servidor responde e se o certificado está válido leva poucos minutos e já separa um problema de hospedagem de um problema de aplicação.
Só depois disso faz sentido olhar o log de erros do PHP, que aponta o arquivo e a linha exatos quando a falha é de código. É esse log que diferencia um plugin conflitante de uma tabela corrompida no banco.
Quando o log acusa um plugin, o teste é direto: desativar aquele plugin específico pelo FTP ou pelo gerenciador de arquivos, renomeando a pasta dele. O site voltando confirma a causa sem que você precise mexer em mais nada.
Quando o backup é a resposta certa
Restaurar backup resolve, mas apaga tudo que aconteceu depois do ponto restaurado: pedidos, cadastros, comentários. Em uma loja com movimento, restaurar a cópia da madrugada pode custar mais do que o site fora do ar por mais uma hora.
A decisão depende do que o site faz. Um institucional sem formulário perde pouco; um e-commerce perde vendas registradas. Vale sempre exportar o banco atual antes de restaurar qualquer coisa, mesmo que ele pareça quebrado.
E existe um caso em que restaurar piora tudo: se houve invasão, a cópia pode estar contaminada. Antes de restaurar, vale ler o que escrevemos sobre backup de site que funciona de verdade.
Os erros que custam caro
Reinstalar o WordPress por cima esperando que ele se conserte sozinho raramente ajuda, porque o núcleo quase nunca é a origem do problema. Atualizar todos os plugins de uma vez enquanto o site está fora do ar acrescenta variáveis a um diagnóstico que já estava difícil.
E apagar arquivos que parecem estranhos, sem saber o que cada um faz, costuma trocar um site fora do ar por um site fora do ar com a evidência destruída.
Quando chamar alguém
Se a checagem não apontar a causa, se o log não fizer sentido, ou se houver qualquer sinal de invasão, é hora de chamar quem faz isso todo dia. Cada hora fora do ar custa visita, contato e posição no Google.
Veja como funciona a nossa recuperação de sites WordPress: diagnóstico, correção da causa e relatório do que foi encontrado, tanto em site que nós fizemos quanto em projeto de outra equipe.
Se o site está fora do ar agora, chame direto no WhatsApp (44) 3142-1808 com o endereço dele. O diagnóstico inicial não custa nada.