Guia: migrar páginas do Elementor para blocos nativos e melhorar o INP

Um guia para migrar páginas do Elementor para blocos nativos e melhorar o INP consiste em reconstruir cada página no editor de blocos do WordPress (Gutenberg), sem o Elementor, para reduzir JavaScript, CSS e elementos no DOM. Não existe conversão automática confiável para layouts complexos, e o ganho de INP depende também de plugins e scripts de terceiros. Para migrar com segurança, siga estes passos:

1. Meça o INP atual com dados de campo e registre as páginas com pior resultado.
2. Crie um ambiente de staging com cópia completa do site e faça backup.
3. Inventarie as páginas e os widgets do Elementor usados em cada uma.
4. Reconstrua cada página com blocos nativos (Grupo, Colunas, Título, Imagem, Botões), reaproveitando textos e mídia.
5. Compare visualmente, teste as interações e meça o INP novamente.
6. Publique página por página e só então desative o Elementor.

Pré-requisitos

• Acesso de administrador ao WordPress e acesso SSH ou ao gerenciador de arquivos da hospedagem.
• Um ambiente de staging (cópia do site) e um backup completo de arquivos e banco de dados.
• WordPress em versão atual e PHP 8.4 ou superior, conforme o artigo Como otimizar PHP no WordPress: versão, módulos e php.ini.
• Acesso ao Google Search Console e ao PageSpeed Insights para medir o INP.
• Navegador Chrome com DevTools para análise em laboratório.
• Lista de plugins que dependem do Elementor (complementos de widgets, formulários, popups).

Por que o INP piora com construtores de páginas

O INP (Interaction to Next Paint) mede o tempo entre uma interação do usuário, como clique, toque ou tecla, e a próxima atualização visual da tela. Ele considera as interações da visita e reflete a mais lenta, com exceção de casos extremos. Quanto mais trabalho a thread principal do navegador tem para fazer, maior tende a ser esse tempo.

Construtores visuais costumam gerar muitos elementos aninhados no DOM, folhas de CSS extensas e scripts para animações, abas, carrosséis e menus. Um DOM grande torna mais caro o recálculo de estilos e o layout após cada interação. Os blocos nativos produzem marcação mais enxuta e, na maioria dos casos, não carregam JavaScript próprio para elementos estáticos como títulos, parágrafos, imagens e colunas.

Isso não significa que migrar resolva tudo. Plugins de chat, pixels de marketing, anúncios e scripts de terceiros também ocupam a thread principal. Por isso, a migração deve ser tratada como uma das alavancas, e o resultado precisa ser medido. Se você ainda quer reduzir o peso do Elementor enquanto a migração não termina, veja Melhorar Core Vitals no WordPress Elementor desativando scripts.

Medir o INP antes de migrar

A linha de base de desempenho define se a migração valeu o esforço. Sem ela, qualquer comparação posterior vira opinião.

1. No Search Console, abra o relatório de Core Web Vitals e anote os grupos de URLs com INP classificado como "precisa melhorar" ou "ruim".
2. No PageSpeed Insights, teste as URLs principais e registre o INP da seção de dados de campo. Se a URL não tiver dados suficientes no CrUX, o PSI exibe os dados agregados da origem (domínio inteiro); confira o rótulo — "Esta URL" ou "Origem" — antes de registrar o valor na planilha.
3. No Chrome DevTools, abra o painel Desempenho, grave uma sessão clicando em menus, botões e acordeões, e identifique tarefas longas após as interações.
4. Guarde as capturas e os valores em uma planilha, com data e URL.

Dados de campo vêm de usuários reais e levam um tempo para refletir mudanças. Os dados de laboratório mostram o efeito na hora, mas dependem do seu dispositivo e da sua rede. Use os dois com propósitos diferentes: campo para confirmar, laboratório para investigar.

Preparar o staging e o backup

Um ambiente de staging evita que visitantes vejam páginas pela metade durante a reconstrução. A maioria das hospedagens oferece clonagem em um clique. Se a sua não oferece, crie um subdomínio e copie arquivos e banco de dados; o processo é parecido com o descrito em Migrar WordPress entre hospedagens sem downtime.

Ao criar o staging em subdomínio, proteja o ambiente com autenticação HTTP (senha no nível do servidor ou da hospedagem) ou restrição por IP — a opção "Desencorajar mecanismos de busca" em Configurações > Leitura insere apenas um noindex e não impede acesso externo. Desative também e-mails transacionais, integrações de pagamento, webhooks e qualquer tarefa agendada que possa causar efeitos em produção. Quando o banco contiver dados pessoais, use uma cópia sanitizada.

Se você tem acesso SSH e o WP-CLI instalado, confirme que o mysqldump ou o mariadb-dump está disponível e exporte o banco diretamente para um diretório fora do document root, com permissões restritas:

command -v mysqldump || command -v mariadb-dump
umask 077; wp db export /caminho/privado/backup-pre-migracao.sql

Confirme que o arquivo foi criado e guarde uma cópia fora do servidor:

ls -lh /caminho/privado/backup-pre-migracao.sql

Após transferir e validar o backup, remova com segurança qualquer cópia deixada no servidor. Nunca exporte o dump dentro do document root: em servidores que sirvam arquivos .sql, o banco pode ser baixado pela web e contém senhas, tokens e dados pessoais.

Atenção: não trabalhe direto em produção.

Inventariar páginas e widgets do Elementor

O inventário de conteúdo mostra o tamanho real do trabalho e permite priorizar. Comece pelas páginas com mais tráfego e pior INP, como a página inicial, páginas de serviço e páginas de captura.

Com o WP-CLI, liste as páginas publicadas:

wp post list --post_type=page --post_status=publish --fields=ID,post_title,post_name

Para saber quais páginas usam o Elementor, verifique os metadados _elementor_edit_mode e _elementor_data. Use uma consulta que trate ausência de metadado de forma explícita:

wp post meta list 123 --keys=_elementor_edit_mode --format=json

Uma lista vazia indica que o metadado não está presente. Troque 123 pelo ID da página. Lembre-se de inventariar também os tipos de post do Elementor Library (elementor_library), que inclui cabeçalhos, rodapés, popups, arquivos e modelos de conteúdo construídos com o Theme Builder ou com o Elementor Pro — eles usam tipos de post próprios e podem não aparecer na listagem de páginas comum.

Para cada página, monte uma tabela com estas colunas: URL, ID, tráfego aproximado, widgets usados, plugins complementares envolvidos e status. Preste atenção em recursos que não têm equivalente direto nos blocos nativos:

• Formulários: exigem um plugin de formulários próprio ou um bloco de formulário de outro plugin.
• Popups e modais: precisam de alternativa específica.
• Animações de entrada e efeitos de rolagem: podem ser descartados, o que também ajuda o INP.
• Cabeçalho e rodapé: se foram feitos com o Theme Builder do Elementor, migre-os para o tema.
• Modelos dinâmicos: use o bloco Query Loop para listar posts; para exibir valores de campos personalizados, use Block Bindings com o metadado registrado e exposto corretamente, um bloco dinâmico compatível, um plugin específico ou implementação no tema — o Query Loop por si só não renderiza campos arbitrários.

Escolher o tema e os blocos equivalentes

Blocos nativos funcionam em temas clássicos, mas um tema de blocos (block theme) com o editor de site permite controlar cabeçalho, rodapé e estilos globais sem builders. Escolha um tema leve e teste a compatibilidade em staging antes de trocar. Se você usa tema filho com customizações, revise o artigo WordPress: como migrar tema filho sem perder estilos — direto no código.

Use esta correspondência como ponto de partida:

• Seção e Contêiner do Elementor: bloco Grupo, ou Linha/Pilha (variações do Grupo).
• Colunas: bloco Colunas.
• Título e Editor de texto: blocos Título e Parágrafo.
• Imagem: bloco Imagem, ou Capa (Cover) quando houver texto sobre a imagem.
• Botão: bloco Botões.
• Lista de ícones: bloco Lista.
• Acordeão e abas: bloco Detalhes (para acordeão simples); abas exigem plugin ou alternativa.
• Vídeo: bloco Vídeo ou Incorporar.
• Espaçador e divisor: blocos Espaçador e Separador.

Reconstruir uma página com blocos nativos

A reconstrução manual é o caminho mais seguro, pois não existe conversor automático confiável para layouts complexos. O fluxo abaixo funciona bem para cada página.

1. Abra a página original em uma aba e, em outra, crie uma nova página (rascunho) no staging com o título "Nome da página (blocos)".
2. Copie os textos e baixe ou reaproveite as imagens da Biblioteca de Mídia, sem reenviar arquivos duplicados.
3. Monte a estrutura externa com blocos Grupo, definindo largura (conteúdo ou ampla) e espaçamentos nas configurações do bloco.
4. Dentro de cada Grupo, insira Colunas, Títulos, Parágrafos, Imagens e Botões na mesma ordem da página original.
5. Use o Editor de Visualização de Lista (List View) para conferir o aninhamento e evitar Grupos desnecessários.
6. Defina cores, fontes e espaçamentos pelos estilos globais do tema, não bloco a bloco. Isso mantém o CSS enxuto.
7. Use as visualizações de tablet e celular do editor para conferir o resultado visual. Essas visualizações são apenas pré-visualizações; o comportamento responsivo real depende da opção "Empilhar em celulares" do bloco Colunas, de tipografia e espaçamento fluidos definidos no theme.json do tema ou de CSS adicional.

Evite recriar o mesmo efeito visual a qualquer custo. Efeitos que exigem muito aninhamento ou JavaScript geralmente são os que mais pesam na interação. Simplificar o design é parte do ganho.

Preservar URL, SEO e mídia

Ao trocar o conteúdo, a URL da página deve permanecer a mesma para não perder posicionamento. Há duas estratégias seguras:

• Substituir o conteúdo na própria página: a opção mais segura para preservar ID, URL, menus e relacionamentos. A página original perde o layout do Elementor assim que você salvar. Use em staging e depois leve a alteração para produção.
• Criar uma página nova e trocar o slug: o WordPress não permite duas páginas com o mesmo slug, mesmo que a original esteja em rascunho — o slug continua reservado. Antes de publicar a página nova, altere o slug da página original (por exemplo, acrescentando -antiga) ou mova-a para a lixeira; só então defina o slug original na nova página e confirme no navegador que a URL final é idêntica à anterior. Atualize também menus e qualquer referência baseada no ID da página antiga.

Confira também título SEO, meta descrição, imagem de destaque, dados estruturados e tags canônicas do plugin de SEO que você usa. Esses campos ficam no plugin, não no Elementor, mas vale revisar. Verifique ainda se links internos e âncoras continuam funcionando.

Remover o Elementor e limpar o que sobrou

Só desative o plugin depois que todas as páginas estiverem reconstruídas, validadas e publicadas. Enquanto houver páginas ainda feitas com o Elementor, desativá-lo quebra o layout ou exibe conteúdo incompleto.

Quando a última página estiver pronta, siga esta ordem em staging:

1. Inventarie todos os tipos de post habilitados para o Elementor, incluindo elementor_library (cabeçalhos, rodapés, popups, modelos). Verifique os metadados _elementor_edit_mode e _elementor_data e valide o uso real antes de prosseguir.
2. Desative primeiro os complementos e o Elementor Pro (extensões de popup, pacotes de widgets e demais dependentes); enquanto estiverem ativos, podem causar erros ao remover a dependência principal.
3. Desative o plugin Elementor principal e navegue pelo site inteiro, incluindo cabeçalho, rodapé, arquivos, busca e páginas 404.
4. Se tudo estiver certo, exclua os complementos e depois o plugin Elementor.

Atenção: tenha o backup validado antes de excluir. Dados antigos do Elementor podem permanecer no banco de dados como metadados. Só remova esses registros depois de um período de observação e com novo backup, de preferência com orientação de quem administra o banco.

Validar o INP depois da migração

Com o novo layout em staging, repita o teste do painel Desempenho do Chrome DevTools, executando as mesmas interações da linha de base. Compare o número e a duração das tarefas longas após cada clique.

Em produção, acompanhe o relatório de Core Web Vitals do Search Console. Como ele usa dados de campo, a atualização leva algum tempo. Compare com a planilha registrada antes de começar e avalie por grupo de URLs.

Se o INP não melhorar como esperado, o gargalo provavelmente está fora do construtor. Investigue:

• Scripts de terceiros (chat, pixels, mapas, vídeos incorporados).
• Plugins que carregam JavaScript em todas as páginas.
• Menus e filtros com muito processamento no clique.
• Resposta lenta do servidor, que afeta outras métricas e a experiência geral. Em casos de origem lenta, veja Site lento no PageSpeed: quando migrar para Cloudflare no WordPress.

Problemas comuns e como resolver

Sintoma: a página reconstruída fica diferente da original no celular

Causa: espaçamentos, colunas e tamanhos de fonte foram definidos apenas na visualização de desktop, e o empilhamento das colunas não segue o mesmo comportamento do Elementor.
Solução: use as visualizações de tablet e celular do editor para conferir o resultado, revise o espaçamento dos Grupos e ative a opção "Empilhar em celulares" no bloco Colunas. Para ajustes mais finos de tipografia e espaçamento responsivo, edite o theme.json do tema ou adicione CSS. Compare com capturas da página original em staging.

Sintoma: a página antiga quebrou ao desativar o Elementor

Causa: ainda havia páginas, modelos de cabeçalho/rodapé, popups ou documentos do elementor_library construídos com o Elementor.
Solução: reative o plugin, rode novamente o inventário e verifique os metadados _elementor_edit_mode e _elementor_data nas páginas restantes e também nos modelos do Elementor Library. Só desative de novo quando tudo estiver migrado.

Sintoma: o INP não melhorou depois da migração

Causa: o problema principal está em scripts de terceiros, plugins pesados ou interações específicas, e não no construtor de páginas. Também é possível que os dados de campo ainda não reflitam a mudança.
Solução: grave o painel Desempenho no DevTools, identifique as tarefas longas após as interações e atribua cada uma a um script. Adie ou remova o que não é essencial e aguarde a atualização dos dados de campo antes de concluir.

Sintoma: formulário ou popup deixou de funcionar

Causa: esses recursos eram widgets do Elementor Pro ou de complementos, sem equivalente nos blocos nativos.
Solução: instale um plugin de formulários que ofereça bloco próprio e recrie os campos, as notificações por e-mail e as integrações. Teste o envio em staging antes de publicar.

Sintoma: perda de posicionamento ou URL alterada

Causa: o slug da página nova ficou diferente porque a página original em rascunho ainda o reservava, ou campos do plugin de SEO não foram revisados.
Solução: altere o slug da página original para um valor de backup (ou mova-a para a lixeira), atribua o slug correto à página nova e confirme a URL no navegador. Revise título, meta descrição e canonical e, se alguma URL mudou, configure um redirecionamento 301 da antiga para a nova.

Perguntas frequentes

Migrar do Elementor para blocos nativos melhora o INP?

Tende a melhorar, porque os blocos nativos geram menos JavaScript, CSS e elementos no DOM do que os widgets do Elementor. O ganho real depende do restante da página, como plugins, scripts de terceiros e anúncios. Meça antes e depois com dados de campo e teste página por página.

Existe conversor automático de Elementor para blocos do Gutenberg?

Não há conversão automática confiável que preserve o layout de páginas complexas. O caminho mais seguro é reconstruir cada página com blocos nativos (Grupo, Colunas, Título, Imagem, Botões), reaproveitando textos e mídia. Faça isso em staging e compare visualmente com a versão original.

Posso desativar o Elementor antes de terminar a migração?

Não. Páginas ainda construídas com Elementor perdem o layout ou exibem conteúdo quebrado quando o plugin é desativado. Mantenha o plugin ativo até que todas as páginas tenham sido reconstruídas, validadas e publicadas, e só então desative e remova.

Como medir o INP antes e depois da migração?

Use o relatório de Core Web Vitals do Search Console e o PageSpeed Insights para dados de campo, e o painel Desempenho do Chrome DevTools para investigar interações lentas em laboratório. Registre os valores antes da migração para comparar depois. Dados de campo levam algum tempo para refletir a mudança.

Preciso de um tema de blocos para usar blocos nativos?

Não é obrigatório, pois blocos nativos funcionam em temas clássicos. Porém, um tema de blocos (block theme) com o editor de site permite controlar cabeçalho, rodapé e estilos globais sem builders. Escolha um tema leve e confirme a compatibilidade em staging antes de trocar.

Conclusão

• Registre o INP atual em dados de campo e laboratório antes de mexer em qualquer página.
• Reconstrua as páginas em staging, começando pelas de maior tráfego, mantendo URLs e campos de SEO.
• Desative o Elementor somente quando todas as páginas estiverem publicadas e validadas, e depois acompanhe o INP no Search Console.

Leia também

• Melhorar Core Vitals no WordPress Elementor desativando scripts
• Solucionar lentidão no WordPress: causas reais e correções
• passo a passo: desativar WP-Cron sem quebrar WordPress

Precisa de ajuda com migração do Elementor?

Uma hospedagem com PHP atualizado e ambiente de staging facilita testar a reconstrução das páginas antes de publicar. Conheça as opções de hospedagem para WordPress da AviraHost.

Ver hospedagem para WordPress