Ecrã branco. Cinco caracteres: 500 Internal Server Error. O site está em baixo, o cliente está a enviar-lhe mensagens e não tem ideia por onde começar.

O erro 500 é o código de estado HTTP mais frustrante. Ao contrário do 404 («página não encontrada») ou do 403 («acesso negado»), não indica um culpado. Diz apenas «algo correu mal no servidor». A partir daí, está por sua conta: um plugin, tema, PHP com problemas, alojamento, .htaccess corrompido. Existem dezenas de possibilidades e cada uma exige uma correção diferente.

A boa notícia: um erro 500 pode sempre ser corrigido. Sem pânico, sem reinstalar o WordPress de raiz e, na maioria dos casos, sem um programador. Em 7 passos (de diagnósticos de 30 segundos à substituição cirúrgica de ficheiros do sistema) vai encontrar a causa e repor o site online. Cada método inclui ficheiros específicos, linhas de código e capturas de ecrã.

💡 Visão geral rápida:

• Passo 1: ativar WP_DEBUG e ler os registos para ver imediatamente qual o ficheiro com problemas
• Passo 2: excluir problemas de alojamento enquanto investiga o código
• Passo 3: corrigir o .htaccess, a causa número um de acordo com as estatísticas de suporte
• Passo 4: aumentar o limite de memória PHP, um culpado comum ao carregar multimédia ou iniciar sessão no admin
• Passo 5: recarregar o núcleo do WordPress quando os ficheiros são corrompidos por uma falha na atualização automática
• Passo 6: desativar plugins via FTP, um método que resolve mais de metade de todos os casos
• Passo 7: repor o tema padrão, um passo muitas vezes esquecido

O que é o erro 500 e de onde vem

HTTP 500 é uma resposta do servidor que significa «erro interno». O pedido do navegador chegou, o Apache ou Nginx aceitou-o, o PHP começou a correr e depois tropeçou. Ao contrário do 404 ou 403 (onde o servidor responde conscientemente «não»), um cinco no início do código significa que algo se partiu dentro do script e o servidor não sabe o quê.

No WordPress, o erro 500 ocorre em quatro cenários típicos:

• Instalou ou atualizou um plugin e este entra em conflito com outro código no sistema.
• Modificou o .htaccess e um erro de sintaxe fez o Apache ir abaixo.
• Um script PHP esgotou a memória que lhe foi atribuída (ecrã branco com Allowed memory size of X bytes exhausted nos registos).
• Ficheiros do núcleo corrompidos: uma falha na atualização automática, uma transferência FTP interrompida, um plugin com mau comportamento que adulterou pastas do sistema.

Menos comum: um tema com um erro fatal no functions.php, problemas do lado do alojamento (sobrecarga, módulo PHP desativado) ou um shortcode quebrado de um plugin removido dentro do conteúdo da página.

Antes de começar: faça uma cópia de segurança completa do seu site. Sem uma cópia de segurança, qualquer ação nos ficheiros do servidor é um risco. A maioria dos alojamentos oferece um botão de cópia de segurança no painel de controlo (cPanel, ISPmanager, aaPanel) com apenas dois cliques.

1. Ativar WP_DEBUG e ler os registos

A forma mais rápida de encontrar a causa é fazer com que o WordPress a revele. Por predefinição, o núcleo esconde os erros de PHP atrás de um ecrã branco (este é o modo «não assustar os visitantes»). Mas o WordPress tem um mecanismo de depuração integrado: as constantes WP_DEBUG.

Ativar o modo de depuração

Abra o wp-config.php na raiz do seu site via FTP ou através do gestor de ficheiros do seu alojamento. Encontre esta linha:

1
/* That's all, stop editing! Happy blogging. */

Antes dela, insira este bloco:

1
// Enable debug mode
2
define( 'WP_DEBUG', true );
3
 
4
// Write errors to /wp-content/debug.log
5
define( 'WP_DEBUG_LOG', true );
6
 
7
// Do not show errors to visitors on screen
8
define( 'WP_DEBUG_DISPLAY', false );
9
@ini_set( 'display_errors', 0 );

O que está a acontecer aqui:

• WP_DEBUG é o interruptor principal; sem true, as outras constantes não funcionam.
• WP_DEBUG_LOG direciona todos os erros para wp-content/debug.log em vez do ecrã. Os visitantes não veem mensagens assustadoras.
• WP_DEBUG_DISPLAY + @ini_set esconde forçosamente os erros da saída da página.

Guarde o ficheiro, atualize a página problemática no seu site e descarregue wp-content/debug.log via FTP. No registo verá o ficheiro e a linha específicos: Fatal error: Cannot redeclare my_function() in /home/user/public_html/wp-content/plugins/broken-plugin/broken.php on line 42.

Desative a depuração após os diagnósticos. Comente ou apague as linhas que adicionou. O WP_DEBUG num site ativo reduz o desempenho e o debug.log pode crescer até gigabytes ao longo do tempo.

2. Contacte o seu fornecedor de alojamento

Se os registos estiverem vazios ou não foram criados, o erro pode estar do lado do servidor e não no código do WordPress. Isto é especialmente comum em planos de alojamento partilhado baratos com limites de processos rigorosos.

Abra um ticket de suporte e anexe três coisas:

• A hora exata a que o erro apareceu, com o fuso horário do servidor.
• O URL da página onde o erro se reproduz.
• Uma captura de ecrã do erro, se disponível.

O suporte irá verificar os registos do servidor Apache ou Nginx, a carga de CPU e memória e os módulos PHP disponíveis. Os problemas resolvem-se frequentemente neste passo: um administrador do alojamento reinicia o PHP-FPM ou ajusta o limite de processos.

Como saber de que lado está o problema

Crie um ficheiro chamado info.php com uma única linha:

1
<?php phpinfo(); ?>

Carregue-o para a raiz do seu site via FTP e abra your-site.com/info.php. Se vir uma tabela com parâmetros PHP, o servidor está a funcionar e o erro está no código do WordPress. Se vir 500, o erro está ao nível do servidor; forneça este URL ao suporte.

Após o teste, elimine info.php. O phpinfo() expõe versões do servidor, caminhos e módulos, criando uma falha de segurança.

3. Corrigir o ficheiro.htaccess

O .htaccess é um ficheiro de configuração do Apache na raiz do seu site. O WordPress utiliza-o para URLs legíveis, redirecionamentos e regras básicas de segurança. Um parêntese a mais, um conflito entre regras de dois plugins e o site inteiro vai abaixo com um erro 500. De acordo com as estatísticas de tickets de suporte, o .htaccess acaba por ser a causa número um.

Verificação rápida: renomeie .htaccess para .htaccess_old via FTP e atualize o site. Se funcionar, o problema está definitivamente neste ficheiro.

Agora restaure o .htaccess: vá a administração do WordPress, Definições → Links permanentes e clique em «Guardar alterações» sem modificar a estrutura. O WordPress irá gerar um novo .htaccess limpo com as regras padrão:

1
RewriteEngine On
2
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
3
RewriteBase /
4
RewriteRule ^index\.php$ - [L]
5
RewriteCond %{REQUEST_FILENAME} !-f
6
RewriteCond %{REQUEST_FILENAME} !-d
7
RewriteRule . /index.php [L]

Se tinha regras personalizadas no .htaccess (redirecionamentos, cache, segurança), volte a adicioná-las uma a uma e verifique o site após cada uma. Assim identificará a linha problemática.

4. Aumentar o limite de memória do PHP

Os scripts PHP do WordPress precisam de RAM. Quando um plugin ou tema solicita mais do que o atribuído, o script quebra. O resultado: um erro 500 ou uma página branca com Allowed memory size of X bytes exhausted.

O limite padrão em muitos alojamentos ainda é de 64 MB. Para um site WordPress moderno com uma dúzia de plugins, isso é catastroficamente baixo. O mínimo recomendado é 256 MB.

Método 1: via wp-config.php (preferencial)

Adicione isto ao wp-config.php antes de /* That's all, stop editing! */:

1
define( 'WP_MEMORY_LIMIT', '256M' );

Esta constante substitui o limite de PHP para a parte pública do site. Para a área de administração, o WordPress eleva automaticamente o teto para WP_MAX_MEMORY_LIMIT (256 MB por defeito).

Método 2: via php.ini (se o seu alojamento não permitir editar o wp-config)

Crie um ficheiro php.ini com este conteúdo:

1
memory_limit = 256M

Carregue-o para a raiz do site e para a pasta wp-admin/. Se isso não resolver, crie ou edite o .user.ini na raiz do site com a mesma linha.

Se nenhum dos métodos funcionar, o seu plano de alojamento limita fisicamente a memória. Está na altura de atualizar o plano ou mudar de fornecedor.

5. Reenviar os ficheiros principais do WordPress

Um ficheiro principal corrompido é uma causa incomum, mas insidiosa. Uma falha na atualização automática, uma transferência FTP interrompida, um plugin que modificou ficheiros do sistema, e o wp-admin ou wp-includes contém lixo.

Procedimento:

• Transfira um arquivo ZIP novo do WordPress a partir de wordpress.org.
• Extraia o arquivo no seu computador.
• Via FTP, vá à raiz do seu site e elimine as pastas wp-admin e wp-includes (apenas essas duas; não toque no wp-content!).
• Envie as pastas wp-admin e wp-includes do arquivo novo.
• Não substitua o wp-content; é lá que vivem os seus temas, plugins e uploads.

Os ficheiros raiz (wp-settings.php, index.php e outros) também podem ser substituídos pelos novos do arquivo. Exceto o wp-config.php; não lhe toque porque contém as suas credenciais da base de dados. Após a substituição, atualize o site; o erro desaparecerá se a causa forem ficheiros de sistema corrompidos.

6. Desativar plugins

Um plugin problemático é a causa mais provável de um erro 500. Atualizou vários plugins de uma vez e um colidiu com outro: olá, ecrã branco.

Se a área de administração funcionar

Vá a Plugins → selecionar todos → ação em massa "Desativar" → "Aplicar". Se o erro desaparecer, ative os plugins um a um, atualizando o site após cada um. Quando encontrar o culpado, elimine-o ou reporte o problema ao programador.

Se a área de administração estiver inacessível

Ligue-se ao servidor via FTP e renomeie a pasta wp-content/plugins para plugins_off. O WordPress deixará de carregar todos os plugins e o site voltará à vida. Devolva o nome original à pasta e renomeie as subpastas dos plugins uma de cada vez; assim encontrará o problemático sem entrar na administração.

Ao que estar atento: plugins de cache (W3 Total Cache, WP Rocket) por vezes escrevem as suas próprias regras no .htaccess e wp-config.php. Após desativar um plugin desses, o erro pode persistir; verifique estes ficheiros e remova as linhas entre marcadores como # BEGIN W3TC e # END W3TC ou semelhantes.

7. Mudar para o tema padrão

O tema ativo é uma fonte subestimada, mas real, de erros 500. Especialmente se adicionou um snippet com um erro fatal ao functions.php.

A verificação é simples: via FTP, renomeie a pasta do tema ativo em wp-content/themes/ (por exemplo, mytheme → _mytheme). O WordPress detetará que o tema ativo está em falta e mudará automaticamente para um padrão: Twenty Twenty-Five ou outro tema padrão instalado no sistema.

Se o site funcionar com o tema padrão, o problema está no seu. Devolva o nome original ao tema, abra o functions.php e procure erros no código personalizado. Se não foi você a adicionar o código, contacte o programador do tema.

⁉️🤔 Perguntas frequentes

O que devo fazer se o erro 500 aparecer apenas ao iniciar sessão na administração?

Muito provavelmente, o limite de memória PHP não é suficiente especificamente para o painel de administração, que carrega todos os plugins de uma vez e é mais pesado do que o front-end. Adicione a linha define( 'WP_MAX_MEMORY_LIMIT', '512M' ); ao wp-config.php; este é um limite separado para a administração, mais alto do que o WP_MEMORY_LIMIT do front-end. Verifique também a sua pasta de plugins: na nossa experiência, os culpados mais comuns são plugins de segurança como o Wordfence ou plugins de backup que consomem memória ao carregar a barra de administração. Desative-os via FTP (a pasta plugins_off do passo 6) e verifique.

Posso corrigir um erro 500 sem acesso FTP?

Sim. A maioria dos alojamentos fornece um gestor de ficheiros no painel de controlo: cPanel → File Manager, ISPmanager → Ficheiros. Através dele pode renomear o .htaccess, as pastas de plugins e temas, e editar o wp-config.php; todos os passos são os mesmos. Sem qualquer acesso a ficheiros, a sua única opção é a equipa de suporte do alojamento. Dica profissional: se tiver um plugin de snippets instalado (Code Snippets, WPCode) e a sua última ação foi adicionar um snippet, tente abrir your-site.com/?code_snippets_safe_mode=1 ou um URL de modo de segurança semelhante para o seu plugin. Isto desativa todos os snippets sem FTP.

O erro 500 aparece apenas numa página. Qual é a causa?

Uma função ou shortcode avariado dentro do conteúdo dessa página específica. Abra a página no editor do WordPress (se a administração funcionar) e remova temporariamente todos os shortcodes, blocos Gutenberg e incorporações de código. Se a administração estiver inacessível, encontre o artigo na base de dados via phpMyAdmin (a tabela wp_posts), copie o conteúdo para um editor de texto e remova os shortcodes suspeitos. Os culpados mais comuns: shortcodes de plugins eliminados ([dead_plugin] permanece, mas o plugin desapareceu), PHP avariado em blocos de conteúdo ou blocos Gutenberg incorretamente aninhados.

Após a recuperação, o erro 500 volta após algumas horas. Como encontro a causa?

Um erro cíclico com um intervalo é quase sempre um de três cenários: uma tarefa cron do WordPress executa um processo avariado de forma programada, um plugin de cache gera cache corrompida ou o alojamento atinge periodicamente os limites de processos (especialmente em planos partilhados baratos). Instale o WP Crontrol e verifique a lista de tarefas cron; encontre a que coincide com a hora da falha. Limpe a cache do seu plugin de cache. Pergunte ao seu alojamento sobre o limite de Entry Processes ou PHP Workers; em planos partilhados, são frequentemente reduzidos para 5 a 10, e um pico de tráfego deita o site abaixo.

Preciso de passar por todos os 7 passos ou posso saltar alguns?

Os dois primeiros passos (WP_DEBUG e alojamento) são de diagnóstico: não partem nada e fornecem informação. Na nossa experiência a dar suporte a sites WordPress, o passo 3 (.htaccess) e o passo 6 (plugins) resolvem a grande maioria dos casos. Os restantes resumem-se à memória PHP, núcleo corrompido e ao tema. Numa situação típica, resolverá o problema nos passos 3 ou 6 sem percorrer toda a cadeia.

Por onde começar agora mesmo

Não repita o cenário típico: pânico → apagar tudo aleatoriamente → piorar as coisas. Siga a ordem do diagnóstico à correção:

A regra principal para reparações no WordPress: uma ação, uma verificação. Nunca faça duas correções ao mesmo tempo; não saberá qual funcionou. E anote exatamente qual o plugin ou edição que causou o erro. Da próxima vez, resolverá tudo em 30 segundos.