Se você já tem um site em Elementor e está só decidindo, a resposta curta é: compensa migrar para o Gutenberg quando você quer acabar com o lock-in e ganhar performance a longo prazo — mas migração é um custo real, quase sempre um rebuild.
Decisão em 40 palavras: migre se busca site mais leve, fim da licença recorrente e manutenção mais barata no longo prazo. Não migre agora se o site só está lento (resolva hosting e cache antes) ou se é um e-commerce complexo que já funciona.
Este guia não repete a comparação de recursos — para isso, veja Elementor vs Gutenberg. Aqui a pergunta é outra e mais concreta: eu já tenho Elementor. Compensa trocar? Vamos falar de custo, de TCO em 3 anos e de execução sem quebrar o site.
A resposta curta (e a honesta)
A Pixelize recomenda o Gutenberg: é nativo, não tem lock-in, permite blocos customizados, gera menos código e não cobra licença. É para onde o WordPress aponta o futuro. Mas recomendar não é esconder o custo — e o custo da migração é real.
Para quem vale a pena migrar:
- Quem quer site mais leve e melhores Core Web Vitals.
- Quem está cansado de pagar a licença recorrente do Elementor Pro.
- Quem vai fazer um redesign de qualquer forma — migrar junto é o momento mais barato.
- Quem quer parar de depender de um construtor de terceiros para editar o próprio site.
Para quem não vale (ainda):
- Quem só tem um site lento — o ganho pode vir primeiro de hosting e cache, sem tocar no construtor.
- Quem tem um e-commerce complexo que funciona: o risco de uma troca apressada supera o benefício.
- Quem tem um time produtivo no Elementor e um site pequeno: adie até haver um motivo concreto.
Migrar é um investimento com retorno em performance, fim do lock-in e manutenção mais barata. Como todo investimento, só faz sentido quando há retorno à vista.
O que realmente acontece quando você migra
Aqui está a parte que os anúncios não contam. Migrar do Elementor para o Gutenberg não é apertar um botão — é reconstruir.
Não existe conversor de 1 clique confiável — é rebuild
Você vai encontrar plugins prometendo “converter Elementor para Gutenberg automaticamente”. Trate com ceticismo. Não há um conversor de 1 clique confiável, e o motivo é técnico: o que esses plugins costumam fazer é despejar o HTML renderizado dentro de um único bloco genérico. Você troca o lock-in do Elementor por uma página que não é editável em blocos nativos — o pior dos dois mundos.
Migração de verdade costuma ser reconstrução, não conversão automática. Você reconstrói cada página usando blocos nativos, aproveitando o conteúdo (textos, imagens, links) que já existe. É trabalho manual e cuidadoso, e é por isso que tem custo.
Ao desativar o Elementor, shortcodes e HTML cru viram texto
Este é o ponto que pega muita gente de surpresa. O Elementor não grava o layout em HTML limpo no post — ele guarda os dados num formato proprietário e renderiza o layout em tempo real. Quando você desativa o plugin, esse motor de renderização some.
O resultado: páginas que voltam a mostrar shortcodes órfãos (do tipo [elementor-template id="123"]) ou um bloco de HTML cru misturado ao conteúdo. Não é que o texto se perdeu — é que a estrutura visual dependia inteiramente do construtor estar ativo. Por isso jamais se desativa o Elementor antes de reconstruir. Primeiro o rebuild, depois a desativação.
Conteúdo em formato proprietário vs. block markup
Vale entender a diferença por baixo do capô, porque é ela que explica o custo:
- Elementor: o layout vive num formato proprietário, salvo em campos do banco de dados (
postmeta). O HTML só existe quando o plugin renderiza. - Gutenberg: o layout vive como block markup — HTML padrão anotado com comentários no próprio conteúdo do post (
<!-- wp:paragraph -->). É legível, portável e não depende de plugin nenhum para existir.
<!-- wp:paragraph -->
<p>Este parágrafo é block markup nativo: HTML puro no post.</p>
<!-- /wp:paragraph -->Essa diferença é o coração do argumento contra o lock-in: no Gutenberg, seu conteúdo é seu, em formato aberto. No Elementor, seu layout é refém do plugin continuar instalado e licenciado.
O caminho seguro: staging → rebuild em blocos → backup → testar → desativar → limpar shortcodes
A migração segura tem uma ordem que não se inverte:
- Staging. Clone o site para um ambiente de testes. Nada de migrar em produção.
- Rebuild em blocos. Reconstrua cada página em Gutenberg, página por página, aproveitando textos e mídia existentes.
- Backup. Antes de qualquer desativação, backup completo de arquivos e banco.
- Testar. Compare cada página nova com a original: layout, links, headings, formulários, responsivo.
- Desativar o Elementor. Só depois de tudo reconstruído e testado.
- Limpar shortcodes. Varra o banco em busca de shortcodes órfãos e HTML residual que o construtor deixou para trás.
Pular etapas é como se pula a corda no escuro — cedo ou tarde você tropeça em produção.
Quanto custa de verdade — TCO em 3 anos
Migração assusta pelo custo de entrada. Mas a conta honesta é o TCO (custo total de propriedade), não o preço de um dia. Aqui não vale cravar número fechado — os valores variam por país, agência e complexidade — então trate tudo abaixo como estimativa para você fazer a sua conta.
A licença recorrente do Elementor Pro
O Elementor Pro é uma licença recorrente: você paga todo ano, para sempre, enquanto quiser os recursos Pro e as atualizações. Parar de pagar significa perder atualizações e suporte — e, em recursos que dependem do Pro, degradação com o tempo. É um custo que nunca termina.
O custo único da migração
O rebuild em Gutenberg é um custo único. Como estimativa de trabalho, algo entre 4 e 12 horas por página, conforme a complexidade — uma página institucional simples fica na base, uma landing page cheia de seções dinâmicas e formulários fica no topo (ou acima). Multiplique pelo número de páginas reais, lembrando que templates repetidos e blocos reutilizáveis reduzem muito o total.
A conta de 3 anos
A comparação honesta coloca as duas naturezas de custo lado a lado:
- Continuar no Elementor: licença recorrente ano 1 + ano 2 + ano 3, indefinidamente, sem fim à vista.
- Migrar para o Gutenberg: custo único do rebuild no ano 1, e depois zero de licença — só a manutenção normal, que tende a ficar mais barata por haver menos código e menos plugins.
Em muitos cenários, o custo único da migração se paga dentro do horizonte de 3 anos, e a partir daí o Gutenberg fica no positivo. Não é uma regra universal — sites pequenos com poucas páginas demoram mais a fechar a conta — mas é por isso que enquadramos a migração como investimento, não como despesa.
Blocos customizados como ativo do cliente
Há um valor que não aparece na planilha de licença: os blocos customizados que se pode construir no Gutenberg. Quando a Pixelize cria um bloco sob medida para o seu negócio — um card de serviço, um bloco de depoimento, uma seção de preços — ele vira um ativo seu, em código aberto, que você controla. Não é um recurso alugado de um construtor; é parte do seu site, para sempre, sem licença. Com o tempo, esse conjunto de blocos vira uma biblioteca própria, que acelera páginas futuras.
Migrar ou não? Árvore de decisão
Se você quer uma resposta rápida para o seu caso, siga o galho:
- Meu site só está lento → trate hosting e cache primeiro (um bom cache como o WP Rocket, CDN e hospedagem decente). Se a lentidão era isso, você economizou uma migração. Se persistir, aí sim avalie o construtor.
- Tenho um e-commerce complexo que funciona → não agora. Risco alto, retorno baixo. Migre páginas de conteúdo primeiro, deixe o transacional para um projeto dedicado.
- Quero fim do lock-in e site leve → migre, de forma planejada. É o cenário em que a migração mais compensa.
- Vou fazer um redesign de qualquer forma → migre junto. O momento mais barato para trocar de motor é quando você já ia reconstruir por cima.
- Tenho um time produtivo no Elementor e um site pequeno → adie. Sem um motivo concreto (performance, custo, redesign), a troca é esforço sem retorno claro.
Ganhos reais da migração (com ressalvas honestas)
Prometer milagre é desonesto. Mas há ganhos consistentes e defensáveis quando a migração é bem feita:
- Core Web Vitals melhores. Menos JS e CSS carregados por página tende a melhorar o LCP e a resposta à interação. O efeito é real, mas depende de também cuidar de imagens, cache e hosting.
- DOM menor. O Elementor aninha muitas
divpara montar o layout. O Gutenberg gera markup mais enxuto, o que ajuda o navegador a renderizar mais rápido. - Menos código do construtor. Você deixa de carregar o pacote de JS/CSS que o Elementor injeta em toda página, inclusive onde não é usado.
- Menos plugins = menor superfície de ataque. Sair do ecossistema de add-ons do construtor costuma reduzir o número de plugins. Menos plugins significam menos pontos de falha e uma superfície de ataque menor — o que conversa direto com os erros comuns do WordPress que nascem de excesso de plugins.
Nenhum desses ganhos é automático. São a tendência quando o rebuild é feito com cuidado — não uma garantia que vem só de trocar o editor.
Quando NÃO migrar (ainda)
Ser honesto inclui dizer quando ficar parado é a decisão certa:
- Quando o problema real é performance de infraestrutura. Se o site está lento por hospedagem ruim ou falta de cache, migrar não resolve. Conserte a base primeiro.
- Quando o e-commerce está estável e testado. Fluxos de checkout que funcionam não se mexe sem um motivo forte e um plano de risco.
- Quando não há orçamento para fazer direito. Uma migração pela metade — que quebra layouts ou deixa shortcodes órfãos — é pior do que não migrar. Melhor esperar do que fazer mal.
- Quando o site é pequeno e o time domina o Elementor. Se está tudo funcionando e ninguém sente dor, a migração é uma solução sem problema.
A regra: migre por um motivo (custo, performance, fim do lock-in, redesign), nunca por moda.
Como a Pixelize faz essa migração
A gente não migra no improviso. O processo é o caminho seguro descrito acima, com método:
- Auditoria. Mapeamos quantas páginas usam Elementor, o que se repete e o que pode virar bloco reutilizável — para dimensionar o esforço real, sem surpresa.
- Staging. Toda a reconstrução acontece num clone, longe do site no ar.
- Rebuild em blocos nativos, com blocos customizados onde faz sentido — que ficam como ativo seu, sem licença.
- Backup, testes e checklist de SEO antes de qualquer publicação: URLs, headings, alt text, redirecionamentos e responsivo.
- Desativação e limpeza do Elementor e dos shortcodes órfãos, só quando tudo já está validado.
Se você quer avaliar se a migração compensa no seu caso — com uma estimativa honesta de horas e TCO —, veja nosso serviço de WordPress ou fale sobre um plano contínuo em manutenção WordPress. A conversa começa por entender se migrar é o certo agora — e, se não for, a gente diz.