Na Green Hat, assumi a arquitetura de mais de 30 projetos de clientes simultâneos. Quando cheguei, os desenvolvedores enviavam arquivos diretamente para produção, sem separação de ambiente e sem caminho de reversão.
Quando um site WordPress fica inativo após uma atualização de plugin ou PHP, a ordem de recuperação é: capture o erro real, desative todos os plugins, volte para um tema padrão, depois verifique se sua versão de PHP mudou sem você. Restaure um backup por último.
Uma restauração apaga a evidência e reinstala a mesma combinação quebrada que derrubou o site quarenta minutos atrás. Você está apenas criando um loop infinito de bugs.
Por que sites WordPress quebram após uma atualização de plugin ou PHP
Quatro coisas podem quebrar WordPress após uma atualização:
- Uma atualização de plugin envia código que entra em conflito com outro plugin.
- Uma atualização principal muda uma API na qual algo estava dependendo.
- Um tema chama uma função que não existe mais.
- E uma mudança de versão de PHP, que seu host pode ter feito sem pedir permissão.
O último causa mais indisponibilidades totais e é o mais difícil de detectar, porque ninguém do seu time fez nada. Quando PHP 8.0 chegou, Make WordPress Core contou 48 mudanças não compatíveis com versões anteriores no próprio PHP. Código que produzia um aviso silencioso em PHP 7.4 lança um erro fatal em PHP 8. create_function() foi depreciada em 7.2 e removida em 8.0, e plugins abandonados em 2018 ainda a chamam. utf8_encode() e utf8_decode() foram removidas em 8.4.
O piso também continua subindo. WordPress 7.0 "Armstrong" foi lançado em 20 de maio de 2026, exigindo PHP 7.4 e recomendando 8.3 ou superior, e PHP 8.2 perde suporte de segurança em dezembro de 2026. Os hosts respondem movendo todos para frente. A própria documentação do Bluehost lista PHP 7.3, 7.4, 8.0 e 8.1 como depreciados, com suporte começando em 8.2.
A árvore de decisão de recuperação
Trabalhe de cima para baixo e pare na primeira ramificação que fizer o site carregar. Cada etapa abaixo é reversível, é por isso que essa ordem é segura para executar em um site ativo.
Site está inativo após uma atualização
│
├─ Um email de Modo de Recuperação chegou?
│ ├─ SIM → abra o link, leia o plugin/tema nomeado, vá para Etapa 5
│ └─ NÃO → ative WP_DEBUG_LOG, recarregue, leia debug.log (Etapa 1)
│
├─ Renomeie wp-content/plugins → plugins-off (Etapa 2)
│ ├─ Site carrega → conflito de plugin → vá para Etapa 5
│ └─ Ainda inativo ↓
│
├─ Renomeie a pasta do tema ativo (Etapa 3)
│ ├─ Site carrega → tema ou functions.php
│ └─ Ainda inativo ↓
│
├─ Verifique a versão de PHP no painel de hospedagem (Etapa 4)
│ ├─ Mudou → reverta uma versão para confirmar
│ └─ Inalterada → arquivos principais ou banco de dados, escale
│
└─ Reative plugins um por um (Etapa 5)
Etapa 1: Capture o erro real
Antes de tocar em um único arquivo, descubra o que WordPress está realmente reclamando. Nunca adivinhe o problema.
Verifique o email administrativo do site primeiro. Modo de Recuperação faz parte do WordPress desde a versão 5.2: quando um erro fatal ocorre em um carregamento de página normal, WordPress envia ao administrador um link único que o faz login com o plugin ou tema ofensor pausado apenas para sua sessão. Esse email geralmente nomeia a extensão, o que o leva direto à Etapa 5.
Duas razões pela qual ele pode estar faltando. WordPress limita a taxa para um por dia por padrão, conforme o filtro recovery_mode_email_rate_limit documentado em developer.wordpress.org. E Modo de Recuperação só dispara em carregamentos de página regulares, então qualquer coisa lançada durante cron não produz email algum.
Se nada chegou, obtenha o log você mesmo. Edite wp-config.php via SFTP e adicione isto acima da linha "stop editing":
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
WP_DEBUG_DISPLAY usa true por padrão, então defini-lo como false mantém stack traces fora de uma página pública enquanto WP_DEBUG_LOG os escreve em wp-content/debug.log. Recarregue a página quebrada, leia as últimas vinte linhas e anote o caminho do arquivo e número da linha.
Obtenha também o log de erro PHP de nível de servidor. Erros que matam a solicitação antes de WordPress carregar seu manipulador nunca chegam a 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 cerca de dez segundos, e não precisa de acesso ao painel.
Via SFTP, renomeie wp-content/plugins para wp-content/plugins-off. WordPress não consegue mais localizar os arquivos do plugin, desativa todos eles e carrega. WordPress.org documenta este método diretamente. Renomeie a pasta de volta, e cada plugin permanece desativado até que você o ative individualmente, que é o estado que você quer para a Etapa 5.
Com acesso SSH, 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 que WP-CLI carregue o código quebrado antes de executar seu comando, o que importa quando o erro fatal é grave o suficiente para levar WP-CLI com ele. Note que mu-plugins ainda carregam independentemente, então verifique wp-content/mu-plugins se o site continuar quebrado com tudo mais desativado.
Etapa 3: Volte para um tema padrão
Se o site ainda está quebrado com todos os plugins desativados, o tema é próximo, e o teste leva quinze segundos.
Renomeie a pasta do tema ativo dentro de wp-content/themes. WordPress volta para um tema padrão incluído automaticamente. Se o site voltar, a falha vive em seu tema, e nove em cada dez vezes vive em functions.php chamando algo que PHP não fornece mais.
Este é também onde você descobre se alguém colocou lógica de negócios customizada em um tema em vez de um plugin. Esse código apenas desapareceu do site em execução, o que é um diagnóstico e um problema de manutenção em um.
Etapa 4: Verifique se sua versão de PHP mudou
Com plugins e tema ambos eliminados, verifique a versão de PHP antes de chegar perto de arquivos principais. Faça login no painel de controle de hospedagem, olhe para a versão atual e compare contra a qual o site estava usando na semana passada.
Hosts mudam isso em seu próprio cronograma, às vezes com um email de aviso que cai em uma caixa de entrada compartilhada que ninguém lê. Do lado do proprietário, parece idêntico a um plugin quebrando, porque o sintoma é o mesmo — tela branca.
Se a versão se moveu, reverta uma etapa no painel de controle. A mudança geralmente é aplicada em menos de um minuto. Se o site retornar, você tem sua resposta e um prazo, porque essa versão mais antiga vai desaparecer. Use a janela para executar os plugins que falharam em staging contra a versão mais nova, atualize o que pode ser atualizado, substitua o que foi abandonado, depois mova a produção deliberadamente para frente.
Se a versão de PHP se manteve estável e o site ainda está inativo com plugins e tema desativados, você está olhando para arquivos principais corrompidos ou um problema de banco de dados. wp core verify-checksums vai te dizer se o núcleo foi modificado. Nesse ponto, você está além do playbook de recuperação rápida, e a questão estratégia de manutenção WordPress de se você tem um backup testável e restoável se torna a conversa inteira.
Etapa 5: Reative um plugin por vez
Biseccionar a lista de plugins é tedioso, e é o único método que termina com uma resposta definida.
Renomeie a pasta de plugins de volta, depois ative plugins um por um no painel. Após cada ativação, carregue a página frontal e a tela de administração que estava falhando. Quando o erro retornar, você tem o culpado.
Comece com qualquer coisa atualizada nos últimos 48 horas, depois qualquer coisa tocando o mesmo subsistema que a falha. Um erro de checkout aponta para gateways de pagamento e plugins de envio. Uma falha apenas de admin aponta para construtores de página. Em um site com 40 plugins isso leva cerca de vinte minutos, o que supera três dias de teorização.
Quando o site carrega mas algo ainda está quebrado
Falhas parciais após uma atualização custam mais que indisponibilidades totais, porque ninguém as nota por dias. O site retorna, a página inicial parece bem, e a coisa que realmente gera receita está silenciosamente morta. Falhas de webhook de assinatura WooCommerce são a versão clássica, onde o gateway registra uma falha de entrega enquanto WordPress registra um sucesso e ambos os registros são tecnicamente corretos.
Após qualquer recuperação, caminhe pelos caminhos transacionais manualmente. Faça um pedido de teste, envie um formulário, dispare um webhook, confirme que o email de saída ainda sai do servidor. Um painel de controle sem relatar erros não significa nada aqui.
Quando parar e escalar
Escale quando o site estiver inativo por mais de uma hora e você ainda não identificou o componente que falha, ou quando o reparo exige editar código de plugin que você não escreveu.
Se o erro aparecer apenas sob carga, ou intermitentemente, você está em um limite de recurso ou timeout, e o trabalho de otimização de velocidade WordPress é o reparo real.
Depois há a versão cara, aquela que aparece como um padrão. Um site que fica inativo após atualizações rotineiras, uma e outra vez, tem um problema de ambiente usando um problema de atualização como disfarce. Trazer ajuda quando um dev sênior não é suficiente geralmente custa menos que a quarta indisponibilidade.
O que realmente previne a próxima
Cada etapa acima existe porque alguém atualizou produção diretamente. Remova isso, e a maioria deste artigo deixa de ser necessária.
A configuração que funciona: um ambiente de staging espelhando produção, atualizações aplicadas lá primeiro, uma imersão de 24 horas antes de ir ao vivo, e backups fora do site que você realmente restaurou pelo menos uma vez. Lançamentos menores do WordPress se instalaram automaticamente desde a versão 3.7, então essa camada é tratada. Plugins e PHP são onde a disciplina tem que estar.
Na Green Hat, mover 30+ projetos para um pipeline dev/staging/produção com aprovação de pull-request cortou erros de implantação pela metade. As implantações ficaram mais rápidas porque havia um caminho revisado para produção e nenhuma maneira de silenciosamente sobrescrever um site em execução.
O próximo prazo já está no calendário. PHP 8.2 perde suporte de segurança em dezembro de 2026, e WordPress 7.1 chega em 19 de agosto de 2026. Você pode atender essas datas em staging em uma hora, ou atendê-las às 9 da manhã de uma segunda-feira com a loja inativa.
Se seu site WordPress continua ficando inativo após atualizações rotineiras, a indisponibilidade é o sintoma e o processo de implantação é o diagnóstico. Este é o tipo de trabalho que assumi: colocar um pipeline de staging real em funcionamento para que as atualizações deixem de ser um evento.