Erro 500 no WordPress: checklist seguro antes de acionar a hospedagem

Ver um erro 500 no WordPress assusta porque, muitas vezes, o site simplesmente sai do ar. Em alguns casos aparece “Internal Server Error”. Em outros, surge uma tela branca, uma mensagem genérica do navegador ou o painel /wp-admin também deixa de abrir.

O ponto mais importante é este: erro 500 não é uma causa, é um sintoma. Ele indica que o servidor encontrou uma falha inesperada e não conseguiu completar a requisição. Essa falha pode estar em um plugin, tema, configuração PHP, .htaccess, permissão de arquivos, banco de dados, limite de memória, cache, CDN ou na própria hospedagem.

Por isso, a pior reação é sair apagando arquivos, desativando tudo ou restaurando backup antigo sem plano. Você pode mascarar a causa, perder evidências, apagar dados recentes ou transformar uma indisponibilidade simples em um problema maior.

Neste guia, você vai seguir um checklist seguro para diagnosticar HTTP 500 WordPress antes de acionar a hospedagem — ou para abrir o chamado com informações úteis, se precisar de suporte.

Aviso importante: antes de alterar plugins, tema, .htaccess, wp-config.php, versão de PHP, permissões, banco de dados ou cache do servidor, faça um backup do estado atual do site. Mesmo quebrado, o site atual pode conter dados recentes e evidências importantes. Se você ainda não tem uma rotina confiável, veja o guia de backup WordPress.

Checklist rápido para erro 500 no WordPress

Se o site está fora do ar agora, siga esta ordem:

1. Anote o sintoma exato. O erro aparece no site todo, só no painel, só em uma página ou só no checkout?
2. Registre o horário. A hospedagem pode procurar logs pelo intervalo correto.
3. Faça backup do estado atual. Não restaure backup antigo antes de salvar o que existe agora.
4. Liste mudanças recentes. Atualização de plugin, tema, WordPress, PHP, cache, CDN, migração, snippet ou regra de redirecionamento.
5. Verifique se há mensagem de erro crítico. O WordPress pode ter enviado e-mail ao administrador em alguns casos.
6. Consulte logs antes de mexer muito. Logs de PHP, servidor e debug.log ajudam a encontrar a causa.
7. Teste cache/CDN com cuidado. Limpar cache costuma ser menos arriscado do que alterar arquivos, mas registre o que foi feito.
8. Isole plugins e tema sem apagar arquivos. Desative ou renomeie temporariamente; não delete pastas no impulso.
9. Evite editar banco de dados sem experiência. Se envolver banco, WooCommerce, membros ou pedidos, chame suporte.
10. Abra chamado com evidências. Envie URL, horário, mensagem, log e últimas alterações.

A lógica é simples: primeiro preserve; depois diagnostique; só então corrija.

O que significa erro 500 no WordPress?

O erro 500, também chamado de “Internal Server Error”, é um código HTTP da família 5xx. Segundo a documentação da MDN, ele indica que o servidor encontrou uma condição inesperada que impediu atender à solicitação. É uma resposta genérica, usada quando o servidor não consegue retornar um erro mais específico.

No WordPress, isso pode acontecer quando alguma parte da aplicação ou do ambiente falha durante o carregamento. Exemplos comuns:

Possível causa	Indício comum	Primeiro caminho seguro
Plugin com erro fatal	O erro começou após instalação ou atualização	Conferir logs e desativar primeiro o plugin alterado
Tema incompatível	Falha após troca, atualização ou edição de functions.php	Testar tema padrão, preferencialmente em staging
.htaccess corrompido	Erro em Apache/LiteSpeed, links permanentes ou redirecionamentos	Fazer cópia do arquivo e regenerar permalinks se aplicável
Limite de memória ou execução	Log com Allowed memory size exhausted ou timeout	Verificar consumo, plugin pesado e limites da hospedagem
Permissões incorretas	Log com Permission denied	Pedir padrão correto à hospedagem; nunca usar permissões amplas às cegas
Banco de dados ou hospedagem	Erro em páginas específicas, painel parcial ou logs MySQL	Preservar dados e acionar suporte com horário e evidências

Nem sempre o navegador mostra detalhes. Por segurança, muitos servidores escondem a mensagem técnica e exibem apenas o erro genérico. Por isso, logs são tão importantes.

Erro 500, tela branca e erro crítico são a mesma coisa?

Não exatamente, mas podem aparecer juntos.

Erro 500 WordPress

É uma resposta do servidor. O navegador recebeu um código HTTP 500 porque algo falhou no processamento da página.

Tela branca WordPress

A tela branca é um sintoma visual: a página fica em branco ou quase sem informação. A documentação oficial do WordPress cita erros de PHP e banco de dados como possíveis causas, incluindo conflitos de plugins e temas.

Erro crítico no WordPress

É uma mensagem do próprio WordPress quando ele detecta uma falha grave. Dependendo da versão, configuração e envio de e-mail do site, o WordPress pode enviar uma mensagem ao administrador com informações ou link de recuperação.

Se o seu caso mostra “houve um erro crítico neste site”, leia também o guia de erro crítico no WordPress. Este artigo aqui foca no diagnóstico de erro interno do servidor e HTTP 500.

Antes de mexer: preserve o site e as evidências

Quando um site cai, a vontade é resolver rápido. Mas alguns minutos de preparação evitam prejuízos.

Antes de qualquer mudança sensível, confirme se você tem:

• acesso ao painel da hospedagem;
• acesso ao WordPress, se o painel ainda abre;
• acesso a FTP/SFTP ou gerenciador de arquivos, se precisar mexer em arquivos;
• backup recente dos arquivos e do banco de dados;
• permissão para alterar o site, se for site de cliente;
• lista de alterações feitas pouco antes do erro;
• uma forma de testar mudanças sem afetar visitantes, quando possível.

Se o site vende, recebe leads, tem usuários logados, área de membros ou WooCommerce, redobre o cuidado. Restaurar backup antigo ou mexer no banco pode apagar pedidos, formulários, cadastros e alterações recentes.

Quando possível, use um ambiente de staging WordPress para testar hipóteses antes de aplicar em produção.

Anote o contexto do erro

Antes de alterar qualquer coisa, monte um pequeno registro:

• URL onde o erro aparece;
• data e horário aproximado, com fuso horário;
• se o erro afeta site público, painel, login, checkout ou página específica;
• mensagem exata exibida no navegador;
• código HTTP, se alguma ferramenta mostrar;
• última atualização de plugin, tema ou WordPress;
• mudança recente de versão PHP;
• instalação ou edição de snippet;
• alteração de cache, CDN, WAF ou SSL;
• migração, restauração ou deploy recente;
• se há pico de tráfego ou consumo anormal de recursos.

Esse registro é útil para você e para o suporte da hospedagem. Um chamado com “meu site está fora do ar” costuma demorar mais do que um chamado com horário, URL, log e mudança recente.

Descubra onde o erro aparece

A primeira triagem é mapear o alcance do problema.

O site todo mostra erro 500

Pode ser plugin, tema, .htaccess, PHP, permissão, banco, cache do servidor ou falha da hospedagem. Comece por logs e mudanças recentes.

Só o painel /wp-admin mostra erro

Pode haver conflito em plugin que carrega apenas no admin, problema em editor, construtor de páginas, permissões, sessão, memória ou atualização interrompida.

Só uma página mostra erro

Pode ser shortcode, bloco, template, consulta pesada, formulário, produto WooCommerce, regra de cache, integração externa ou conteúdo específico.

Só checkout, carrinho ou área de membros falha

Trate como caso crítico. Evite testes destrutivos em produção. Registre o erro, preserve pedidos e dados recentes, e acione suporte técnico se houver risco de venda perdida ou cobrança duplicada.

O erro aparece para alguns usuários, mas não para outros

Pode envolver cache, CDN, sessão, geolocalização, WAF, navegador, cookie, dispositivo ou nó específico da infraestrutura. Teste em janela anônima, outro navegador e, se possível, outra rede. Não conclua que “voltou ao normal” só porque abriu para você.

Verifique mudanças recentes

Erro 500 costuma aparecer depois de alguma mudança. Pergunte:

• algum plugin foi atualizado ou instalado?
• o tema foi atualizado, trocado ou editado?
• o WordPress foi atualizado?
• a hospedagem mudou a versão do PHP?
• houve limpeza ou troca de cache?
• alguma regra de .htaccess, Nginx, LiteSpeed, redirecionamento ou SSL foi alterada?
• alguém adicionou código em functions.php ou plugin de snippets?
• houve migração, restauração de backup ou deploy?
• o site atingiu limite de CPU, memória, processos ou disco?

Se o erro começou logo depois de uma mudança identificável, investigue essa mudança primeiro. Mesmo assim, faça backup antes de reverter.

Consulte logs antes de sair testando

Logs reduzem tentativa e erro. Dependendo da hospedagem, você pode encontrar:

• log de erros PHP;
• log do servidor web, como Apache, Nginx ou LiteSpeed;
• log do painel da hospedagem;
• log de WAF/firewall;
• consumo de recursos da conta;
• wp-content/debug.log, se o debug do WordPress estiver ativo.

Os nomes e caminhos variam por provedor. Em hospedagem compartilhada, procure áreas como “Errors”, “Logs”, “Métricas”, “Uso de recursos” ou “Terminal”. Em hospedagem gerenciada, o painel pode ter uma área própria de logs por ambiente.

Ao analisar logs, procure mensagens próximas do horário do erro. Termos comuns incluem:

• PHP Fatal error;
• Allowed memory size exhausted;
• Permission denied;
• syntax error;
• Uncaught Error;
• Maximum execution time exceeded;
• nome de plugin, tema ou arquivo específico;
• erro de conexão com banco;
• bloqueio de regra de segurança.

Não publique logs completos em fóruns, comentários ou redes sociais. Eles podem expor caminhos internos, nomes de usuários, tokens, e-mails ou dados sensíveis. Compartilhe apenas o trecho necessário com o suporte ou desenvolvedor de confiança.

Como ativar debug log WordPress temporariamente

Se os logs da hospedagem não forem suficientes, você pode ativar o debug do WordPress temporariamente. Faça isso com cuidado.

Pré-requisitos:

• backup do estado atual;
• acesso a FTP/SFTP, gerenciador de arquivos ou editor seguro da hospedagem;
• capacidade de editar wp-config.php sem corromper o arquivo;
• plano para desativar o debug depois do diagnóstico.

No arquivo wp-config.php, antes da linha /* That's all, stop editing! Happy blogging. */, a documentação oficial mostra constantes como estas:

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

Com essa configuração, o WordPress registra erros no arquivo wp-content/debug.log e evita exibir detalhes técnicos aos visitantes.

Cuidados importantes:

• use true e false como booleanos, sem aspas;
• não deixe debug ativo permanentemente em produção;
• apague ou proteja logs antigos quando não forem mais necessários;
• não compartilhe o debug.log completo publicamente;
• se não se sente seguro editando wp-config.php, peça ajuda à hospedagem.

Depois de coletar a informação, volte WP_DEBUG para false ou remova apenas o bloco que você adicionou, conforme a configuração original do site.

Limpe cache e confira CDN sem mascarar a causa

Cache pode exibir uma página quebrada mesmo depois de corrigir o problema, ou pode esconder um erro que ainda aparece para visitantes específicos.

Você pode verificar:

• cache do plugin WordPress;
• cache do servidor;
• cache do CDN;
• cache do navegador;
• regras de minificação ou otimização;
• modo de desenvolvimento do CDN, quando disponível.

Limpar cache costuma ser menos arriscado do que editar arquivos, mas ainda assim registre o que foi feito. Se o erro desaparece apenas quando o cache/CDN é desativado, a causa pode estar em regra de cache, minificação, WAF, SSL ou integração externa.

Isole plugins com segurança

Plugins são uma causa comum de erro 500 WordPress, principalmente depois de atualização, instalação, conflito ou incompatibilidade com PHP.

Se o painel abre:

1. Vá em Plugins.
2. Desative primeiro o plugin alterado por último.
3. Teste a página afetada.
4. Se o erro sumir, mantenha o plugin desativado e investigue atualização, configuração ou compatibilidade.
5. Se não sumir, reative com cuidado e continue a triagem.

Se o painel não abre, a documentação oficial do WordPress descreve a desativação via FTP ou gerenciador de arquivos renomeando a pasta de plugins. O caminho comum é:

wp-content/plugins

Você pode renomear temporariamente para algo como:

plugins.hold

Depois, teste o site. Se o erro sumir, o problema provavelmente está em algum plugin. Renomeie a pasta de volta para plugins e reative os plugins um por um pelo painel, acompanhando quando o erro retorna.

Cuidados:

• não delete a pasta de plugins;
• anote quais plugins estavam ativos;
• em WooCommerce, membros, formulários e LMS, desativar plugins pode afetar vendas, acesso e captura de leads;
• prefira fazer isso em staging quando o site for crítico;
• se há pedidos em andamento, considere janela de manutenção.

Isole o tema sem perder alterações

Tema também pode causar erro 500, especialmente depois de atualização, troca de tema, edição em functions.php ou incompatibilidade com PHP.

Se o painel abre, ative temporariamente um tema padrão compatível com sua versão do WordPress. Depois, teste se o erro desaparece.

Se o painel não abre, é possível renomear a pasta do tema ativo via FTP/SFTP em:

wp-content/themes

Mas faça isso com cautela. Antes de renomear, confirme qual é o tema ativo e se há tema padrão instalado. Em sites com tema filho, construtores visuais ou personalizações, a troca pode alterar layout e funcionalidades.

Não edite functions.php às pressas sem backup. Um erro de sintaxe nesse arquivo pode derrubar o site.

Verifique o arquivo .htaccess quando o servidor usa Apache/LiteSpeed

Em hospedagens com Apache ou LiteSpeed, o arquivo .htaccess pode afetar URLs, redirecionamentos, cache e regras de servidor. A documentação oficial do WordPress cita .htaccess corrompido como uma causa provável de erro interno do servidor.

Caminho típico:

.htaccess

na raiz da instalação WordPress, junto de pastas como wp-admin, wp-includes e wp-content.

Uma triagem comum é renomear temporariamente o arquivo para algo como:

.htaccess_old

Depois, teste o site. Se funcionar, vá em Configurações > Links permanentes no painel do WordPress e salve novamente para regenerar regras padrão, quando aplicável.

Cuidados:

• faça backup do arquivo antes de alterar;
• não apague regras personalizadas sem entender o impacto;
• sites com redirecionamentos, segurança, cache ou multisite podem depender de regras específicas;
• em Nginx puro, .htaccess normalmente não é usado da mesma forma; nesse caso, a configuração fica no servidor e pode exigir suporte da hospedagem.

Confira versão do PHP e limite de memória

Mudança de PHP pode quebrar plugins ou temas antigos. Um plugin compatível com uma versão pode falhar em outra, especialmente se usa funções obsoletas ou código não mantido.

Verifique na hospedagem:

• versão atual do PHP;
• se houve alteração recente;
• extensões PHP exigidas pelo site;
• limite de memória;
• limite de execução;
• erros como Allowed memory size exhausted ou Maximum execution time exceeded.

Aumentar memória pode resolver alguns casos, mas não deve ser usado para esconder problema permanente. Se um plugin consome memória demais, a causa real pode ser conflito, bug, consulta pesada ou infraestrutura insuficiente.

Se você não sabe qual versão PHP o site suporta, não troque várias versões no impulso em produção. Teste em staging ou peça orientação à hospedagem.

Permissões de arquivos: cuidado para não abrir brecha

Permissões incorretas podem gerar erro 500, mas sair aplicando permissões amplas é perigoso.

A documentação oficial de WordPress explica que permissões variam por hospedagem e configuração. Ela também alerta que, se um usuário experiente instalou o WordPress e você não está vendo erros de permissão, provavelmente não deve mexer nisso sem motivo.

Sinais de possível problema de permissão:

• Permission denied nos logs;
• WordPress não consegue gravar em wp-content;
• uploads falham;
• atualizações não conseguem criar ou substituir arquivos;
• erro começou depois de migração manual ou restauração de backup.

Evite recomendações genéricas como “coloque tudo em 777”. Permissões muito abertas podem comprometer a segurança do site. Se os logs apontarem permissão, confirme com a hospedagem qual é o padrão correto para aquele servidor.

Banco de dados e erro 500: quando suspeitar

Nem todo erro de banco aparece como erro 500. Muitas vezes o WordPress mostra “Erro ao estabelecer conexão com o banco de dados”. Ainda assim, problemas no banco podem derrubar páginas específicas, plugins ou rotinas.

Suspeite de banco quando:

• o erro aparece em páginas com consultas pesadas;
• o painel abre parcialmente;
• logs mostram erro MySQL/MariaDB;
• houve migração ou restauração recente;
• o site atingiu limite de banco na hospedagem;
• tabelas estão corrompidas;
• plugins de loja, membros ou LMS falham em consultas.

Não faça reparo, limpeza ou alteração direta no banco sem backup. Se você não tem experiência com phpMyAdmin, SQL ou WP-CLI, peça ajuda à hospedagem ou a um desenvolvedor.

Diagnóstico com WP-CLI: útil, mas avançado

WP-CLI pode ajudar quando o painel não abre, desde que sua hospedagem ofereça SSH e o comando wp esteja disponível.

Como regra de segurança, comece por comandos de leitura, que não alteram o site. Exemplos úteis em contexto técnico:

wp --info
wp core version
wp plugin list
wp theme list

Esses comandos ajudam a consultar ambiente, versão do WordPress, plugins e temas. Mesmo comandos aparentemente simples devem ser executados no diretório correto da instalação.

Evite rodar comandos que alteram banco, plugins, temas ou usuários se você não entende o impacto. Para uma visão mais completa, veja o guia sobre usar WP-CLI em hospedagem WordPress com segurança.

O que enviar para a hospedagem

Se você vai acionar o suporte, envie informações objetivas. Isso aumenta a chance de receber uma resposta útil. Também vale revisar se a estrutura contratada oferece logs, backup, staging e suporte compatíveis com o seu projeto; se precisar avaliar isso com calma, veja o guia sobre como escolher hospedagem WordPress.

Modelo de chamado:

Olá. Meu site WordPress está retornando erro 500.

Domínio/URL afetada: [URL]
Horário aproximado do início: [data, hora e fuso]
Onde ocorre: [site todo / wp-admin / página específica / checkout]
Mensagem exibida: [texto ou print]
Últimas mudanças feitas: [plugin, tema, PHP, cache, migração, atualização]
O que já testei: [cache, plugin, tema, .htaccess, debug]
Trecho relevante do log: [cole apenas o trecho necessário, sem dados sensíveis]

Podem verificar logs PHP/servidor, limite de memória/processos, permissões, WAF, status do banco e incidentes no servidor nesse intervalo?

Se você viu um erro específico no log, envie o trecho com horário e arquivo. Não envie senha, token, chave de API, acesso de administrador ou backup completo pelo chat sem um canal seguro.

Quando não tentar resolver sozinho

Pare e peça ajuda quando:

• o site é uma loja com pedidos recentes;
• há assinaturas, membros, cursos ou área restrita;
• o erro começou após invasão, malware ou alerta de segurança;
• logs indicam banco de dados corrompido;
• você precisa editar .htaccess, Nginx, wp-config.php ou permissões e não tem segurança;
• a hospedagem mostra limite de recursos ou processo encerrado;
• o erro envolve checkout, pagamento, webhooks ou estoque;
• você não tem backup confiável;
• o cliente depende do site para vendas ou captação de leads em tempo real.

Nesses casos, a melhor decisão pode ser acionar suporte da hospedagem ou desenvolvedor antes de tentar mais uma alteração.

Como prevenir o próximo erro 500

Depois que o site voltar, aproveite para reduzir risco futuro:

• mantenha rotina de backup externo e testado;
• use staging antes de mudanças importantes;
• atualize plugins e tema em janela planejada;
• evite muitos plugins sem manutenção;
• registre mudanças técnicas em um histórico simples;
• monitore uptime e erros;
• confirme se a hospedagem oferece logs acessíveis, suporte competente, backup e staging;
• mantenha PHP em versão suportada pela hospedagem e compatível com seus plugins;
• revise plugins de cache, segurança e otimização com cuidado.

Checklist final: erro 500 WordPress

Antes de considerar o problema resolvido, confirme:

• [ ] o site público abre em janela anônima;
• [ ] o painel /wp-admin abre;
• [ ] páginas críticas carregam sem erro;
• [ ] formulários funcionam;
• [ ] checkout funciona, se houver WooCommerce;
• [ ] login e área de membros funcionam, se houver;
• [ ] cache foi limpo e recriado;
• [ ] logs não continuam registrando erro fatal;
• [ ] plugins e tema foram reativados com controle;
• [ ] WP_DEBUG foi desativado depois do diagnóstico;
• [ ] arquivos temporários ou renomeados foram revisados;
• [ ] backup pós-correção foi feito;
• [ ] a causa provável foi registrada para evitar repetição.

Erro 500 no WordPress não deve ser tratado no improviso. Com backup, logs, triagem e evidências, você aumenta a chance de resolver com segurança — ou de acionar a hospedagem com tudo que ela precisa para investigar de verdade.