Um erro 500 no Elementor quase nunca é um bug do plugin — é um limite do PHP sendo estourado. Os três que causam praticamente todos os casos são o memory_limit (memória insuficiente para abrir o editor), o max_input_vars (poucos campos permitidos ao salvar uma página) e o max_execution_time (o salvamento demora mais do que o PHP permite). Aumente esses três e a maioria dos erros 500 no Elementor simplesmente para de acontecer.
Esse é o atalho, e ele é específico o suficiente para ser útil. Mas qual limite você está estourando depende de quando o erro aparece — ao abrir o editor, ao salvar, ou na página publicada. Este guia liga o sintoma ao limite e mostra como aumentar cada um.
O Elementor consome bem mais recursos que um plugin comum, e o erro 500 costuma significar que o PHP ficou sem algo. Os valores mínimos que o próprio Elementor recomenda:
| memory_limit | 256M ou mais |
| max_input_vars | 4000 ou mais |
| max_execution_time | 300 |
| post_max_size | 64M |
Confira os seus valores atuais em Elementor → Informações do Sistema. Se a hospedagem limita esses valores, peça ao suporte para aumentar — num plano decente, é um pedido de dois minutos.
Conteúdo
Primeiro: quando o erro aparece?
Essa única pergunta reduz as possibilidades mais rápido que qualquer outra coisa, porque cada limite falha num momento diferente.
| Quando o 500 aparece | Causa mais provável |
|---|---|
| Ao abrir o editor — carregando para sempre, ou tela em branco | memory_limit baixo, ou conflito de plugin. O editor carrega toda a biblioteca de widgets de uma vez |
| Ao clicar em Atualizar numa página complexa | max_input_vars estourado — o erro 500 mais comum do Elementor. Páginas complexas enviam milhares de campos num único POST |
| O salvamento demora muito e falha | max_execution_time atingido |
| Ao enviar uma imagem ou template | upload_max_filesize ou post_max_size pequenos demais |
| Na página publicada, mas o editor funciona | Arquivos de CSS ausentes — regenere-os. Ou conflito com um widget de terceiros |
| Logo após uma atualização | Versões incompatíveis entre Elementor e Elementor Pro, ou um pacote de addons desatualizado |
Comece pelas Informações do Sistema
Antes de mudar qualquer coisa, veja o que o Elementor já sabe. Vá em Elementor → Informações do Sistema no painel do WordPress.
Ele mostra os seus valores reais de memory_limit, max_input_vars, max_execution_time e post_max_size, a versão do PHP, e quais extensões estão instaladas. Também destaca em vermelho qualquer valor abaixo do mínimo recomendado.
É o diagnóstico mais rápido disponível, e quase todo mundo pula. Se as Informações do Sistema mostram max_input_vars em 1000 e você está editando uma página com dezenas de widgets, achou a resposta em dez segundos.
Causa 1: max_input_vars — a mais específica do Elementor
Essa é a causa que diferencia o erro 500 do Elementor de um erro 500 comum do WordPress, e vale entender o mecanismo.
Quando você clica em Atualizar, o Elementor não envia um pacote pequeno. Ele envia todas as configurações de todos os widgets da página como variáveis POST separadas — espaçamentos, cores, tipografia, breakpoints responsivos, animações. Uma página com cinquenta widgets gera facilmente milhares de variáveis.
O max_input_vars do PHP limita quantas ele aceita. O padrão costuma ser 1000. Quando a página ultrapassa, o PHP trunca a requisição em silêncio — e o salvamento falha com erro 500 ou, pior, salva pela metade e perde configurações.
O sinal: páginas simples salvam normalmente, as complexas falham. Quanto mais widgets, maior a chance do erro.
O Elementor recomenda 4000 ou mais. Em páginas pesadas, 10000 não é exagero.
Causa 2: memory_limit
O editor do Elementor carrega a biblioteca completa de widgets, o seu tema e todos os plugins ativos numa única requisição. Isso consome muito mais memória que um carregamento normal de página.
Se o editor não abre, ou fica com o indicador girando sem parar, a memória é o primeiro suspeito. O padrão do WordPress (40M) não é suficiente; o Elementor recomenda 256M, e sites com muitos addons às vezes precisam de mais.
Vale notar que o WordPress tem um limite próprio acima do limite do PHP. Definir WP_MEMORY_LIMIT no wp-config.php não adianta se o memory_limit do PHP for menor — vale sempre o menor dos dois. Nosso guia sobre como aumentar o limite de memória do WordPress detalha os dois lados.
Causa 3: max_execution_time
Salvar uma página complexa envolve gravar bastante dado e regerar o CSS. Se o PHP interromper o script no meio, você recebe um erro 500 e o salvamento se perde.
O padrão costuma ser 30 segundos — suficiente para o WordPress comum, apertado para o Elementor. 300 dá folga confortável. Veja o guia sobre max_execution_time.
Como aumentar os limites
O método depende da sua hospedagem. Tente nesta ordem:
1. Pelo painel de controle. No cPanel, use o MultiPHP INI Editor ou Selecionar versão do PHP → Opções. No DirectAdmin, o equivalente fica nas configurações de PHP. É a forma mais limpa e não mexe nos arquivos do site.
2. Pelo php.ini, se você tiver acesso:
memory_limit = 256M
max_input_vars = 4000
max_execution_time = 300
post_max_size = 64M
upload_max_filesize = 64M
3. Pelo .htaccess, no Apache — mas atenção: o max_input_vars normalmente não pode ser definido aqui, e é por isso que o painel ou o php.ini são preferíveis:
php_value memory_limit 256M
php_value max_execution_time 300
php_value post_max_size 64M
php_value upload_max_filesize 64M
Vale lembrar que editar diretivas de PHP no .htaccess pode, ele próprio, gerar um erro 500 em servidores CGI/FPM — é o mesmo cuidado que vale ao ajustar o upload_max_filesize.
Para uma leitura mais aprofundada, recomendamos este artigo sobre o htaccess do WordPress.
4. Peça à sua hospedagem. Em planos compartilhados esses valores costumam estar travados no servidor. Uma boa hospedagem aumenta em minutos — e se a sua recusa ou demora dias, isso diz algo sobre a hospedagem, não sobre o Elementor.
Depois de mudar qualquer coisa, volte às Informações do Sistema e confirme que os novos valores foram aplicados. Editar um arquivo que o servidor ignora é o motivo número um de as pessoas acharem que “já aumentei o limite e não resolveu”.
Se não for limite do PHP
Com os limites corretos e o erro persistindo, siga por aqui:
Regenere os arquivos de CSS. O Elementor guarda o CSS gerado em /wp-content/uploads/elementor/css/. Se esses arquivos sumirem ou corromperem — comum depois de uma migração — as páginas quebram enquanto o editor funciona normalmente. Vá em Elementor → Ferramentas → Regenerar CSS e Dados.
Use o Modo de Segurança do Elementor. Em Elementor → Ferramentas → Modo de Segurança, ele carrega o editor com um tema padrão e sem os outros plugins. Se o editor funcionar assim, você tem um conflito — e agora sabe que não é o Elementor. Reative os plugins um a um para achar o culpado.
Confira as versões. Elementor e Elementor Pro precisam estar em versões compatíveis. Atualizar um sem o outro é causa frequente de erros 500 repentinos. Pacotes de addons de terceiros são o suspeito seguinte, já que costumam demorar a acompanhar as versões novas.
Confirme as extensões do PHP. O Elementor precisa de zip, dom, gd, mbstring e curl. As Informações do Sistema mostram quais estão presentes. Uma extensão faltando num servidor mal configurado produz falhas que parecem bugs.
Leia o erro de verdade. Se nada acima funcionar, ative o log de depuração do WordPress e deixe o servidor dizer o que aconteceu — nosso guia sobre o HTTP erro 500 percorre a sequência completa de diagnóstico.
Por que o Elementor estoura limites que outros plugins não estouram
Vale dizer com clareza, porque explica o padrão: o Elementor não é mal feito — ele simplesmente faz muito mais trabalho por requisição que um plugin comum.
O editor é uma aplicação completa rodando dentro do WordPress. Ele carrega uma biblioteca grande de widgets, renderiza pré-visualização em tempo real e serializa cada propriedade de design de cada elemento. Isso significa mais memória, mais variáveis POST, mais tempo de execução. Uma configuração que roda um blog WordPress comum sem problema pode ser genuinamente apertada demais para o Elementor.
É também por isso que os erros 500 no Elementor têm forte correlação com hospedagem barata e com limites travados. Se a sua hospedagem não aumenta o max_input_vars além de 1000, você vai continuar batendo nessa parede por mais que mexa no WordPress.
Nossa hospedagem WordPress é preparada para Elementor e Elementor Pro, com os limites de PHP que o construtor realmente precisa — e se precisar de mais, o suporte aumenta em vez de explicar por que não pode. Servidor no Brasil, CloudLinux, backup automático e atendimento em português.
Ver hospedagem WordPressPerguntas frequentes
Por que o Elementor dá erro 500?
Quase sempre porque um limite do PHP foi atingido, não por causa de um bug. Os três mais comuns são o memory_limit (memória insuficiente para carregar o editor), o max_input_vars (poucas variáveis POST permitidas ao salvar uma página complexa) e o max_execution_time (o salvamento demora mais do que o PHP permite). Confira os seus valores em Elementor → Informações do Sistema.
Quais configurações de PHP o Elementor precisa?
O Elementor recomenda no mínimo 256M de memory_limit, max_input_vars de 4000 ou mais, max_execution_time de 300 e post_max_size de 64M. Também exige as extensões zip, dom, gd, mbstring e curl. As Informações do Sistema mostram os valores atuais e destacam o que estiver abaixo do mínimo.
Por que o Elementor não salva minha página?
A causa habitual é o max_input_vars estourado. O Elementor envia cada configuração de cada widget como uma variável POST separada, então uma página complexa gera milhares delas. Quando o total ultrapassa o limite do PHP, a requisição é truncada e o salvamento falha — muitas vezes com erro 500. Aumentar o limite para 4000 ou mais resolve.
Como aumentar o max_input_vars para o Elementor?
A forma mais confiável é pelo painel da hospedagem: no cPanel, use o MultiPHP INI Editor ou Selecionar versão do PHP. Também é possível definir no php.ini como max_input_vars = 4000. Note que o .htaccess normalmente não consegue alterar essa diretiva específica, por isso o painel ou o php.ini são preferíveis. Em hospedagem compartilhada o valor pode estar travado — nesse caso, peça ao suporte.
O editor do Elementor não carrega. É o mesmo problema?
Geralmente sim, mas o limite é outro: um editor que não abre aponta para o memory_limit, não para o max_input_vars, porque o editor carrega toda a biblioteca de widgets, o tema e todos os plugins numa única requisição. Aumente a memória para 256M ou mais e depois use o Modo de Segurança para descartar conflito de plugin.
O que é o Modo de Segurança do Elementor?
É uma ferramenta em Elementor → Ferramentas que carrega o editor com um tema padrão e todos os outros plugins desativados. Se o editor funcionar no Modo de Segurança, o problema é um conflito e não o Elementor em si — basta reativar os plugins um a um para encontrar o responsável.
O Elementor funciona no editor, mas a página publicada está quebrada. Por quê?
Isso aponta para arquivos de CSS gerados ausentes ou corrompidos, que ficam em wp-content/uploads/elementor/css/ e costumam quebrar depois de uma migração de site. Vá em Elementor → Ferramentas → Regenerar CSS e Dados. Se não resolver, um widget de addon de terceiros usado naquela página é o suspeito seguinte.
O erro 500 é culpa do Elementor ou da minha hospedagem?
Geralmente da configuração da hospedagem. O Elementor faz muito mais trabalho por requisição que um plugin comum, então limites que rodam um site WordPress simples podem ser apertados demais para ele. Se a sua hospedagem não aumenta o max_input_vars acima de 1000 ou a memória acima de 128M, a parede vai continuar aparecendo por mais que você mexa no WordPress.
Veja também
O erro 500 no Elementor é um caso específico do HTTP erro 500, que cobre todas as outras causas. Se o seu site usa CDN, veja também erro 500 no Cloudflare para saber de onde o erro está vindo.
Conclusão
O erro 500 no Elementor é um problema de recursos fantasiado de bug. Abra as Informações do Sistema primeiro, porque o Elementor já sabe qual dos seus valores de PHP está baixo e diz isso em dez segundos. Na maioria das vezes é o max_input_vars — o limite que só falha em páginas complexas, e é por isso que o erro parece aleatório até você entender o mecanismo. Aumente a memória para 256M, o max_input_vars para 4000, o tempo de execução para 300, confirme que os novos valores realmente foram aplicados, e a maior parte desses erros simplesmente para. Se não parar, o Modo de Segurança diz se é conflito, e o Regenerar CSS resolve os casos de página publicada.
