Erro 500 no WordPress: encontre e corrija a causa

O erro 500 no WordPress indica que o servidor não conseguiu concluir a requisição, mas não revela sozinho a causa. Em vez de desativar tudo aleatoriamente, registre a URL e o horário, preserve o estado do site, consulte os logs e isole uma camada por vez. Os culpados mais frequentes são erro fatal de PHP, regra inválida no servidor, limite de memória, plugin ou tema incompatível e permissão incorreta.

Guia revisado em 21/09/2026. Faça backup antes de editar arquivos e use staging sempre que o site ainda estiver acessível.

O que significa HTTP 500

HTTP 500 é uma resposta genérica de erro interno. O navegador sabe que a solicitação chegou ao servidor, mas a aplicação ou uma camada anterior falhou. A mesma tela pode representar causas muito diferentes: uma função inexistente no PHP, um .htaccess com diretiva não aceita, falta de memória, indisponibilidade do banco ou bloqueio do provedor.

Por isso, pesquisar a frase exibida no navegador raramente basta. A informação útil está no log associado à requisição. O objetivo do diagnóstico é encontrar a primeira mensagem de erro relevante, reproduzir o problema com controle e testar a menor correção possível.

Antes de alterar: registre o cenário

• URL exata e horário com fuso;
• ação realizada antes do erro;
• se afeta todas as páginas, somente painel, login, checkout ou uma rota;
• usuários e navegadores afetados;
• última atualização, instalação ou mudança de PHP;
• código de resposta e identificador exibido por CDN ou proxy;
• estado de CPU, memória, disco e processos.

Esses dados evitam confundir dois erros ocorridos em horários diferentes. Se o site voltou sozinho, ainda vale investigar: limite de recursos, reinício de serviço ou tarefa agendada pode produzir falhas intermitentes.

Ordem segura de diagnóstico

Etapa 1: consulte os logs

No cPanel, procure Erros, Métricas ou o gerenciador de logs. Também podem existir arquivos como error_log no diretório do site. Em VPS, os caminhos dependem de Apache, Nginx, LiteSpeed e PHP-FPM. Pesquise pelo minuto da falha e pelo caminho acessado.

Mensagens comuns:

• PHP Fatal error: o arquivo e a linha indicam onde a execução parou;
• Allowed memory size exhausted: a requisição excedeu o limite de memória;
• Maximum execution time exceeded: o processamento demorou além do permitido;
• Premature end of script headers: o processo PHP terminou antes de responder;
• Permission denied: o servidor não conseguiu ler ou executar algo;
• Invalid command: uma diretiva no .htaccess não é aceita.

Não publique o log inteiro. Ele pode conter caminhos, endereços IP, consultas e dados pessoais. Separe somente o trecho necessário para a equipe responsável.

Etapa 2: ative o log do WordPress

Se o log do servidor não detalha a aplicação, em staging adicione ao wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Reproduza uma vez e leia wp-content/debug.log. A documentação oficial de depuração explica essas constantes. Mantenha a exibição desligada para que mensagens internas não apareçam aos visitantes e desative o debug ao terminar.

Etapa 3: verifique recursos e disco

Um site pode gerar 500 quando atinge limite de processos, memória, CPU, I/O ou espaço. Confira o painel no mesmo horário. Disco cheio impede cache, sessões, logs e atualizações. Muitos processos simultâneos podem indicar tráfego legítimo, bot agressivo, consulta lenta ou tarefa cron travada.

Aumentar um limite pode restaurar o acesso, mas não substitui a análise. Se uma única página consome centenas de megabytes, descubra qual consulta, imagem, importação ou plugin produz essa carga. Escalar recursos sem corrigir a origem costuma apenas adiar o próximo erro.

Etapa 4: teste o .htaccess

Em servidores Apache ou LiteSpeed, renomeie temporariamente .htaccess para um nome de backup. Faça isso apenas depois de salvar uma cópia. Se o site voltar, gere regras padrão em Configurações > Links permanentes e recoloque manualmente as regras necessárias de segurança, cache e redirecionamento.

Não deixe o arquivo renomeado por muito tempo: URLs amigáveis, proteção e redirects podem parar. Se o servidor usa Nginx sem compatibilidade com .htaccess, esse teste não se aplica; consulte a configuração do virtual host.

Etapa 5: isole plugins sem perder dados

Se o painel abre, desative primeiro o componente citado no log. Se não abre, WP-CLI permite desativar de forma controlada:

wp plugin list
wp plugin deactivate nome-do-plugin

Quando não há WP-CLI, renomear a pasta de um plugin específico impede seu carregamento. Renomear toda a pasta plugins ajuda apenas como teste amplo; depois restaure o nome e ative um por vez. Desativar normalmente preserva configurações, mas plugins de cache, segurança e loja podem exigir limpeza ou procedimento próprio.

Plugins obrigatórios em mu-plugins e drop-ins como object-cache.php, advanced-cache.php e db.php continuam ativos quando a pasta comum é desativada. Inclua-os no inventário.

Etapa 6: teste o tema

Ative temporariamente um tema padrão compatível no staging. Com WP-CLI:

wp theme list
wp theme activate twentytwentysix

Use um tema realmente instalado. Se a falha desaparecer, compare o log, o functions.php, templates substituídos e dependências do construtor. Um tema filho pode conter código antigo mesmo quando o tema pai foi atualizado.

Etapa 7: confirme versão e extensões do PHP

Uma atualização de PHP pode remover funções antigas ou tornar avisos mais rigorosos. Uma regressão para PHP antigo também causa erro quando o código usa sintaxe recente. Confirme a versão efetiva do domínio, não somente a padrão da conta. Verifique extensões como mysqli, mbstring, intl, curl, gd ou imagick conforme o projeto.

Trocar temporariamente para a versão anterior pode restaurar o serviço e confirmar incompatibilidade. Trate isso como reversão curta e atualize o código. Permanecer em uma linha PHP sem suporte aumenta o risco de segurança e limita a evolução do WordPress.

Etapa 8: verifique arquivos do núcleo

Com WP-CLI, compare os arquivos oficiais:

wp core verify-checksums
wp core version

Arquivos diferentes podem resultar de atualização incompleta, alteração manual ou incidente de segurança. Não substitua wp-content nem wp-config.php ao reinstalar o núcleo. Faça backup, confirme a versão e use pacote oficial. A referência do WP-CLI explica a verificação de checksums.

Permissões recomendadas

Em muitas hospedagens, diretórios usam 755 e arquivos 644, mas o modelo pode mudar conforme PHP-FPM, usuário e servidor. Evite 777: ele amplia acesso e raramente corrige a causa real. Compare proprietário e grupo com arquivos criados normalmente pela conta. Se não houver acesso para ajustar ownership, peça à hospedagem.

E se o erro acontecer somente em uma ação?

Erro ao salvar uma página pode estar ligado ao tamanho da requisição, firewall ou bloco específico. Erro no upload pode envolver extensão, memória e processamento de imagens. Erro no checkout exige examinar gateway, webhook e log da loja. Erro no REST API pode vir de autenticação, permalink ou regra de segurança.

Reproduza a menor ação possível e filtre o log pelo endpoint. Isso é mais eficiente que desativar o site inteiro. Se o problema ocorre apenas para usuários conectados, compare cookies, função do usuário e plugins de cache.

Como restaurar o serviço com segurança

1. Escolha a menor reversão: plugin, tema, regra ou versão recém-alterada.
2. Registre o que foi revertido e preserve o log.
3. Teste página inicial, login, formulário e função crítica.
4. Limpe caches somente depois de corrigir a origem.
5. Reproduza e corrija definitivamente em staging.
6. Atualize monitoramento e documentação para detectar recorrência.

Perguntas frequentes

Erro 500 é sempre problema da hospedagem?

Não. O servidor entrega o código, mas a causa pode estar no PHP, WordPress, plugin, tema, regra ou recurso da conta. O log mostra qual camada falhou.

Aumentar memory_limit resolve?

Resolve somente quando o limite era adequado ao trabalho e ficou baixo. Se há vazamento, consulta excessiva ou loop, aumentar memória mascara o defeito.

Desativar todos os plugins apaga configurações?

Em geral não, mas cada plugin define seu comportamento. Prefira desativar o componente citado no log e tenha backup antes de intervenções amplas.

Posso mostrar erros PHP na tela?

Evite em produção. Grave em log e limite o acesso. Mensagens públicas revelam caminhos e detalhes úteis a atacantes.

Conclusão

O erro 500 deixa de ser genérico quando você correlaciona a requisição com o log certo. Preserve o cenário, confirme recursos, leia a primeira falha relevante e teste uma hipótese por vez. Essa ordem reduz indisponibilidade e evita mudanças que criam novos problemas.

Depois de restaurar, corrija a causa em staging, atualize componentes e monitore. Um registro curto com horário, mensagem, componente e solução poupa horas quando outra falha semelhante aparecer.