Loja WooCommerce fora do ar? Erro 500 e tela branca: como diagnosticar

Sua loja caiu. Erro 500 na página inicial, tela branca no lugar do catálogo ou um aviso de “erro crítico” no lugar do checkout. Cada minuto parado é uma venda que não acontece — e o cliente que encontra a loja fora do ar pode não voltar.

O primeiro impulso é sair mexendo: desativar todos os plugins, reiniciar o servidor, restaurar o primeiro backup que aparecer. É o erro mais comum — e o que mais prolonga a queda. Este artigo entrega o método de diagnóstico que usamos em atendimentos reais de lojas WooCommerce fora do ar: uma sequência de passos na ordem certa, que funciona mesmo sem acesso ao painel, para colocar a loja no ar sem piorar o problema.

O custo de uma queda é fácil de estimar. Use a fórmula: receita anual ÷ horas operacionais do ano × horas fora do ar. Uma loja que fatura R$ 360 mil por ano e opera 16 horas por dia (cerca de 5.840 horas) perde, em média, R$ 62 por hora parada. Uma queda de 8 horas representa quase R$ 500 só em faturamento direto — sem contar clientes que desistem e não voltam.

Para efeito de comparação: o relatório ITIC 2024 — pesquisa anual de custo de indisponibilidade do Information Technology Intelligence Consulting — estima em mais de US$ 300 mil por hora o custo de indisponibilidade para empresas médias e grandes no mercado internacional — a direção vale, a escala não.

---

Primeiro, identifique o sintoma com precisão

Cada erro aponta para uma camada diferente — aplicação, servidor ou cache. Diagnosticar o sintoma errado leva ao remédio errado e horas perdidas. Antes de qualquer coisa, entenda o que cada mensagem significa na prática.

Erro 500 (Internal Server Error)

O mais comum de todos. É uma resposta genérica do servidor: “algo quebrou, mas não vou dizer o quê”. As causas possíveis são várias: um erro fatal de PHP, um limite de memória estourado, um arquivo .htaccess corrompido (em servidores Apache), permissões erradas ou configuração do servidor. Como a mensagem não detalha nada, o diagnóstico depende dos logs — que é exatamente o que faremos na próxima seção.

Tela branca (white screen of death)

A página carrega sem nenhum conteúdo: fundo branco, nada de texto, nada de erro. Na maioria dos casos, é um erro fatal que acontece muito cedo no carregamento, antes de o WordPress exibir qualquer coisa — por exemplo, um erro de sintaxe em um arquivo carregado no início, como wp-config.php ou um plugin carregado antes do tema — mas também pode resultar de memória esgotada ou de falhas silenciosas em outras camadas. Não há mensagem para o visitante, mas o erro fica registrado no log.

“Houve um erro crítico neste site”

Desde o WordPress 5.2 (maio de 2019), quando acontece um erro fatal, o WordPress exibe “Houve um erro crítico neste site” e envia um e-mail ao administrador com um link de recuperação. Esse link coloca a loja em modo de recuperação temporário e permite acessar o painel para corrigir o plugin ou tema problemático — além de exibir mais detalhes sobre o erro. Se você recebeu esse e-mail, guarde-o: ele já entrega parte do diagnóstico pronto.

Erros 502, 503 e 504: quando o problema é do servidor

• 502 (Bad Gateway): o servidor não conseguiu falar com o serviço por trás dele — por exemplo, o PHP-FPM caiu ou travou.
• 503 (Service Unavailable): o servidor está sobrecarregado ou em manutenção. Durante atualizações do WordPress, um arquivo .maintenance é criado e causa 503 temporário.
• 504 (Gateway Timeout): o servidor demorou demais para responder — por exemplo, recurso esgotado ou processamento travado.

Estes três frequentemente envolvem o servidor ou serviços upstream, mas não são exclusivamente problemas de infraestrutura: podem ter origem ou gatilho na aplicação, em proxy ou CDN, no banco de dados ou em configuração. A ação não se limita ao painel: verifique recursos e logs, reinicie serviços, cheque proxy/CDN e configuração ou fale com a hospedagem. Se a loja cai e volta sozinha em minutos, pode ter sido apenas um pico — mas picos repetidos merecem investigação (mais sobre isso na seção de prevenção).

Erro 500 só no checkout

Este é o caso específico WooCommerce: o restante da loja funciona, mas a tela de finalização da compra quebra. É um erro fatal no processamento do pedido — nos hooks de checkout ou no plugin do gateway de pagamento. O detalhe crítico: o pedido pode não ser criado no painel, e o cliente pode ser cobrado sem confirmação. Tratamos disso em detalhes na seção dedicada ao checkout.

O painel também está fora?

Teste o acesso a seudominio.com.br/wp-admin. O resultado separa duas hipóteses:

• Painel OK, loja em branco: suspeite de cache servindo HTML vazio. O front-end foi cacheado em um momento de erro e está sendo reentregue página vazia. Limpe o cache do plugin, da CDN e do servidor.
• Painel e site fora do ar: é o mesmo erro de aplicação ou de servidor atingindo tudo. Siga o diagnóstico normal.

O que anotar antes de qualquer coisa

Cinco minutos de registro economizam horas de diagnóstico:

• Hora exata em que a queda começou (e se houve outras quedas antes).
• URL afetada: loja inteira, página específica ou só o checkout.
• Mudanças recentes: atualização de plugin ou tema, plugin novo, edição de código, mudança de hospedagem ou de PHP.
• Mensagem exata exibida e o que o e-mail de recuperação (se houver) diz.
• O que você já tentou — para não repetir e para informar o suporte com precisão.

---

As causas mais comuns de erro 500 e tela branca em lojas WooCommerce

Em ordem aproximada de frequência, os culpados costumam ser:

• Plugin ou tema com erro fatal ou incompatível — atualização recente, plugin abandonado, ou componente que exige um PHP mais novo que o da hospedagem.
• Limite de memória PHP estourado — a loja não tem memória suficiente para carregar os processos.
• Arquivo .htaccess corrompido — só em servidores Apache e LiteSpeed; o nginx ignora esse arquivo.
• Permissões de arquivo erradas — comum depois de migrações e restaurações de backup.
• Recursos da hospedagem esgotados — CPU e memória no limite, ou conta suspensa por sobrecarga.
• Banco de dados indisponível ou corrompido — a loja não consegue ler produtos, pedidos ou configurações.
• Atualização interrompida — núcleo, plugins ou temas pela metade, com arquivos faltando.
• Cache servindo página vazia — o front em branco com o painel funcionando.
• Gateway de pagamento incompatível — causa típica do erro 500 restrito ao checkout.

Essa lista serve de referência mental enquanto você executa os passos a seguir. Vamos ao método.

---

Como diagnosticar uma loja WooCommerce fora do ar na ordem certa (mesmo sem acesso ao painel)

A regra de ouro: isolar antes de mexer, e um passo por vez. Depois de cada passo, recarregue a loja e teste. E registre o resultado de cada tentativa — isso orienta o próximo passo e ajuda a explicar o problema para a hospedagem, se for o caso.

1. Registre o sintoma e as mudanças recentes

Volte às anotações da primeira seção: hora, URL afetada, mensagem exata e o que mudou na loja nas últimas 24 horas. A frase mais comum em atendimentos é “não mudei nada” — e na sequência descobrimos a atualização automática do plugin de pagamento na noite anterior. Mudanças recentes são o atalho número um para a causa.

2. Leia o log de erros da hospedagem

Este é o caminho mais rápido e sem risco. No painel da hospedagem (cPanel, hPanel ou similar), procure por “Error Logs” ou “Logs de Erros”. O log registra os erros de PHP com arquivo e linha exata — por exemplo, PHP Fatal error: Call to undefined function em wp-content/plugins/meu-plugin/arquivo.php na linha 42. Com essa linha em mãos, metade do diagnóstico já está feito. Não há risco nenhum aqui: você só está lendo.

3. Ative o modo de depuração do WordPress

Sem acesso ao painel, você ainda tem FTP ou o gerenciador de arquivos da hospedagem. Abra o wp-config.php e adicione estas linhas antes da linha “Isso é tudo, pare de editar!” (o comentário de encerramento do arquivo):

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Salve e recarregue a loja. A documentação oficial do modo de depuração do WordPress explica cada constante. Atenção: WP_DEBUG_DISPLAY deve ficar em false em produção — com true, mensagens de erro e caminhos de arquivos aparecem para qualquer visitante, o que é risco de segurança. Ao terminar o diagnóstico, remova as linhas: a documentação oficial não recomenda manter as ferramentas de depuração ativas em sites em produção. Para acompanhamento contínuo, use os logs de erro PHP do servidor (painel da hospedagem) e os logs do WooCommerce.

4. Leia o wp-content/debug.log

Com o modo de depuração ativo, o WordPress registra todos os erros em wp-content/debug.log. Abra esse arquivo pelo gerenciador de arquivos ou baixe-o por FTP. A mensagem aponta o arquivo e a linha exata do erro fatal — na prática, o nome do plugin ou tema culpado aparece na primeira linha do log. Este é o passo que transforma o diagnóstico de tentativa e erro em certeza.

5. Desative os plugins

No gerenciador de arquivos, renomeie a pasta wp-content/plugins para wp-content/plugins.bak. Sem a pasta com o nome original, o WordPress ignora todos os plugins de uma vez. Anote o nome original da pasta antes de renomear. Atenção: com os plugins desativados, a loja não processa pedidos — o WooCommerce também está desligado. Se a loja voltar ao ar, o problema está em um dos plugins. Para encontrá-lo, renomeie a pasta de volta para plugins (a loja volta com todos os plugins ativos — e pode cair de novo, o que é esperado durante o teste) e:

• Se o painel estiver acessível: desative os plugins um por um na tela Plugins do admin, testando a loja após cada desativação. Quando a loja voltar a funcionar, o plugin que você acabou de desativar é o culpado.
• Se o painel continuar inacessível: desative por arquivos, renomeando a pasta de cada plugin uma por uma (por exemplo, meu-plugin → meu-plugin.bak), testando a loja após cada renomeação. Quando a loja voltar, o plugin desativado é o culpado.

Se a loja não voltar nem com todos os plugins desativados, o problema não está nos plugins: restaure o nome original (plugins.bak → plugins) e siga para o próximo passo.

6. Troque para o tema padrão

Ainda no gerenciador de arquivos, renomeie a pasta do tema ativo em wp-content/themes (por exemplo, meu-tema → meu-tema.bak). Sem encontrar o tema ativo, o WordPress cai automaticamente para o tema padrão da sua versão do WordPress, como o Twenty Twenty-Four. Se a loja voltar, o problema é do tema — e você pode renomear a pasta de volta e investigar o tema em separado. Se a loja voltou com aparência diferente, não se assuste: é o tema padrão no lugar, temporariamente. Atenção: ao cair para o tema padrão, o WordPress troca o tema ativo no banco de dados — para voltar ao tema original depois do teste, renomeie a pasta de volta e reative o tema em Aparência → Temas.

7. Verifique o arquivo .htaccess

Em servidores Apache (e LiteSpeed), um .htaccess corrompido derruba a loja com erro 500. Renomeie para .htaccess.bak — se esse era o problema, a loja volta imediatamente, e o WordPress recria o arquivo na próxima vez que as regras de permalink forem salvas. Em servidores nginx, o .htaccess é ignorado: pule este passo.

8. Verifique permissões e a integridade do wp-config.php

Pastas 755, arquivos 644 e wp-config.php com permissões mais restritas (440 ou 400) são referências comuns, mas a configuração correta depende do dono dos arquivos (ownership), do servidor e da hospedagem — não aplique esses valores indiscriminadamente. Permissões erradas são comuns depois de migrações e restaurações. Confira também se o wp-config.php está íntegro: credenciais do banco de dados corretas e sem caracteres quebrados — uma edição corrompida nesse arquivo derruba a loja antes de tudo carregar.

9. Aumente temporariamente a memória PHP

Se o debug.log apontar erros de memória (Allowed memory size exhausted), adicione no wp-config.php:

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

Trate como remendo para ganhar tempo, não como cura: se a loja voltar, a causa — um plugin guloso ou um limite baixo da hospedagem — continua lá. Atenção: WP_MEMORY_LIMIT só consegue elevar o limite se a configuração do PHP e da hospedagem permitir, e aumentar a memória não substitui o diagnóstico da causa. O remendo precisa virar correção.

10. Cheque hospedagem e banco de dados

Nenhum passo anterior funcionou? O problema pode estar fora do alcance do painel. No painel da hospedagem, verifique: uso de CPU e memória, se a conta foi suspensa por sobrecarga e se o DNS aponta para o servidor certo. No phpMyAdmin, abra o banco da loja e confira se as tabelas carregam sem erro. Não rode reparos por conta própria sem saber o que está fazendo — o suporte da hospedagem pode ajudar a verificar.

11. Restaure um backup limpo e recente

Se existe um backup limpo de antes da queda, restaure-o — arquivos e banco de dados. Lembre-se do custo: a loja volta ao estado do backup, e pedidos, estoque e configurações do período ficam para trás. E o passo mais importante: antes de reabrir, descubra o que causou o problema. Restaurar sem entender a causa é programar a próxima queda — muitas vezes na semana seguinte, em horário de pico.

Atenção: se a queda veio acompanhada de redirecionamentos estranhos, usuários desconhecidos no admin ou arquivos .php suspeitos em wp-content/uploads, não é um erro comum — é provável invasão. Nesse caso, a prioridade é conter o dano antes de restaurar. Veja o guia de loja WooCommerce hackeada antes de qualquer restauração.

---

Quando o problema é específico do checkout (erro 500 ao finalizar a compra)

Quando o erro 500 aparece só na finalização da compra, o alvo muda: é um erro fatal no processamento do pedido — nos hooks do WooCommerce (como woocommerce_checkout_process) ou no plugin do gateway de pagamento.

O risco aqui é específico de e-commerce e dobrado: o pedido pode não ser criado no painel, e o cliente pode ser cobrado sem confirmação. Resultado: venda perdida, cliente no suporte e, em casos piores, chargeback.

O diagnóstico usa as mesmas ferramentas: o debug.log aponta o arquivo e a linha exata, e o WooCommerce guarda seus próprios registros em WooCommerce → Status → Logs, que podem capturar falhas de gateway com detalhes — os nomes dos arquivos de log dependem da fonte (gateway, pagamentos, plugins) e alguns gateways só registram se o logging estiver habilitado nas próprias configurações. Para confirmar, teste com o gateway em modo sandbox e um pedido de valor baixo, acompanhando se o pedido aparece em WooCommerce → Pedidos. A documentação de solução de problemas de erros de pagamento do WooCommerce lista as causas e verificações mais comuns. Se o erro só aparece com o gateway real, as hipóteses vão além da incompatibilidade de versão: credenciais ou configuração do modo live, API, notificações/webhooks, chamadas REST, resposta do processador ou indisponibilidade externa. Para o passo a passo completo, veja nosso artigo sobre checkout com erros.

---

Como evitar que a loja fique fora do ar

Prevenção é mais barata que correção — e, no caso de loja, a correção custa vendas. Uma rotina básica reduz drasticamente o risco:

• Monitore o uptime. Ferramentas gratuitas como o UptimeRobot verificam a loja a cada poucos minutos e avisam por e-mail no primeiro sinal de queda (alerta no WhatsApp exige uma integração, como o Zapier). Monitore também uma página de checkout ou de carrinho, não só a home — quedas no checkout muitas vezes não aparecem no monitoramento da página inicial.
• Atualize uma coisa por vez. Plugin por plugin, tema, núcleo — nunca tudo junto. E sempre com backup feito antes. Se algo quebrar, você sabe exatamente o que foi.
• Prefira staging quando possível. Atualizar em um ambiente de teste antes da loja real elimina a maioria dos sustos.
• Teste o backup de verdade. Gerar o arquivo não basta: restaure-o periodicamente em um ambiente de teste. Backup que não restaura não existe.
• Dimensione os recursos da hospedagem para os picos. Campanhas e Black Friday derrubam lojas que rodavam bem no dia a dia.
• Acompanhe pelos logs do servidor e do WooCommerce. Os logs de erro PHP da hospedagem e os logs do WooCommerce (WooCommerce → Status → Logs) ficam disponíveis sem depender do modo de depuração do WordPress — que a documentação oficial não recomenda manter ativo em produção.
• Mantenha o PHP atualizado e compatível com a sua versão do WooCommerce. PHP desatualizado é causa frequente de erro 500 logo após atualizações.

Uma loja WooCommerce instável — que cai e volta sozinha, sem explicação — é o estágio anterior à queda longa. O monitoramento e os logs transformam essa instabilidade em diagnóstico antes que ela vire prejuízo.

---

Quando chamar um especialista

O método acima resolve a maioria dos casos. Há situações, porém, em que a tentativa caseira sai mais cara:

• Você não tem acesso a FTP nem ao gerenciador de arquivos da hospedagem.
• Não existe backup recente da loja.
• A loja caiu, voltou e caiu de novo — queda recorrente indica causa não resolvida.
• O problema está no checkout e envolve dados de pagamento.
• Há suspeita de invasão, com qualquer um dos sinais da caixa de aviso.

Nesses casos, o custo de errar — horas de loja parada, pedidos perdidos, dados de clientes em risco — supera o custo de um profissional. A Panacea é especialista em manutenção de lojas WooCommerce: diagnóstico técnico profundo, correção e prevenção de recorrência. A análise inicial é gratuita e sem compromisso. Comece por um diagnóstico com um Especialista WooCommerce.

---

Perguntas frequentes

Como resolver erro 500 no WordPress sem acesso ao painel?

Pelo FTP ou gerenciador de arquivos da hospedagem, nesta ordem:

1. Leia o log de erros da hospedagem (aponta arquivo e linha).
2. Ative o modo de depuração no wp-config.php e leia o wp-content/debug.log.
3. Desative os plugins renomeando a pasta wp-content/plugins.
4. Troque o tema ativo renomeando a pasta dele e verifique o .htaccess (servidores Apache).

Teste a loja depois de cada passo — e nunca reative tudo de uma vez.

Erro 500 ao finalizar a compra no WooCommerce: o que fazer?

O restante da loja funciona, mas a finalização quebra — o erro está no processamento do pedido ou no gateway. Leia o debug.log e os logs em WooCommerce → Status → Logs; teste com o gateway em modo sandbox e pedido de valor baixo; confira se o pedido foi criado em WooCommerce → Pedidos. Enquanto o problema existir, considere informar os clientes ou pausar vendas: o pedido pode não ser criado e o cliente pode ser cobrado sem confirmação.

Tela branca no WordPress é problema de hospedagem?

Geralmente não. Tela branca é, na maioria dos casos, um erro fatal de aplicação que acontece cedo demais no carregamento — tema, plugin ou wp-config.php com erro de sintaxe. Já os erros 502, 503 e 504 no WordPress costumam envolver o servidor ou serviços upstream: PHP-FPM parado, servidor sobrecarregado ou timeout. A distinção prática: tela branca e erro 500 pedem diagnóstico de arquivos e logs; 502/503/504 costumam exigir verificação de servidor, proxy/CDN, banco de dados ou configuração.

Quanto tempo a loja pode ficar fora do ar sem perder posições no Google?

Não existe percentual ou prazo oficial — mas as orientações do Google são claras. Falhas 5xx persistentes reduzem o rastreamento da loja e podem levar URLs a sair do índice; indisponibilidades curtas tendem a ser tratadas como temporárias, e para interrupções planejadas e curtas o Google recomenda responder com HTTP 503. O foco correto não é “quanto posso ficar fora”, e sim “como ficar fora o mínimo possível” — com monitoramento, backups testados e atualizações controladas.

---

Uma loja virtual fora do ar por horas é cara, mas é evitável — com método na crise e prevenção depois dela. Se a sua loja caiu agora e você não sabe por onde começar, o diagnóstico não precisa ser feito sozinho. A Panacea oferece análise inicial gratuita: solicite com um Especialista WooCommerce e coloque a loja no ar com quem resolve.