Na Green Hat, assumi a arquitetura de mais de 30 projetos de clientes ao mesmo tempo. Quando cheguei, os desenvolvedores subiam arquivo direto em produção, sem ambientes separados e sem caminho de volta.
Quando um site WordPress cai depois de uma atualização de plugin ou de PHP, a ordem de recuperação é esta: capture o erro real, desative todos os plugins, volte pra um tema padrão e confira se a versão do PHP mudou sem você saber. Restaurar backup vem por último.
Restaurar apaga a evidência e reinstala exatamente a mesma combinação quebrada que derrubou o site quarenta minutos atrás. Você só entra num ciclo sem fim de bug.
Por que o WordPress quebra depois de uma atualização de plugin ou de PHP
Quatro coisas derrubam o WordPress depois de uma atualização:
- Uma atualização de plugin traz código que briga com outro plugin.
- Uma atualização do núcleo muda uma API da qual algo dependia.
- Um tema chama uma função que não existe mais.
- Uma troca de versão do PHP, que a hospedagem pode ter feito sem pedir licença.
Essa última é a que mais derruba site inteiro e a mais difícil de perceber, porque ninguém do seu time fez nada. Quando o PHP 8.0 chegou, o Make WordPress Core contou 48 mudanças incompatíveis no próprio PHP. Código que gerava um aviso silencioso no PHP 7.4 vira erro fatal no PHP 8. create_function() foi descontinuada no 7.2 e removida no 8.0, e plugins abandonados em 2018 ainda chamam essa função. utf8_encode() e utf8_decode() saíram no 8.4.
E o piso continua subindo. O WordPress 7.0 "Armstrong" saiu em 20 de maio de 2026, exigindo PHP 7.4 e recomendando 8.3 ou mais novo, e o PHP 8.2 perde suporte de segurança em dezembro de 2026. As hospedagens reagem empurrando todo mundo pra frente. A própria documentação da Bluehost lista o PHP 7.3, 7.4, 8.0 e 8.1 como descontinuados, com suporte a partir do 8.2.
A árvore de decisão da recuperação
Vá de cima pra baixo e pare no primeiro galho que fizer o site carregar. Todas as etapas abaixo são reversíveis, e é por isso que essa ordem é segura pra rodar num site no ar.
Site caiu depois de uma atualização
│
├─ Chegou e-mail do Modo de Recuperação?
│ ├─ SIM → abra o link, veja o plugin/tema citado, vá pra Etapa 5
│ └─ NÃO → ligue o WP_DEBUG_LOG, recarregue, leia o debug.log (Etapa 1)
│
├─ Renomeie wp-content/plugins → plugins-off (Etapa 2)
│ ├─ Site carrega → conflito de plugin → vá pra Etapa 5
│ └─ Continua fora ↓
│
├─ Renomeie a pasta do tema ativo (Etapa 3)
│ ├─ Site carrega → tema ou functions.php
│ └─ Continua fora ↓
│
├─ Confira a versão do PHP no painel da hospedagem (Etapa 4)
│ ├─ Mudou → volte uma versão pra confirmar
│ └─ Não mudou → arquivos do núcleo ou banco, escale
│
└─ Reative os plugins um por um (Etapa 5)
Etapa 1: Capture o erro real
Antes de encostar em qualquer arquivo, descubra do que o WordPress está reclamando de fato. Nunca tente adivinhar o problema.
Olhe primeiro o e-mail do administrador do site. O Modo de Recuperação faz parte do WordPress desde a versão 5.2: quando um erro fatal acontece num carregamento normal de página, o WordPress manda pro administrador um link de uso único que faz login com o plugin ou tema problemático pausado só naquela sessão. Esse e-mail normalmente diz qual extensão é, o que te leva direto pra Etapa 5.
Tem dois motivos pra ele não ter chegado. O WordPress limita a um e-mail por dia por padrão, pelo filtro recovery_mode_email_rate_limit documentado em developer.wordpress.org. E o Modo de Recuperação só dispara em carregamento normal de página, então qualquer erro que estoure durante o cron não gera e-mail nenhum.
Se não chegou nada, vá atrás do log você mesmo. Edite o wp-config.php por SFTP e coloque isto acima da linha "stop editing":
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
O WP_DEBUG_DISPLAY vem como true por padrão, então deixar em false tira os stack traces da página pública, enquanto o WP_DEBUG_LOG grava tudo em wp-content/debug.log. Recarregue a página quebrada, leia as últimas vinte linhas e anote o caminho do arquivo e o número da linha.
Pegue também o log de erros do PHP do servidor. Erro que mata a requisição antes de o WordPress carregar o tratamento de erros nunca chega no debug.log.
Etapa 2: Desative todos os plugins de uma vez
Renomear a pasta de plugins separa um problema de plugin de um problema de ambiente em uns dez segundos, e não precisa de acesso ao painel.
Por SFTP, renomeie wp-content/plugins pra wp-content/plugins-off. O WordPress deixa de achar os arquivos dos plugins, desativa todos e carrega. O WordPress.org documenta esse método. Quando você renomear a pasta de volta, todos os plugins continuam desativados até serem ativados um a um, que é exatamente o estado que você quer pra Etapa 5.
Com SSH, o WP-CLI é mais limpo:
wp --skip-plugins --skip-themes plugin list --status=active
wp --skip-plugins --skip-themes plugin deactivate --all
Os parâmetros globais --skip-plugins e --skip-themes impedem o WP-CLI de carregar o código quebrado antes de rodar o comando, o que faz diferença quando o erro fatal é grave a ponto de derrubar o próprio WP-CLI. Os mu-plugins carregam de qualquer jeito, então dê uma olhada em wp-content/mu-plugins se o site continuar quebrado com todo o resto desativado.
Etapa 3: Volte pra um tema padrão
Se o site continua quebrado com todos os plugins desativados, o próximo suspeito é o tema, e o teste leva quinze segundos.
Renomeie a pasta do tema ativo dentro de wp-content/themes. O WordPress volta sozinho pra um dos temas padrão incluídos. Se o site voltar, a falha mora no seu tema, e em nove de cada dez casos mora no functions.php, chamando algo que o PHP não oferece mais.
É aqui também que você descobre se alguém colocou regra de negócio dentro do tema em vez de num plugin. Esse código acabou de sumir do site no ar, o que é diagnóstico e problema de manutenção ao mesmo tempo.
Etapa 4: Confira se a versão do PHP mudou
Com plugins e tema descartados, confira a versão do PHP antes de chegar perto dos arquivos do núcleo. Entre no painel da hospedagem, veja a versão atual e compare com a que o site usava na semana passada.
A hospedagem muda isso no próprio calendário, às vezes com um e-mail de aviso que cai numa caixa compartilhada que ninguém lê. Pro dono do site, parece igualzinho a um plugin quebrado, porque o sintoma é o mesmo: tela branca.
Se a versão mudou, volte uma no painel. A troca costuma valer em menos de um minuto. Se o site voltar, você tem a resposta e um prazo, porque essa versão mais antiga vai sumir. Use essa janela pra rodar em staging os plugins que falharam com a versão nova, atualizar o que dá, trocar o que foi abandonado e só então levar a produção pra frente, de propósito.
Se a versão do PHP não mudou e o site continua fora do ar com plugins e tema desativados, você está diante de arquivos do núcleo corrompidos ou de um problema no banco. O wp core verify-checksums diz se o núcleo foi alterado. A partir daí, você passou do roteiro de recuperação rápida, e a pergunta da estratégia de manutenção WordPress, se você tem um backup testado que dá pra restaurar, vira a conversa inteira.
Etapa 5: Reative um plugin por vez
Ir dividindo a lista de plugins é chato, e é o único método que termina com uma resposta certa.
Renomeie a pasta de plugins de volta e ative os plugins um por um no painel. Depois de cada ativação, carregue a página inicial e a tela do painel que estava falhando. Quando o erro voltar, você achou o culpado.
Comece pelo que foi atualizado nas últimas 48 horas e depois pelo que mexe no mesmo subsistema da falha. Erro no checkout aponta pra gateway de pagamento e plugin de frete. Falha só no painel aponta pra construtor de páginas. Num site com 40 plugins isso leva uns vinte minutos, o que ganha de três dias de teoria.
Quando o site carrega mas alguma coisa continua quebrada
Falha parcial depois de uma atualização custa mais que queda total, porque ninguém percebe por dias. O site volta, a home parece normal, e a parte que realmente gera receita está morta em silêncio. As falhas de webhook em assinaturas do WooCommerce são o caso clássico: o gateway registra uma entrega que falhou, o WordPress registra sucesso, e os dois registros estão tecnicamente certos.
Depois de qualquer recuperação, percorra os caminhos que envolvem transação na mão. Faça um pedido de teste, envie um formulário, dispare um webhook, confirme que o e-mail continua saindo do servidor. Painel sem erro nenhum não prova nada aqui.
Quando parar e escalar
Escale quando o site estiver fora do ar há mais de uma hora e você ainda não souber qual componente falhou, ou quando a correção exigir mexer no código de um plugin que você não escreveu.
Se o erro só aparece sob carga, ou de vez em quando, você bateu num limite de recurso ou de timeout, e a correção de verdade está na otimização de velocidade do WordPress.
E tem a versão cara, a que aparece como padrão. Um site que cai depois de atualização de rotina, de novo e de novo, tem um problema de ambiente disfarçado de problema de atualização. Trazer ajuda quando um dev sênior não é o suficiente costuma sair mais barato que a quarta queda.
O que evita a próxima de verdade
Cada etapa acima existe porque alguém atualizou direto em produção. Tire isso da equação e a maior parte deste artigo deixa de ser necessária.
A configuração que funciona: um ambiente de staging espelhando a produção, atualizações aplicadas ali primeiro, 24 horas de observação antes de ir pro ar e backups fora do servidor que você já restaurou pelo menos uma vez. As versões menores do WordPress se instalam sozinhas desde a 3.7, então essa camada já está resolvida. É nos plugins e no PHP que a disciplina precisa estar.
Na Green Hat, levar mais de 30 projetos pra um pipeline de desenvolvimento, staging e produção com aprovação por pull request cortou os erros de deploy pela metade. Os deploys ficaram mais rápidos, porque havia um caminho revisado até a produção e nenhum jeito de sobrescrever um site no ar em silêncio.
O próximo prazo já está no calendário. O PHP 8.2 perde suporte de segurança em dezembro de 2026, e o WordPress 7.1 chega em 19 de agosto de 2026. Você pode encarar essas datas em staging, numa hora, ou encarar às 9 da manhã de uma segunda-feira com a loja fora do ar.
Se o seu site WordPress vive caindo depois de atualização de rotina, a queda é o sintoma e o processo de deploy é o diagnóstico. É esse o tipo de trabalho que eu pego: montar um pipeline de staging de verdade pra que atualizar deixe de ser um evento.