Nesta página: [ocultar]
A própria tela de travamento do WordPress é um HTTP 500. O mesmo acontece com uma página em branco. O mesmo ocorre com a página sem estilo que seu servidor web exibe quando desiste. O manipulador de erros fatais do Core entrega um 500 resposta para wp_die() antes de imprimir “Ocorreu um erro crítico neste site.” O código de status é idêntico em todos os três casos, então não diz quase nada. O corpo da página diz muito. Quem imprimiu corta a lista de causas quase pela metade, antes de tocar em um único arquivo.
Resposta rápida: Leia o que foi renderizado, não o código. Uma página WordPress estilizada significa que o PHP foi executado, WordPress carregado, então um plugin ou tema morreu. Verifique a caixa de entrada do administrador do site para obter um link de recuperação. Uma página de servidor vazia, sem estilo WordPress, significa que a solicitação nunca chegou tão longe, então renomeie .htaccess e leia o log do servidor. Uma página em branco fica entre os dois, e o log de depuração resolve isso em cerca de um minuto.
Última revisão: setembro 2026. Constantes, memory defaults and PHP support dates verified against WordPress core documentation and php.net this month.
Three Screens, One Status Code
Every guide opens with a list of causes. Corrupt .htaccess, plugin conflict, memory limit, permissions, and so on down the page. That list is accurate and close to useless, because you can’t tell from a status code which entry applies to you. Sorting by what rendered is faster.
A styled WordPress page. Grey background, small centered box, the sentence “There has been a critical error on this website” with a link to a WordPress support page. This is core talking. PHP started, wp-config.php parsed, WordPress booted far enough to register its shutdown handler, and then something threw a fatal error. Almost always a plugin, um tema, or code you pasted into functions.php. Ir para the recovery section.
A bare server page. Times New Roman on white, the words “Erro do Servidor Interno”, maybe an Apache or LiteSpeed version string at the bottom. Or your host’s own branded error page. WordPress never got a word in. The failure happened in the web server, in the PHP process manager, or in a config file the server read before handing anything to PHP. Start at .htaccess.
Nothing at all. A white page, no text, view-source shows an empty document. PHP died with error display switched off, and either the fatal came before WordPress could install its handler, or the handler itself couldn’t finish. Fatals inside wp-config.php, inside a must-use plugin, or in an opcache-stale file land here. So do out-of-memory kills, because PHP can run out of memory while trying to render the error about running out of memory.
One more screen gets confused with this constantly. “Erro ao estabelecer uma conexão com o banco de dados” is not a 500. É o WordPress relatando que o MySQL recusou, e a correção reside nas credenciais do seu banco de dados, não está em nenhum dos arquivos abaixo.
O que este guia verificou, e o que não aconteceu
Onde um número aparece neste guia, veio de quem o publica, verificado em setembro 2026. Os padrões de memória e constantes de depuração vêm da documentação principal do WordPress e da referência de função do próprio núcleo. O comportamento do PHP vem do manual do PHP, especificamente as páginas em arquivos INI por diretório e em versões suportadas. As localizações dos registros vêm da documentação oficial de cada painel de controle, e não de uma postagem no fórum citando-a.
Excluímos três coisas de propósito. Conselhos que funcionam apenas em um host são sinalizados como tal, em vez de apresentados como gerais. Correções que exigem edições no banco de dados foram lançadas, porque um 500 o erro quase nunca se origina aí e o risco é desproporcional. E qualquer reclamação que não conseguimos rastrear até a página de um fornecedor ou à fonte principal foi descartada em vez de protegida.
A falha do plugin-package descrita posteriormente foi verificada em primeira mão. Baixamos três arquivos de lançamento do WordPress.org, listou seu conteúdo, e os comparou com o arquivo de inicialização do próprio plugin. Todo o resto aqui é trabalho de documentação. Não reproduzimos cada erro em um servidor ativo, e não comparamos nada. Também não podemos dizer qual causa é estatisticamente mais comum. Ninguém publica esses dados, e os guias que afirmam saber não citam a fonte.
Confirme se é realmente um 500
Os navegadores encobrem a diferença entre erros de servidor. O Chrome mostra a mesma página inútil para vários deles, e uma cópia em cache pode mostrar a falha de ontem. Verifique o cabeçalho da resposta real antes de gastar uma hora resolvendo o problema errado.
De um terminal, execute curl -i https://seusite.com. Use -i e não -I. A capital envia uma solicitação HEAD e joga fora o corpo da página, qual é a metade que informa quem imprimiu o erro. Em um navegador, abra DevTools, vá para a guia Rede, recarregar, e clique na solicitação principal. De qualquer forma, você quer o número de três dígitos, e importa qual você recebe:
- 500 significa que o servidor tentou e algo no seu aplicativo quebrou. Quase tudo abaixo se aplica.
- 502 significa um proxy na frente (geralmente NGINX) recebi uma resposta lixo do back-end com o qual estava conversando. Muitas vezes, um processo PHP-FPM que travou ou nunca foi executado.
- 503 significa que o servidor está ativo e recusando deliberadamente. Sobrecarga, um modo de manutenção, ou um limite de recursos que seu plano atingiu.
- 504 significa que o back-end foi alcançado, mas nunca foi respondido a tempo. Uma consulta lenta, uma chamada de API externa interrompida, um cron job comendo um trabalhador.
A definição é contundente sobre por que a primeira é tão vaga. A referência HTTP da Mozilla descreve 500 como um genérico genérico “indicando que o servidor não consegue encontrar um erro 5XX mais apropriado para responder com”. Um servidor que soubesse o que deu errado teria dito isso.
Duas coisas que vale a pena descartar no mesmo minuto. Carregue o site em uma janela privada. Um service worker ou um cache agressivo servirá alegremente uma página de erro armazenada muito depois de o site ser recuperado. E experimente o front end e /wp-admin separadamente. Um front-end que carrega enquanto o wp-admin lança 500 aponta para algum lugar específico, e voltamos a isso mais abaixo.
Quando o WordPress imprimiu a página
Se você tem o estilo “erro crítico” página, O WordPress já fez a maior parte do trabalho de diagnóstico e tentou lhe entregar a resposta. Desde a versão 5.2, core detecta erros fatais e pausa o que os causou. Em seguida, ele envia por e-mail o endereço em Configurações, Geral com um link para o modo de recuperação. Siga esse link e o plugin quebrado permanecerá desabilitado apenas para a sessão do seu navegador. Você pode fazer login e removê-lo enquanto os visitantes continuam vendo a página de erro.
Verifique essa caixa de entrada primeiro, spam incluído. Então saiba por que tantas vezes chega vazio.
A documentação do WordPress é franca sobre o modo de falha. Os plug-ins são carregados em ordem. Se o fatal disparar antes do carregamento do plugin SMTP, o e-mail sai através da função de e-mail do próprio servidor. Em um IP compartilhado sem alinhamento SPF, essa mensagem é filtrada ou descartada imediatamente. O alerta sobre o seu site quebrado está quebrado, by the same crash. You can’t fix that in the moment, but it does explain the missing email. Nosso guia para why WordPress stops sending email covers the deliverability side properly.
Getting the real error message
No email means you read the log instead. Two lines in wp-config.php, above the “pare de editar” comment:
- definir( "WP_DEBUG", verdade );
- definir( "WP_DEBUG_LOG", verdade );
Core writes to wp-content/debug.log por padrão. Reload the broken page once, then open that file and read the last entry. A PHP fatal names the file and the line number, and the folder in that path is your culprit. That’s the whole diagnosis, and it takes longer to describe than to do.
Leave WP_DEBUG_DISPLAY alone while you do it, or set it to false explicitly. Printing errors to the screen on a live site publishes your absolute server paths to anyone reloading the page (and some people go looking for exactly that).
Existe um instrumento mais contundente para os casos em que a tora fica vazia. Adicionando definição( ‘WP_DISABLE_FATAL_ERROR_HANDLER’, verdade ); desliga o manipulador completamente, então o próprio erro do PHP surge em vez do substituto educado do WordPress. Core verifica essa constante em wp_is_fatal_error_handler_enabled(), e o efeito é imediato. Use-o durante os trinta segundos necessários para ler a mensagem, então tire isso. Sem o manipulador, você também perde o modo de recuperação, e cada visitante vê o erro bruto.
Isolando o plugin ou tema
Você não pode clicar em Desativar em um painel que você não consegue acessar. Então faça isso a partir do sistema de arquivos. Verificações principais file_exists() em cada plugin ativo antes de carregar qualquer um deles, e silenciosamente ignora aqueles que desapareceram.
Por FTP ou pelo gerenciador de arquivos do seu host, renomear wp-content/plugins para desativar plug-ins. Recarregue o site. Se voltar, você encontrou a camada com defeito.
Então faça uma coisa antes de renomear a pasta de volta, porque a ordem importa mais do que qualquer guia admite. Carregue /wp-admin primeiro. Pular no front-end e desativar no banco de dados são dois comportamentos diferentes, manipulado por duas funções diferentes. O front-end simplesmente pula. Somente o lado administrativo executa valid_active_plugins(), que chama deactivate_plugins() e realmente escreve a mudança. Renomeie a pasta novamente sem visitar o painel e todos os seus plug-ins ainda estarão marcados como ativos, o quebrado incluído. O site morre novamente no momento em que você faz isso, e parece que o teste não provou nada.
Assim que o painel visualizar a pasta vazia, renomeie-o novamente e reative os plug-ins, um de cada vez, recarregando após cada. Aquele que mata o site novamente é a sua resposta. Mesma técnica para temas: renomeie a pasta do tema ativo e o WordPress voltará para a pasta padrão.
Com SSH, WP-CLI faz isso em um comando, e suas bandeiras globais são a parte útil. Executando o plugin wp desativado –tudo com –skip-plugins inicializa o WordPress sem carregar plug-ins. O fatal nunca dispara, então o comando é concluído. Observe o limite documentado: mu-plugins ainda carrega de qualquer maneira. Um fatal em wp-content/mu-plugins sobrevive a ambas as abordagens, e essa pasta tem que ser movida manualmente.
O maio 2026 caso que tornou isso concreto
Os plug-ins fatais geralmente vêm de um conflito, onde duas coisas que cada uma funciona sozinha não funcionam juntas. Às vezes, o pacote em si está quebrado, e um lançamento deste ano mostra o mecanismo de forma clara.
Códigos de acesso finais, um plugin ativo em 400,000 sites, versão enviada 7.5.1 em 18 Maio 2026 com o diretório /freemius/ incluído ausente do pacote. Linha 31 do arquivo principal dessa versão ainda chamado require_once em /freemius/start.php, sem verificação de file_exists em torno dele. Baixamos todos os três arquivos para confirmar. Versão 7.5.0 detém 223 arquivos nessa pasta, 7.5.1 não contém nenhum, e 7.5.3 restaura 222. O arquivo quebrado é um megabyte menor que o lançamento em ambos os lados dele.
Um require_once apontando para um arquivo que não existe é um erro fatal. Cada solicitação, cada visitante, sem exceções. O autor marcou o substituto, 7.5.3, na manhã seguinte 19 Maio 2026. Sua entrada no changelog é uma linha: “Corrigido problema com pasta /freemius/ ausente”. Versões 7.5.1 e 7.5.2 não aparece mais na lista de tags do plugin.
Duas coisas decorrem disso para qualquer um que esteja lendo um registro agora. Culpar um conflito é um palpite. Um fatal que nomeia um caminho de fornecedor dentro de uma pasta de plugin geralmente não é um conflito. E se o site morreu logo após uma atualização automática, reverter esse plugin em uma versão é um primeiro passo justo, não é um último recurso. A coisa quebrada pode já ter sido retirada.
A correção .htaccess, e aquele que sai pela culatra
Este arquivo é o primeiro suspeito quando o servidor imprimiu a página de erro, porque o Apache lê antes do PHP estar envolvido. Uma diretiva inválida retorna 500 para cada solicitação para esse diretório e tudo abaixo dele.
O reparo é uma renomeação, não é uma edição. Por FTP, renomeie .htaccess na raiz do WordPress para htaccess-old e recarregue. Site de volta? O arquivo era o problema. Vá para Configurações, Links permanentes no painel e clique em Salvar alterações sem alterar nada, e o WordPress escreve um bloco de reescrita limpo. Site ainda quebrado? Renomeie-o de volta e siga em frente, porque você o eliminou.
Agora a parte que confunde as pessoas. A maioria dos guias de erros 500 diz para você aumentar seu limite de memória adicionando uma linha como php_value memory_limit 256M a .htaccess. Em muita hospedagem em 2026, aquela linha é em si o 500.
Aqui está o mecanismo. php_value é uma diretiva fornecida por mod_php, o modelo antigo onde o PHP é executado dentro do processo Apache. Os hosts mudaram em grande parte para PHP-FPM ou FastCGI, onde o PHP é executado como um pool separado e o mod_php não é carregado. Apache atende a uma diretiva que nenhum módulo carregado reconhece, se recusa a servir o diretório, e retorna 500. O manual do PHP afirma claramente a divisão. Arquivos INI por diretório “são processados apenas pelo CGI/FastCGI SAPI”, e os usuários do módulo Apache são apontados para .htaccess para o mesmo efeito. Dois mecanismos, e você precisa daquele que seu host realmente executa.
Então, qual você tem? Descobrir leva um único arquivo, e quase nenhum guia diz para você olhar. Solte um arquivo chamado check.php na raiz da sua web, contendo uma chamada para phpinfo(). Carregue-o em um navegador e leia o API do servidor linha perto do topo.
“Apache 2.0 Manipulador” é mod_php, então php_value funciona. “FPM/FastCGI” ou “CGI/FastCGI” significa que não. “LiteSpeed V” é o ambíguo. Essa mesma string cobre LiteSpeed Enterprise, que homenageia php_value, e OpenLiteSpeed, que pega regras de reescrita de .htaccess e ignora o resto. Em qualquer um, pule a pergunta e use .user.ini. Em seguida, exclua check.php, porque phpinfo() entrega toda a configuração do seu servidor para qualquer um que adivinhar a URL. E se check.php lançar um 500 também, seu .htaccess ainda está quebrado e você ainda não o renomeou.
No FPM ou FastCGI o arquivo equivalente é .usuário.ini, colocado na raiz do WordPress, contendo memory_limit = 256M e nada mais. Uma pegadinha documentada vem com isso, e isso desperdiça muito tempo. PHP armazena em cache esses arquivos para 300 segundos por padrão, definido por user_ini.cache_ttl. Salve o arquivo, recarregue imediatamente, não vejo nenhuma mudança, e parece que a correção falhou. Não tem. Espere cinco minutos.
Duas armadilhas relacionadas residem no mesmo arquivo. Qualquer regra copiada de um tutorial que faça referência a um módulo que seu servidor não carrega faz exatamente o que php_value faz. O agressor usual é uma linha SecFilterEngine, colado para desligar um firewall. No NGINX, enquanto isso, nada disso se aplica. NGINX não possui mecanismo .htaccess, então o arquivo fica ali ignorado e não pode ser sua causa. LiteSpeed e OpenLiteSpeed leem, é por isso “verifique .htaccess” fica com bons conselhos sobre a maioria das hospedagens compartilhadas.
Limites de memória: The Real Numbers
The defaults are lower than most people assume, and knowing them saves you from raising a limit that was never the constraint.
WordPress sets WP_MEMORY_LIMIT to 40M em um único site, and 64M on multisite. It lifts the admin side to WP_MAX_MEMORY_LIMIT of 256M for heavier jobs like media handling and core updates. The core documentation adds the qualifier that matters. WordPress checks what PHP has been allocated first, and it can only request within that. If your host caps PHP at 128M, setting 512M in wp-config.php changes nothing.
That asymmetry between 40M and 256M also explains one common symptom directly. A site whose front end loads fine but whose dashboard throws 500 is often a site sitting between the two limits.
To test it, add define( "WP_MEMORY_LIMIT", ‘256M’ ); to wp-config.php and reload. If the error clears, treat that as a diagnosis and not a repair. Something in your stack is using six times the default to render one page. The honest next step is finding out what. Otherwise the next plugin you install pushes you over the new ceiling too.
File Permissions and Who Owns Your Files
Permission errors produce 500s reliably. They turn up most often after a migration or a restored backup, when files arrive owned by the wrong user.
The safe values are 755 para diretórios, 644 para arquivos. Set wp-config.php to 640 ou 600 if your host allows it. And don’t reach for 777 because a tutorial promised it would fix an upload problem.
Se 777 actually returns a 500 depends on your handler, and most advice on this point is about a decade out of date. suPHP refuses to run anything group-writable or world-writable, and it announces itself in the log with a distinctive string: SoftException em Application.cpp. O suEXEC do Apache aplica uma regra semelhante aos programas CGI. Ele verifica se o alvo está “NÃO gravável por mais ninguém”, e que o proprietário do arquivo corresponda ao usuário com o qual ele é executado. PHP-FPM não tem tal recusa, e o cPanel agora o recomenda no lugar do suPHP. Então, em uma pilha atual, 777 é um problema de segurança e não a causa do seu 500. Pesquise no log de erros essa string SoftException antes de gastar uma hora no chmod.
A propriedade é tão importante quanto o modo. Cada arquivo na raiz da sua web deve pertencer ao usuário da sua conta de hospedagem. Não fazer root, e não para o usuário do servidor web. Se uma correção de permissão não for necessária e você estiver em hospedagem compartilhada, abra um ticket aqui. A correção da propriedade precisa de acesso que sua conta não possui.
Saltos de versão do PHP
Um site que quebrou durante a noite sem nada alterado da sua parte foi frequentemente alterado do lado do seu host. Datas de fim de vida do PHP impulsionam atualizações programadas, e um plugin que não é atualizado há três anos atende a uma sintaxe que não existe mais.
As datas vêm direto da tabela de versões suportadas do php.net. PHP 8.1 parou de receber correções de segurança em 31 dezembro 2025. PHP 8.2 tem sido apenas de segurança desde o final de 2024, com seu próprio corte 31 dezembro 2026. PHP 8.3 passa patches 2027, 8.4 através 2028, e 8.5, lançado 20 novembro 2025, através 2029.
O próprio WordPress permaneceu parado enquanto o PHP se movia. WordPress 7.0 “Armstrong” enviado em 20 Maio 2026 e 7.1 “Maria Lou” em 19 agosto 2026, e nenhum deles elevou o nível do PHP acima 7.4. A recomendação ainda é PHP 8.3 ou mais recente. Essa lacuna é a armadilha. WordPress funciona perfeitamente em uma versão PHP que parou de receber correções de segurança anos atrás. Nada em seu painel avisa você, até que uma atualização do lado do host force o problema.
Se o seu painel de controle permite alternar versões do PHP, abandonar uma versão secundária é um teste rápido. Confirma a causa em menos de um minuto. Trate a reversão como temporária, Apesar. Agora você está executando um PHP mais antigo para acomodar o código que precisa ser substituído. Nosso guia para o WordPress “requer uma versão mais recente do PHP” aviso aborda como descobrir qual extensão está impedindo você.
Quando é o servidor, Não é o seu site
Alguns 500 não são seus para consertar, e identificá-los antecipadamente evita que você renomeie pastas que nunca foram o problema.
Uma regra de firewall falhando. ModSecurity geralmente retorna 403 quando bloqueia algo. Dois casos retornam 500 em vez de. Uma regra que falha durante o processamento da solicitação, ou uma linha .htaccess escrita para desligar o firewall onde isso não é permitido. A informação está no log de erros do servidor, onde as solicitações bloqueadas carregam um ID de regra entre colchetes. Você não pode ajustar essas regras em uma conta compartilhada, então este vai para o suporte com a linha de log anexada.
Um pool de processos PHP que morreu. Mais frequentemente um 502 do que um 500, mas vale a pena verificar quando os erros aparecem e desaparecem sob carga, e não em todas as solicitações. Falhas intermitentes relacionadas ao tráfego são um problema de recursos, não é um problema de código, e nenhuma renomeação de plugin os afeta.
Cota de disco. Uma conta completa deixa o PHP incapaz de gravar dados da sessão, arquivos temporários ou seu próprio log, e essas falhas surgem como um 500. Se o site estava bom há uma hora, verifique seu número de uso no painel de controle antes de mais nada.
Onde seu log de erros realmente reside
O log de depuração do WordPress registra erros de PHP dentro do WordPress. Não registra erros de sintaxe .htaccess, recusas de permissão ou bloqueios de firewall, porque isso acontece antes do PHP ser executado. Para aqueles que você precisa do log do servidor, e cada painel coloca em algum lugar diferente:
- cPanel: a interface Erros em Métricas. A própria documentação do cPanel descreve-o como aparecendo para 300 das entradas mais recentes, mais novo primeiro. Muitas configurações também descartam um arquivo error_log diretamente em public_html.
- Hostinger hPanel: Gerenciador de arquivos, em seguida, o diretório .logs na raiz da sua conta, segurando um arquivo chamado error_log_ mais seu domínio. Apenas erros de PHP, então falhas no nível do servidor não aparecerão lá.
- Ferramentas do site SiteGround: Estatisticas, em seguida, Log de erros para erros recentes detectados pelo servidor, com um arquivo php_errorlog na raiz do site para aqueles de nível PHP.
- Cloudways: a pasta logs dentro do diretório do seu aplicativo, acessível por SSH ou SFTP, com Apache separado, Arquivos NGINX e PHP.
- VPS simples: /var/log/apache2/error.log no Debian e Ubuntu, /var/log/httpd/error_log em sistemas da família RHEL, /var/log/nginx/error.log para NGINX.
Vale a pena reconhecer duas linhas de log do Apache à primeira vista. “Fim prematuro dos cabeçalhos do script” e “Fim da saída do script antes dos cabeçalhos” significa a mesma coisa. O script parou antes de retornar qualquer coisa que o servidor pudesse usar. Esse é um processo PHP que morreu no meio da solicitação, que aponta você de volta para o lado do PHP em vez do lado da configuração.
Qual correção tentar primeiro
Trabalhar todos os métodos acima em ordem é como um problema de quinze minutos se torna uma tarde. O que você fez por último, e o que ainda funciona, restringe mais rápido do que qualquer lista de verificação.
Algo mudou, e você sabe o que. Atualizou um plugin, funções editadas.php, colei um trecho, tema trocado. Desfaça aquela coisa, e nada mais. Se fosse uma atualização automática, verifique se a versão em que você está ainda existe no WordPress.org antes de depurá-la. A withdrawn release is not your bug to solve.
Nothing changed, and it broke overnight. This is host-side until proven otherwise. Check your PHP version first, then your disk quota, then the server error log. A scheduled PHP upgrade or a hit resource cap explains most of these, and neither leaves a trace in wp-content/debug.log.
Only /wp-admin throws 500. The front end loads fine, so memory is the first candidate, given core’s own 40M against 256M split. Second is a corrupted file in wp-admin or wp-includes. A clean core reinstall fixes that without touching your content. Replace those two directories from a fresh WordPress download, and leave wp-content and wp-config.php exactly where they are.
A browser and nothing else. No FTP, sem SSH, no file manager. Your host’s control panel almost certainly has a file manager, então comece por aí. Se isso não acontecer, a sequência é: verifique a caixa de entrada para obter um link de recuperação, em seguida, registre um ticket com a hora exata da primeira falha. O suporte pode ler logs que você não consegue.
Ele vem e vai. 500s intermitentes sob tráfego são um problema de capacidade. Renomear pastas de plugins não ajudará, e nem uma constante de memória. O limite que você está atingindo pertence à conta, não ao pedido. Ou o local precisa de menos peças móveis ou o plano precisa de mais espaço. Este é o lugar onde hospedagem gerenciada de WordPress deixa de ser um luxo, já que os limites de recursos e as atualizações de PHP são tratadas para você, em vez de anunciadas para você.
Parando de voltar
A maioria repete 500 traços de um hábito: atualizando ao vivo, tudo de uma vez, sem caminho de volta. Consertar isso é barato.
Atualize em pequenos lotes e recarregue o site entre eles. Dez plug-ins atualizados juntos fornecem dez suspeitos e nenhuma informação. Faça um backup antes de qualquer coisa que envolva o núcleo ou um plugin profundamente integrado. Em seguida, confirme que você pode restaurá-lo, porque um backup não testado é uma suposição sobre o futuro.
Defina o e-mail do administrador para uma caixa de correio que alguém lê. O modo de recuperação não vale nada se o link cair em uma caixa de entrada abandonada. Mantenha o PHP em uma versão que ainda esteja recebendo patches de segurança. A partir de setembro 2026 que inclui tecnicamente 8.2, mas só até 31 dezembro, tão 8.3 ou mais recente é o que deve estar ligado. Trate o aviso de atualização de um host como um prazo de teste, não é um anúncio para arquivar. E se um plugin estiver no centro do seu site, verifique seu histórico de lançamento de vez em quando. Aquele que envia um pacote quebrado uma vez tende a fazê-lo novamente.
A preparação é a verdadeira resposta, and plenty of shared plans now include it instead of reserving it for the expensive tiers. One click to copy the site, break the copy, and leave the live version alone. If your plan doesn’t have it, that’s worth weighing against price the next time you renew.
perguntas frequentes
What causes a 500 internal server error all of a sudden?
Algo mudou, even if you didn’t change it. On your side, that’s usually a plugin or theme update, an edit to functions.php, or a snippet pasted into wp-config.php. On your host’s side, it’s a PHP version upgrade, a hit resource cap, or a full disk. If you genuinely changed nothing, check your PHP version and your disk usage before you start renaming folders.
Can I fix a 500 internal server error myself, or do I need my host?
A maioria deles, sim. Renaming .htaccess, renaming the plugins folder, aumentar o limite de memória e corrigir permissões de arquivo funcionam via FTP ou gerenciador de arquivos. Três casos precisam do seu anfitrião. Problemas de propriedade de arquivos, Regras do ModSecurity disparando em suas solicitações, e pools PHP-FPM que continuam morrendo. Cada um precisa de acesso que sua conta não tem. Envie ao suporte o horário exato da falha, mais a linha de log, se você tiver uma.
Por que eu recebo um 500 erro apenas no wp-admin quando o front end funciona?
Geralmente memória. WordPress permite 40M por padrão no front-end, e aumenta para 256 milhões para tarefas administrativas. Um painel que morre enquanto o site carrega geralmente fica entre esses dois números, em um plano que não pode alcançar o mais alto. A outra causa comum é um arquivo corrompido em wp-admin ou wp-includes. Corrija isso substituindo os dois diretórios de um novo download do WordPress, leaving wp-content and wp-config.php alone.
Is a 500 error the same as 502, 503 ou 504?
Não, and the difference tells you who fixes it. UMA 500 means the application broke, so it’s usually yours. UMA 502 means a proxy got an invalid response from the backend, typically a dead PHP-FPM process. UMA 503 means the server is refusing requests deliberately, through overload or a maintenance mode. UMA 504 means the backend never answered in time. The last three point at infrastructure, so they go to your host with the timestamp attached.
How do I fix a 500 error if I can’t log in to WordPress at all?
You don’t need the dashboard for any of the main fixes. Renaming .htaccess and renaming wp-content/plugins both work over FTP or a hosting file manager. WordPress skips plugins whose folders have disappeared, embora você tenha que carregar /wp-admin uma vez para fazer com que ele fique no banco de dados. Com SSH, plugin wp desativar –tudo mais o –O sinalizador skip-plugins inicializa o WordPress sem carregar plug-ins, então o fatal nunca dispara. Se a falha ocorrer apenas na tela de login e não em todo o site, as causas do cookie e do bloqueio são uma lista separada.
Será que um 500 erro interno do servidor prejudicou minha classificação no Google?
Um curto não vai. A própria documentação de rastreamento do Google diz que erros 5xx fazem seus rastreadores “desacelerar temporariamente com o rastreamento”. Também diz que URLs já indexados são mantidos, então “eventualmente caiu” se o erro persistir. Então as horas estão bem, e os dias não são. Corrija-o no mesmo dia e é quase certo que você não verá nenhum efeito de classificação. O custo real durante uma interrupção é a perda de tráfego e a perda de confiança, não é uma penalidade duradoura depois.
Quanto tempo leva para consertar um 500 erro?
Se for .htaccess ou um único plugin, dez minutos, e a maior parte disso está esperando por FTP. Se for um limite de memória ou uma incompatibilidade de versão do PHP, uma hora ou duas, já que você está testando em vez de apenas reverter. Se for propriedade, uma regra de firewall ou um pool de processos em extinção, leva tanto tempo quanto a fila de ingressos do seu anfitrião. Esse é o verdadeiro argumento para identificar qual dos três você tem antes de começar.
A versão curta
Olhe a página antes de olhar uma lista de verificação. Um erro estilizado do WordPress significa que a falha ocorreu dentro do WordPress, então verifique a caixa de entrada do administrador para obter um link de recuperação e leia wp-content/debug.log. Uma página de servidor vazia significa que a falha ocorreu antes do carregamento do WordPress, então renomeie .htaccess, então verifique se os diretórios estão 755 e os arquivos são 644. Uma página em branco significa que desligar o manipulador de erros fatais por trinta segundos lhe dirá o que o PHP realmente viu.
Então resista à solução que todos recomendam sem qualificação. Adicionar php_value memory_limit a .htaccess é uma correção funcional no mod_php e um instante 500 é PHP-FPM, e o próprio manual do PHP diz qual é qual. Se o seu host executa FPM, o arquivo é .user.ini, e ele armazena em cache por cinco minutos antes que sua alteração faça alguma coisa.
Cheguei aqui com um sintoma diferente? Dois problemas vizinhos têm seus próprios guias. “Brevemente indisponível para manutenção programada” é uma atualização travada em vez de uma falha, e ele se limpa depois de dez minutos. Uma falha que atinge apenas a tela de login é um problema diferente novamente, com causas de cookie e bloqueio que nunca tocam em .htaccess.