ByteSeguroPode Confiar.

WordPress mostra erro crítico ou tela branca: como descobrir se o problema está em plugin, tema, PHP ou servidor

Erro crítico, tela branca e HTTP 500 são sintomas. Antes de reinstalar WordPress, restaurar backup ou editar arquivos, descubra o que ainda funciona, preserve a mensagem de erro e veja qual mudança ocorreu imediatamente antes da falha.

Autor
ByteSeguro Editorial
Publicado
Pessoa segura notebook com falha visual na tela.

Comece com uma pergunta:

O que ainda funciona: o site, o wp-admin ou nenhum dos dois?

Depois siga esta ordem:

  1. registre a mensagem, horário e página afetada antes de alterar qualquer coisa;
  2. compare frontend e wp-admin;
  3. reveja a mudança mais recente: plugin, tema, WordPress, PHP, hospedagem ou código;
  4. se o WordPress enviou um link oficial de Recovery Mode, use-o como caminho de recuperação;
  5. isole apenas o plugin ou tema realmente suspeito, uma variável por vez;
  6. se a falha começou após mudança de PHP ou servidor, trate compatibilidade/runtime como camada própria;
  7. preserve detalhes de erro e logs fornecidos pela hospedagem;
  8. use Site Health se o painel ainda estiver acessível;
  9. deixe backup, rollback e reinstalação para depois de conhecer a camada;
  10. não habilite exibição pública de erros;
  11. não mexa em banco, wp-config.php, filesystem ou memória por tentativa;
  12. quando perder acesso à aplicação, leve as evidências ao desenvolvedor ou à hospedagem.

Princípio central: um erro crítico só diz que o WordPress não conseguiu continuar normalmente. Ele não informa sozinho se a causa é plugin, tema, PHP, servidor ou outro componente.

O que ainda funcionaO que ganha pesoPróximo passo
Frontend falha, wp-admin abreTema, plugin de frontend ou código da aplicaçãoPreservar erro e isolar mudança recente
Frontend abre, wp-admin falhaPlugin/admin, autenticação, runtime ou aplicaçãoInvestigar apenas a área administrativa
Ambos falhamPHP, aplicação, servidor ou componente carregado globalmenteRecovery Mode/logs/suporte
Recovery Mode chegouWordPress detectou erro fatal elegível para recuperaçãoUsar o link oficial e observar componente indicado
Falha começou após pluginPlugin ganha pesoTestar somente o suspeito
Falha começou após temaTema ganha pesoTeste controlado de tema, se o painel estiver acessível
Falha começou após mudança de PHPCompatibilidade/runtime ganha pesoComparar com requisito/documentação e suporte
HTTP 500 genéricoCamada servidor/aplicaçãoObter detalhes antes de culpar um componente

1. Erro crítico e tela branca são sintomas, não diagnósticos

O WordPress pode falhar de formas diferentes:

  • mensagem de “erro crítico”;
  • página completamente branca;
  • frontend quebrado;
  • painel administrativo quebrado;
  • resposta HTTP 500;
  • erro depois de atualização;
  • erro depois de mudança de PHP;
  • apenas uma página ou função quebrada.

A documentação oficial do WordPress reconhece que tela branca pode estar ligada a erros de PHP, banco, plugin, tema e outras falhas da aplicação.

A mensagem de erro crítico também indica apenas que algo impediu o WordPress de executar como esperado.

Portanto, não use atalhos como:

  • “erro crítico = plugin”;
  • “tela branca = memória”;
  • “500 = hospedagem”;
  • “depois da atualização = atualização culpada”.

Esses elementos são pistas.

2. Primeiro separe frontend de `wp-admin`

Pergunte o que ainda abre.

wp-admin funciona, frontend falha

Ganham peso:

  • tema;
  • template;
  • plugin que atua no frontend;
  • código executado apenas em páginas públicas.

Frontend funciona, wp-admin falha

Ganham peso:

  • plugin administrativo;
  • fluxo de login;
  • código executado no painel;
  • operação de aplicação específica do admin.

Ambos falham

Ganham peso:

  • plugin carregado globalmente;
  • tema ou código fatal;
  • PHP/runtime;
  • WordPress/aplicação;
  • servidor/recursos.

Essa comparação não prova a causa, mas reduz a área de investigação.

3. Registre a mensagem antes de alterar o site

Antes de desativar qualquer componente, preserve evidências.

Anote:

  • texto exato do erro;
  • URL afetada;
  • horário aproximado;
  • se ocorre no frontend, no wp-admin ou nos dois;
  • se aparece HTTP 500;
  • se houve e-mail do WordPress;
  • qual foi a última mudança conhecida.

Se a hospedagem fornece um identificador de erro, detalhe de falha ou log, guarde a informação.

Não publique em fóruns abertos:

  • senhas;
  • tokens;
  • credenciais;
  • chaves;
  • caminhos internos sensíveis;
  • dados pessoais.

A evidência vale mais antes da primeira mudança.

4. Veja o que mudou imediatamente antes da falha

Pergunte se houve:

  • instalação ou atualização de plugin;
  • ativação ou atualização de tema;
  • atualização do WordPress;
  • alteração de PHP;
  • migração de hospedagem;
  • deploy;
  • snippet ou código personalizado;
  • alteração de configuração.

Se o erro surgiu logo depois, essa camada ganha peso.

Mas cronologia não é prova.

Um plugin pode ter sido atualizado no mesmo momento em que o servidor mudou de versão de PHP, por exemplo.

O objetivo é escolher um teste controlado, não reverter tudo.

5. Recovery Mode pode ajudar a isolar um componente

O Recovery Mode é um recurso oficial do WordPress para determinados erros fatais de PHP.

Quando ele é ativado, o WordPress pode enviar um e-mail ao endereço administrativo com:

  • informação sobre o erro;
  • link especial de acesso;
  • indicação do componente envolvido.

Ao entrar por esse link, plugins ou temas que causaram o erro podem ser pausados para a sessão administrativa de recuperação, permitindo acesso ao painel para investigar.

Isso é muito menos invasivo que começar renomeando pastas no servidor.

Mas há limites:

  • o e-mail pode não chegar;
  • nem todo tipo de falha ativa Recovery Mode;
  • a indicação do componente não substitui validação;
  • a interface e o fluxo podem mudar entre versões.

Se você recebeu um e-mail legítimo do seu próprio WordPress, confirme o domínio e use o link de recuperação atual.

6. Plugin, tema e PHP precisam de evidência antes de qualquer rollback

Se a cronologia aponta para um plugin:

  • prefira Recovery Mode;
  • ou, se o wp-admin abre, desative somente o plugin suspeito;
  • teste o site;
  • registre o resultado.

Se a cronologia aponta para um tema e o painel abre, um teste temporário com um tema conhecido e compatível pode ajudar — de preferência em staging quando o impacto visual ou funcional for relevante.

Não delete o tema.

Se a falha começou exatamente após alteração do PHP, compatibilidade de runtime ganha peso.

O próprio WordPress lista incompatibilidade de PHP entre possíveis causas de falhas críticas.

Isso não significa escolher uma versão arbitrária, fazer downgrade às cegas ou editar php.ini.

Confirme o requisito do WordPress, do tema e dos plugins envolvidos e, se necessário, peça ao provedor para verificar a mudança de runtime.

7. Isole um componente de cada vez quando o acesso permitir

A boa investigação mantém o teste pequeno.

Se existe um suspeito forte:

  1. preserve o estado atual;
  2. faça backup adequado antes de mudanças relevantes;
  3. use staging quando disponível;
  4. desative apenas o componente suspeito;
  5. teste frontend e wp-admin;
  6. registre se o sintoma desapareceu;
  7. não mude outra variável ao mesmo tempo.

Evite desativar todos os plugins indiscriminadamente em produção.

A documentação do WordPress contém métodos avançados via FTP ou gerenciador de arquivos, mas eles ficam fora deste artigo.

Se o painel está inacessível e não existe Recovery Mode, encaminhe o isolamento via filesystem a alguém com experiência ou à documentação técnica apropriada.

8. Erro 500 e falta de recursos não apontam uma causa sozinhos

HTTP 500 Internal Server Error significa que o servidor encontrou uma condição inesperada e não conseguiu concluir a solicitação.

É um erro genérico.

Entre as causas possíveis estão:

  • exceção não tratada;
  • configuração;
  • aplicação;
  • permissões;
  • falta de recursos;
  • outros problemas do servidor.

No WordPress, isso pode coincidir com:

  • plugin;
  • tema;
  • PHP;
  • WordPress;
  • servidor.

Não conclua “é plugin” apenas por ver 500.

Da mesma forma, mensagens de memória ou tempo de execução precisam ser tratadas como evidência.

Não aumente memory_limit, constantes do wp-config.php ou recursos de hospedagem por tentativa.

Primeiro preserve o erro e peça ao provedor/desenvolvedor para confirmar onde o limite está sendo atingido.

9. Preserve logs e use Site Health quando disponível

Se o provedor oferece logs ou detalhes de erro, use-os para responder:

  • qual arquivo/componente aparece?
  • qual horário coincide com a falha?
  • o erro é recorrente?
  • existe um fatal error de PHP?
  • existe indicação de memória, timeout ou compatibilidade?

Não é necessário ensinar acesso via shell para aproveitar logs.

Peça ao suporte os trechos relevantes quando necessário.

Se o wp-admin ainda abre, Site Health também pode fornecer contexto sobre:

  • WordPress;
  • tema;
  • plugins;
  • PHP/servidor;
  • banco;
  • permissões;
  • outros itens de configuração.

Site Health não “descobre automaticamente o culpado”. Ele apenas aumenta o contexto.

10. Backup, rollback e reinstalação vêm depois

Um backup é proteção. Restaurá-lo é uma alteração de estado.

Um WordPress típico depende de:

  • arquivos;
  • banco de dados.

Restaurar um ponto antigo pode remover conteúdo ou alterações feitos depois do backup.

Por isso, rollback ou restauração só deve entrar quando:

  • a falha está ligada a uma mudança conhecida;
  • o ponto de retorno é conhecido;
  • o backup foi verificado;
  • dados posteriores foram considerados;
  • o teste mais localizado não é suficiente.

Reinstalar WordPress também não é uma primeira resposta.

Uma reinstalação pode não corrigir:

  • conflito de plugin;
  • conflito de tema;
  • incompatibilidade com PHP;
  • falha de servidor;
  • limite de recursos.

Ela ainda pode apagar pistas úteis.

11. O que não fazer diante de um erro crítico

Evite procedimentos que alteram várias camadas ou expõem informações.

Não faça como primeira tentativa:

  • habilitar WP_DEBUG seguindo receita aleatória;
  • exibir erros de PHP publicamente;
  • editar wp-config.php;
  • aumentar memória sem evidência;
  • editar php.ini;
  • reiniciar PHP-FPM;
  • renomear a pasta inteira de plugins;
  • apagar diretórios de plugins;
  • apagar o tema ativo;
  • acessar banco pelo phpMyAdmin para “reparar”;
  • executar SQL;
  • ativar reparo de banco;
  • reinstalar WordPress;
  • restaurar backup imediatamente;
  • fazer downgrade de PHP às cegas;
  • atualizar todos os componentes simultaneamente.

A documentação do WordPress alerta que exibir erros em produção pode revelar informações internas. Se depuração avançada for necessária, faça em staging ou com suporte técnico, mantendo a exibição pública desativada.

12. Quando procurar desenvolvedor ou hospedagem

Procure o desenvolvedor ou suporte do plugin/tema quando:

  • a falha começou após um componente específico;
  • Recovery Mode indica esse componente;
  • o problema desaparece quando ele é isolado de forma controlada.

Procure a hospedagem quando:

  • existe HTTP 500 sem detalhes suficientes;
  • houve mudança de PHP/runtime;
  • há indício de memória ou limite de processo;
  • frontend e wp-admin falham;
  • você precisa de logs do servidor;
  • Recovery Mode não chega e a aplicação está inacessível.

Procure suporte WordPress/desenvolvedor mais amplo quando:

  • nenhum componente isolado explica;
  • há custom code;
  • aplicação e servidor interagem;
  • será necessário debugging técnico.

Leve:

  • mensagem exata;
  • horário;
  • URL;
  • o que ainda funciona;
  • mudança recente;
  • Recovery Mode recebido ou não;
  • componente isolado e resultado;
  • trecho relevante de log;
  • informação do Site Health.

Se a falha também pode estar em domínio, DNS, SSL ou hospedagem antes de chegar ao WordPress, veja [Site WordPress está fora do ar: como separar problema de hospedagem, domínio, DNS, SSL e WordPress](/br/35/software-it/hosting-wordpress-domains/site-wordpress-fora-do-ar).

Se o site voltou a funcionar, mas permaneceu lento, veja [WordPress está lento: como separar hospedagem, plugins, tema, banco de dados e conteúdo](/br/35/software-it/hosting-wordpress-domains/wordpress-lento).

Conclusão

Erro crítico, tela branca e HTTP 500 não dizem sozinhos qual componente falhou.

A sequência segura é:

o que funciona → preservar erro → mudança recente → Recovery Mode → isolamento de um componente → PHP/hospedagem → logs/Site Health → rollback controlado ou suporte.

Quanto mais evidência você preserva antes de mexer em arquivos, banco ou servidor, maior a chance de recuperar o site sem apagar pistas nem criar um segundo problema.

Fontes públicas

  • WordPress.org — Recovery Mode.
  • WordPress Developer Resources — Common WordPress errors.
  • WordPress.org — Site Health e Site Health screen.
  • Learn WordPress — Troubleshooting your site: Plugin and theme conflicts.
  • WordPress Developer Resources — Display Errors.
  • WordPress Developer Resources — Backups.
  • MDN — 500 Internal Server Error.