De Olho

erro 500 wordpress

Erro 500 no WordPress: o site respondeu, mas avariou-se a meio.

Um ecrã branco, ou "Ocorreu um erro crítico neste site". O servidor está de pé — o PHP é que rebentou a meio da execução. Em quase todos os casos foi um plugin, e há uma forma de o descobrir sem entrar no painel.

O erro 500 é o código que um servidor devolve quando não sabe o que dizer. Recebeu o pedido, começou a construir a resposta e a execução morreu pelo caminho — normalmente porque o PHP encontrou um erro fatal, ficou sem memória ou tentou usar uma função que não existe na versão que está instalada.

A parte que confunde no erro 500 é que o servidor está bom. O Apache ou o Nginx responderam, a máquina está ligada, o alojamento não caiu. O que falhou foi o código que corre por cima — e é por isso que reiniciar o servidor não resolve nada e mudar de alojamento resolve ainda menos.

No WordPress, o culpado tem quase sempre nome. Um plugin actualizou-se, um tema chamou uma função removida numa versão nova do PHP, ou o `wp-content` ficou com um ficheiro a meio de um upload. A boa notícia é que se descobre por eliminação, e a eliminação faz-se por FTP mesmo quando o painel não abre.

// a ficha

O que este código diz, em cinco linhas.

Código
500 Internal Server Error
Família
5xx — erro do servidor
Quem responde
o servidor web, depois de o PHP falhar
Do lado de quem
do servidor, nunca do visitante
Aparece a toda a gente
sim — não é a tua ligação

// causas prováveis

Por onde é que isto costuma vir.

Por ordem de frequência e não por ordem de gravidade. A primeira da lista explica mais casos do que as outras todas juntas.

  • Um plugin actualizou-se e levou o site

    É a causa em mais de metade dos casos, e é pior quando as actualizações automáticas estão ligadas: o site cai sozinho, sem ninguém ter tocado em nada, muitas vezes de madrugada. Se o erro apareceu sem intervenção humana, começa por aqui.

  • A versão do PHP mudou por baixo

    O alojamento passou de PHP 7.4 para 8.2 e um tema antigo usa sintaxe que deixou de existir. Acontece em migrações e em actualizações de painel de alojamento — e o site funcionava perfeitamente na véspera.

  • Memória esgotada

    O `memory_limit` do PHP acabou a meio de uma importação, de um backup ou de uma página de administração pesada. Costuma ser intermitente: o site abre, o wp-admin não, ou ao contrário.

  • O .htaccess ficou corrompido

    Um plugin de cache ou de segurança escreveu regras que o servidor não aceita. Renomear o ficheiro para `.htaccess.old` é um teste de dez segundos que elimina esta hipótese por completo.

  • Ficheiros do core partidos

    Uma actualização do WordPress interrompida a meio, ou um upload por FTP que caiu. Raro, mas é o que sobra quando os plugins e o tema já foram eliminados.

// diagnóstico

Passo a passo, do que custa menos ao que custa mais.

Cada passo elimina hipóteses. Saltar um passo poupa dois minutos e costuma custar uma hora — a ordem é a parte que interessa.

  1. 01

    Confirma que o erro é do servidor e não teu

    Abre o site numa janela anónima e, se puderes, pelos dados do telemóvel. Se continuar, o problema não é cache nem a tua rede. Podes confirmar de fora com o "Está em baixo, ou és só tu?" — um 500 devolvido a um servidor em Portugal é um 500 para toda a gente.

  2. 02

    Liga o registo de erros do WordPress

    No `wp-config.php`, põe `WP_DEBUG` a `true` e `WP_DEBUG_LOG` a `true` — os erros passam a escrever em `wp-content/debug.log` em vez de darem ecrã branco. O ficheiro diz-te a linha e o ficheiro exactos. Deixa `WP_DEBUG_DISPLAY` a `false` para não mostrar o erro a quem visitar o site entretanto.

  3. 03

    Desliga os plugins todos de uma vez, por FTP

    Não precisas do painel. Renomeia a pasta `wp-content/plugins` para `plugins-off`. Se o site voltar, é um plugin — volta a pôr o nome certo e desactiva-os um a um, pela ordem inversa da última actualização.

  4. 04

    Troca o tema pelo tema por omissão

    Se os plugins não eram, renomeia a pasta do tema activo. O WordPress cai para um tema padrão sozinho. Se o site abrir, é o tema — e quase sempre é a versão do PHP a que ele não sobreviveu.

  5. 05

    Sobe a memória e limpa o .htaccess

    Acrescenta `define("WP_MEMORY_LIMIT", "256M");` ao `wp-config.php` e renomeia o `.htaccess`. Se o site voltar sem o ficheiro, gera-o outra vez guardando as permaligações nas definições — não o escrevas à mão.

  6. 06

    Pede o log de erros do servidor ao alojamento

    Se chegaste aqui, o `debug.log` do WordPress não apanhou. O log do PHP-FPM ou do Apache apanha, e o suporte do alojamento tem acesso a ele. Manda a hora exacta do erro — é a primeira coisa que te vão pedir.

O primeiro passo é sempre o mesmo — ver de fora o que o servidor responde de facto. Faz isso aqui, a partir de um servidor em Portugal. Sem conta, sem custo, e não guardamos o que verificares.

verificar_site servidor: PT

// que não volte

Como evitar que volte a acontecer sem dares por isso.

Resolver o incidente é metade do trabalho. A outra metade é a parte que ninguém factura e é a que decide se há um terceiro.

  • Desliga as actualizações automáticas de plugins

    Num site de cliente, uma actualização automática é uma alteração ao código em produção sem ninguém a olhar. Actualiza à mão, num dia útil, com tempo para reverter. As de segurança do core são a excepção sensata.

  • Testa em staging antes de mudar a versão do PHP

    Quase todos os alojamentos deixam clonar o site para um subdomínio. Subir o PHP num clone custa dez minutos; descobrir a incompatibilidade em produção custa o dia.

  • Tem um backup que já tenhas restaurado uma vez

    Um backup que nunca foi testado é uma suposição. Restaura um para staging de vez em quando — é a única forma de saber que a cópia serve.

  • Faz alguém dar por isso antes do cliente

    Um erro 500 não avisa ninguém. O site continua a responder ao servidor, o alojamento não vê nada de errado e o Google só repara horas depois. Sem uma verificação de fora a correr sozinha, o aviso é o telefonema.

// limites

Onde é que esta página encalha.

Uma página de diagnóstico que não diz onde acaba manda-te dar voltas até desistires. Estes são os casos em que não chega.

  • Se o erro só aparece a alguns visitantes, isto não chega. Um 500 intermitente costuma ser memória ou um processo a ser morto por excesso de recursos, e vê-se no log do servidor e não no do WordPress.
  • Se não tens FTP nem gestor de ficheiros, os passos 3 a 5 ficam fechados. Sem acesso aos ficheiros, o caminho é o suporte do alojamento — e vale a pena pedir acesso antes de precisares dele.
  • Um 500 no wp-admin com o site público a funcionar é outro problema. Costuma ser memória ou um plugin só de administração, e diagnostica-se pelo mesmo método mas a partir do passo 3.
  • Nada disto diz porque é que o plugin rebentou. Diz qual foi. A causa a sério está no `debug.log`, e é isso que se manda a quem o escreveu.

// perguntas

O que nos perguntam a seguir.

O erro 500 apaga alguma coisa da base de dados?

Não por si. O erro 500 é a execução a parar, não a escrever. O risco existe quando o erro apanha uma migração a meio — uma actualização de plugin que estava a alterar tabelas. Por isso é que o backup se faz antes de actualizar e não depois de rebentar.

Porque é que vejo um ecrã branco em vez da mensagem de erro?

Porque o PHP está configurado para não mostrar erros a quem visita — o que está certo em produção. O erro existe na mesma e está no log. Liga o `WP_DEBUG_LOG` e ele aparece em `wp-content/debug.log`.

Reinstalar o WordPress resolve?

Reinstalar resolve o caso raro em que os ficheiros do core estão partidos, e não toca no `wp-content` nem na base de dados. Mas se a causa era um plugin, o erro volta assim que ele voltar a correr — por isso é que a eliminação vem primeiro.

// erros vizinhos

Se afinal não era este.

Metade do diagnóstico é perceber que se estava a olhar para o erro errado. Estes três são os que mais se confundem com este.

E se acontecer às três da manhã?

Um erro 500 num site de cliente costuma durar o tempo que demorar até alguém reparar. Não há aviso: o alojamento não vê problema nenhum, o site continua a responder e o único sinal é o telefonema. A De Olho vai fazer este pedido a cada minuto e avisar-te quando a resposta deixar de ser 200 — inclusive às três da manhã, que é a hora a que as actualizações automáticas costumam correr.

A De Olho abre em 2026 e ainda não dá para usar. Quem estiver na lista de espera fica a saber primeiro e mantém o preço de lançamento enquanto a subscrição durar.

Só te escrevemos sobre o lançamento. Sem spam, e não partilhamos o teu email com ninguém. Como tratamos os teus dados.