O que fazer quando um site WordPress está em baixo?

São 9h30 de segunda-feira. O telefone toca. O cliente pergunta: "O site está em baixo?" Nesse momento, a agência precisa de ter um processo claro, não de improvisar. Este guia é o protocolo de resposta que toda a agência deveria ter documentado e partilhado com a equipa.

Passo 1: Confirmar que o site está realmente em baixo

Antes de entrar em modo de crise, confirme o problema. Nem sempre "não consigo aceder" significa que o site está em baixo para todos.

• Teste a partir de múltiplos dispositivos e redes. O problema pode ser local — DNS cache, ISP específico ou firewall.
• Use ferramentas externas: Down For Everyone Or Just Me, UptimeRobot ou ferramentas de ping distribuído.
• Verifique o código de erro: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable e "connection refused" têm causas e soluções diferentes.
• Confirme o scope: é só a homepage? É todo o site? É só o wp-admin? É global ou só Portugal?

Passo 2: Diagnóstico rápido — os 5 pontos de verificação

Com o site confirmado como indisponível, percorra esta checklist de diagnóstico por ordem de probabilidade:

1. Servidor e hosting

• O servidor responde a ping? (ping dominio.pt)
• Consegue aceder via SSH ou painel do hosting?
• O provider tem status page com incidentes reportados?
• O espaço em disco está esgotado? Memória RAM saturada?

2. DNS

• O domínio resolve corretamente? (nslookup dominio.pt ou dig dominio.pt)
• Houve alguma alteração recente nos registos DNS?
• O domínio expirou? (verificar no registrar)

3. SSL/HTTPS

• O certificado SSL expirou? (verificar no browser ou com openssl s_client -connect dominio.pt:443)
• Houve alteração no certificado que está a causar mixed content ou redirect loops?

4. WordPress e aplicação

• Ativar WP_DEBUG para ver o erro específico.
• Houve alguma atualização recente de core, tema ou plugin?
• Os uploads ou wp-content têm permissões corretas?
• O ficheiro .htaccess está corrompido ou em falta?

5. Base de dados

• O serviço MySQL/MariaDB está a correr?
• As credenciais em wp-config.php estão corretas?
• Há tabelas corrompidas? (REPAIR TABLE via phpMyAdmin ou CLI)

Passo 3: Comunicar com o cliente

A comunicação durante um incidente é tão importante como a resolução técnica. Regras fundamentais:

• Comunicar rápido, mesmo sem solução. "Identificámos o problema e estamos a trabalhar na resolução. Enviaremos atualização em 30 minutos." é melhor que silêncio.
• Ser honesto sobre impacto e timeline. Não prometer "5 minutos" se não souber. Dar estimativas conservadoras.
• Usar linguagem não-técnica. O cliente quer saber quando vai estar resolvido, não detalhes sobre MySQL.
• Enviar updates regulares mesmo que o status não tenha mudado. O silêncio gera ansiedade.
• Enviar post-mortem. Após a resolução, enviar resumo: o que aconteceu, como foi resolvido, o que vai ser feito para evitar que volte a acontecer.

Passo 4: Resolver — ações por tipo de problema

Servidor inacessível

Se o servidor não responde de todo: contactar provider imediato, verificar status page. Se for um VPS/dedicado, tentar reboot via painel. Se for shared hosting, a agência tem pouco controlo — escalar com provider.

Erro 500 — Internal Server Error

Causa mais comum: plugin ou tema incompatível após update. Resolução: aceder via FTP/SSH, renomear pasta wp-content/plugins para desativar todos os plugins. Se o site volta, reativar um a um para identificar o culpado.

Erro 503 — Service Unavailable

Causa mais comum: sobrecarga de recursos (CPU/memória) ou modo de manutenção de WordPress ativo (.maintenance file). Verificar e remover ficheiro .maintenance se existir.

White Screen of Death (WSOD)

Ativar WP_DEBUG em wp-config.php. Verificar error log do PHP. Tipicamente causado por erro fatal em plugin ou tema — mesmo processo de desativar plugins via FTP.

"Error establishing a database connection"

Verificar credenciais em wp-config.php. Verificar se MySQL está a correr. Verificar se a base de dados existe. Tentar reparar base de dados adicionando define('WP_ALLOW_REPAIR', true); em wp-config.php e acedendo a /wp-admin/maint/repair.php.

Passo 5: Documentar e prevenir

Após resolver o incidente, três ações obrigatórias:

1. Documentar o incidente: quando começou, causa raiz, ações tomadas, tempo de resolução, impacto no cliente.
2. Identificar prevenção: o que pode ser feito para que isto não volte a acontecer? Monitorização? Updates mais controlados? Melhores backups?
3. Implementar melhorias: não basta identificar — implementar as medidas preventivas. Monitorização profissional detecta downtime antes do cliente ligar. Manutenção regular reduz a probabilidade de incidentes.

Template de comunicação de incidente

Para facilitar a comunicação com clientes durante incidentes, aqui fica um template adaptável:

Assunto: [Nome do site] — Incidente de indisponibilidade (resolvido/em resolução)

Olá [Nome do cliente],

Identificámos uma indisponibilidade no site [URL] às [hora]. A nossa equipa iniciou o diagnóstico imediatamente.

Estado atual: [em investigação / causa identificada / resolvido]

Impacto: [site completamente indisponível / funcionalidade X afetada]

Próxima atualização: [hora estimada]

Cumprimentos,
[Nome da agência]

Conclusão: processo vence improviso

Quando um site vai abaixo, a diferença entre resolver em 15 minutos ou em 3 horas é, quase sempre, ter ou não um processo documentado. As agências que investem em preparação — checklists mensais, monitorização ativa, backups testados e protocolos de resposta — são as que mantêm clientes e reputação intactos.