Erro interno servidor: como resolver o erro 500

Erro interno servidor é o nome do código de status HTTP 500, retornado quando o servidor encontra uma condição inesperada que o impede de concluir a requisição, sem informar qual é a causa. No WordPress, cinco origens respondem por quase todos os casos: arquivo .htaccess corrompido, limite de memória PHP esgotado, conflito de plugin ou tema, arquivo do core danificado e versão de PHP incompatível.

Você atualizou um plugin às 14h. Às 14h02, o site que sustenta suas matrículas ou seu checkout virou uma tela branca com uma linha de texto genérica.

E ninguém sabe por onde começar.

Esse é o ponto que quero atacar aqui: o erro 500 parece aleatório, mas segue um padrão bastante previsível. O que separa quem resolve em dez minutos de quem passa a tarde inteira tentando é a ordem das ações.

O erro 500 é sintoma, não diagnóstico

O internal server error pertence à classe 5xx, que sinaliza falha do lado do servidor. Isso o separa da classe 4xx, que aponta erro do cliente (o 404 é o exemplo mais conhecido).

Ou seja: quando você vê um erro interno servidor, o problema não está no navegador do visitante. Está no ambiente que executa o seu WordPress.

E por que o navegador não dá mais detalhes? Porque não deve. Segundo a documentação da Mozilla sobre o status HTTP 500, esse código é genérico por definição: o servidor sabe que algo quebrou, mas não expõe a causa raiz ao cliente. A mensagem real fica registrada nos logs internos, longe de olhos curiosos.

Pense no garçom que volta da cozinha e diz apenas que o prato não vai sair. A explicação está lá dentro, no fogão. O log é a sua cozinha.

Por isso, tratar o erro 500 como um problema único é o equívoco mais caro. Ele é o envelope. O conteúdo está no log.

As cinco causas que respondem pela maioria dos casos

Em manutenção de sites corporativos em WordPress, o erro interno do servidor se concentra em um conjunto pequeno de origens. A ordem abaixo reflete o que nosso time encontra com mais frequência em atendimentos de emergência:

• Arquivo .htaccess corrompido: diretivas de rewrite inválidas, normalmente inseridas por um plugin de cache ou por edição manual após migração, fazem o Apache rejeitar todas as requisições do domínio.

• Limite de memória PHP esgotado: importações grandes, builders visuais e plugins pesados consomem mais memória do que o memory_limit configurado, e o script morre no meio da execução.

• Conflito de plugin ou tema: uma atualização introduz uma chamada incompatível com outro plugin ou com o tema ativo, gerando erro fatal de PHP em toda requisição que carrega aquele código.

• Arquivos do core danificados: upload interrompido, falha de FTP ou problema de disco corrompem arquivos dentro de /wp-admin/ ou /wp-includes/, e o WordPress não consegue nem carregar o próprio bootstrap.

• Versão de PHP incompatível: tema ou plugin antigo usa função removida na versão de PHP do servidor, o que derruba a execução assim que aquele trecho é chamado.

Repare que nenhuma delas se chama erro 500. Todas produzem o mesmo status na tela do visitante, com correções completamente diferentes.

Diagnóstico primeiro: leia o log antes de tocar em qualquer arquivo

Diagnóstico cego custa receita por hora. E, pior, costuma criar um segundo problema em cima do primeiro.

Aqui na Apiki a regra é simples: ninguém mexe em arquivo antes de ler o log. Três fontes resolvem quase toda investigação.

Habilite o WP_DEBUG no wp-config.php

O modo debug do WordPress grava os erros de PHP em um arquivo dedicado. Abra o wp-config.php via SFTP e, acima da linha que avisa para parar de editar, inclua as constantes:

• define( ‘WP_DEBUG’, true ); ativa o registro de erros da aplicação.

• define( ‘WP_DEBUG_LOG’, true ); envia tudo para /wp-content/debug.log.

• define( ‘WP_DEBUG_DISPLAY’, false ); impede que o erro apareça na tela do visitante.

A documentação oficial de debugging do WordPress detalha cada constante. Em produção, mantenha o WP_DEBUG_DISPLAY como false, sempre. Erro exposto na tela entrega caminho de arquivo, versão de PHP e estrutura de diretórios para qualquer um.

Encontre o error_log do servidor web

Nem todo erro interno servidor chega ao debug do WordPress. Falhas de Nginx ou Apache acontecem antes do PHP rodar, então ficam só no log do servidor web.

Os caminhos típicos são /var/log/apache2/error.log e /var/log/nginx/error.log. Em hospedagem compartilhada, o arquivo costuma estar na raiz do site ou na pasta de logs do painel. A documentação de logs do Apache HTTP Server explica os formatos e onde cada distribuição grava esses registros.

Traduza o stack trace

A última linha do log quase sempre nomeia o culpado.

Allowed memory size exhausted significa memória PHP. Fatal error com caminho dentro de /wp-content/plugins/ significa plugin. Invalid command significa .htaccess. Cada padrão aponta para uma correção específica, e é isso que evita o clássico desativar tudo e torcer.

Como resolver o erro interno servidor passo a passo

Com o log em mãos, aplique só a correção correspondente. Uma de cada vez, testando entre elas.

1. Arquivo .htaccess corrompido

Acesse via SFTP e localize o .htaccess na mesma pasta de wp-admin e wp-includes. Renomeie para .htaccess_old e recarregue o site.

Voltou ao ar? Era ele. Agora vá em Configurações, Links permanentes e clique em salvar sem mudar nada: o WordPress regenera um arquivo limpo e suas URLs param de retornar 404. Se o erro apareceu logo depois de trocar de servidor, revise nosso guia de como migrar o .htaccess no WordPress antes de recriar regras na mão.

2. Limite de memória PHP esgotado

Adicione ao wp-config.php: define( ‘WP_MEMORY_LIMIT’, ‘256M’ );. No nível do servidor, ajuste a diretiva memory_limit do PHP no php.ini com memory_limit = 256M.

Atenção à sintaxe, porque muito tutorial erra aqui. É 256M, sem o B e sem espaço. Escrever 256MB é sintaxe inválida e simplesmente não surte efeito.

E um alerta que dou sempre: se você precisa subir memória de novo a cada dois meses, o problema não é o limite. É o que está consumindo.

3. Conflito de plugin ou tema

Pelo SFTP, renomeie /wp-content/plugins/ para /plugins_old/. Isso desativa tudo de uma vez, sem precisar do painel (que provavelmente também está fora).

Se o erro 500 sumiu, renomeie a pasta de volta e reative um plugin por vez até reproduzir a falha. Isolou o culpado, atualize, substitua ou reporte ao desenvolvedor. Se o erro persiste com todos desativados, troque o tema ativo por um tema padrão e teste de novo.

4. Arquivos do core danificados

Baixe uma cópia limpa da mesma versão do WordPress e substitua apenas /wp-admin/ e /wp-includes/ via SFTP. Esses diretórios não guardam seu conteúdo nem suas configurações, então a operação é segura.

Não substitua wp-content nem o wp-config.php. Nunca.

5. Versão de PHP incompatível

Log com Uncaught Error apontando função inexistente costuma ser incompatibilidade de versão. Verifique os requisitos do tema e dos plugins críticos e ajuste a versão de PHP no painel da hospedagem.

Rodar em uma versão que já saiu do suporte de segurança, conforme a lista de versões suportadas do PHP, é risco que não compensa. Vale acompanhar também o que muda a cada ciclo do core, como discutimos em WordPress 7.1: o que muda na sua operação WP.

Do log à correção: o mapa rápido

Quando a causa é a hospedagem, e não o WordPress

Nem todo erro interno servidor nasce dentro da aplicação. Alguns sinais são bem característicos.

Erro 500 que aparece só em horário de pico. Timeout intermitente sem padrão de página. Debug do WordPress silencioso enquanto o log do Nginx acumula registros de upstream.

Nesses casos, desativar plugin não resolve. O gargalo está em PHP-FPM, em conexões de banco, em limite de processos ou em falta de camada de cache. Distribuir estático em CDN ajuda a aliviar picos, e explicamos o caminho em como configurar CDN no WordPress, mas CDN não conserta infraestrutura subdimensionada.

Na experiência do nosso time com projetos corporativos, o erro 500 recorrente é quase sempre um sintoma de arquitetura, não um acidente isolado. Ele volta porque a causa nunca foi tratada.

Perguntas frequentes sobre erro interno servidor

O erro interno servidor prejudica o SEO do site?

Sim, se persistir. O Googlebot que encontra HTTP 500 adia o rastreamento daquela URL e, em quedas prolongadas, pode remover páginas do índice temporariamente. Falhas curtas e pontuais costumam ser toleradas, já indisponibilidade de horas ou dias afeta rastreamento, indexação e a experiência de quem chega pela busca.

Dá para resolver o erro 500 sem acesso a SFTP?

Parcialmente. Alguns painéis de hospedagem oferecem gerenciador de arquivos, visualização de logs e troca de versão de PHP pela interface web, o que cobre a maioria das correções descritas aqui. Sem nenhum desses recursos e sem acesso ao servidor, a saída é abrir chamado com a hospedagem pedindo o trecho do error_log referente ao horário da falha.

Por que o erro 500 aparece só no wp-admin?

Quando o site público carrega e apenas o painel retorna erro interno do servidor, a suspeita recai sobre um .htaccess específico dentro de /wp-admin/, sobre um plugin que roda somente no admin ou sobre memória insuficiente para telas pesadas, como a de atualizações. Comece pelo log e depois teste renomeando o .htaccess daquele diretório.

Qual a diferença entre erro 500 e erro 503?

Os dois são falhas de servidor, mas com significados distintos. O 500 indica uma condição inesperada que impediu o processamento da requisição, geralmente erro fatal de aplicação. O 503 indica indisponibilidade temporária, típica de manutenção programada ou de servidor sobrecarregado, e sinaliza para os buscadores que a situação deve ser passageira.

Conclusão

O erro interno servidor não é um mistério. É um envelope genérico que esconde uma causa específica, e essa causa está escrita no log.

Lê o log. Isola a causa. Aplica uma correção por vez. Valida.

O que preocupa não é o incidente isolado, é a reincidência. Site que devolve erro 500 toda vez que o tráfego sobe ou que um plugin atualiza está pedindo revisão de infraestrutura, não mais um ajuste de memory_limit.

Se esse é o seu caso, converse com o nosso time sobre uma avaliação de infraestrutura do seu ambiente WordPress. A gente olha log, stack e configuração de servidor antes de sugerir qualquer coisa.

E me conta: quando o seu site caiu pela última vez, alguém chegou a abrir o log ou o time foi direto desativando plugins?