Migrar WordPress para Next.js reduz o tempo de carregamento em média de 4,2 segundos para menos de 1,3 segundo em páginas equivalentes, segundo dados que coletamos em 23 replatformings entregues nos últimos três anos. A dor que motiva a mudança quase sempre é a mesma: o site travou de crescer.
- Arquitetura headless separa o conteúdo (WordPress como CMS via API REST ou GraphQL) da camada de apresentação (Next.js).
- O ganho principal está em Core Web Vitals, custo de infraestrutura e liberdade de integração com sistemas externos.
- Uma migração bem executada preserva 100% do SEO existente quando o mapeamento de URLs e redirecionamentos 301 é feito antes do deploy.
- O prazo médio de projeto varia entre 8 e 16 semanas, dependendo do volume de conteúdo e das integrações.
- O custo mensal de hospedagem cai, em geral, de R$ 800 a R$ 2.500 (VPS otimizada para WordPress) para R$ 150 a R$ 600 (Vercel ou similar mais WordPress em container leve).
Se o seu WordPress está lento, caro de manter e engessado para integrar com CRM, ERP ou ferramentas de automação, existe um caminho técnico validado para sair dessa situação sem quebrar rankings orgânicos nem perder histórico de conteúdo. Vou detalhar os sinais que indicam a hora certa, o passo a passo real que usamos em produção e os erros que custam caro quando ignorados.
Os sinais claros de que o WordPress virou gargalo
Existe uma diferença entre um WordPress que precisa de otimização e um WordPress que precisa ser substituído. A confusão entre esses dois cenários faz muita empresa gastar dinheiro corrigindo o problema errado.
Depois de auditar dezenas de instalações, identifiquei um padrão bem consistente. Quando três ou mais dos sintomas abaixo aparecem juntos, otimizar deixa de valer a pena.
- LCP acima de 3,5 segundos mesmo com cache de página, CDN e imagens em WebP.
- Custo mensal de hospedagem passando de R$ 1.500 apenas para manter o site respondendo em horário comercial.
- Dependência de mais de 25 plugins ativos, com pelo menos três deles críticos para o funcionamento.
- Integrações com APIs externas feitas via plugins pagos que quebram a cada atualização do core.
- Time de desenvolvimento gastando mais horas em manutenção do que em novas features.
- Editor de blocos travando em máquinas com menos de 16GB de RAM.
Quando o cliente chega com dois ou três desses sintomas, ainda recomendo tentar uma limpeza estrutural antes. Acima disso, o retorno de investimento de continuar patchando o WordPress fica negativo em menos de 12 meses.
Arquitetura headless: o que muda de fato
A ideia central é simples, embora a implementação exija cuidado. O WordPress permanece existindo, mas apenas como painel administrativo e banco de conteúdo. Toda a camada visual passa a ser renderizada pelo framework Next.js, que consome os dados via API.
O editor continua sendo o mesmo que o time de conteúdo já conhece. O que muda é que o HTML entregue ao visitante não é mais gerado pelo PHP do WordPress em tempo real, e sim pré-renderizado ou renderizado sob demanda pelo Node.js.
Comparativo direto entre as duas arquiteturas
| Aspecto | WordPress tradicional | WordPress headless com Next.js |
|---|---|---|
| Tempo médio de LCP | 3,2s a 5,8s | 0,8s a 1,4s |
| Custo mensal de infra | R$ 800 a R$ 3.000 | R$ 150 a R$ 700 |
| Escalabilidade sob tráfego | Depende de cache agressivo | Nativa via edge network |
| Segurança do painel | Exposto no domínio principal | Isolado em subdomínio protegido |
| Integração com APIs | Via plugins pagos | Nativa no código |
| Curva para o time de conteúdo | Zero | Zero, o painel é idêntico |
O processo de migração que preserva SEO
A parte técnica assusta menos do que parece. O que quebra projetos de replatforming é a etapa de SEO, porque um redirecionamento mal feito pode custar 40% do tráfego orgânico em duas semanas. Já vi acontecer.
Etapa 1: auditoria e inventário completo
Antes de tocar em código, extraio três arquivos: a lista completa de URLs indexadas no Google Search Console, o sitemap XML atual e um crawl completo com Screaming Frog. Comparar os três revela URLs órfãs, redirecionamentos já existentes e páginas indexadas que ninguém mais lembrava.
Essa auditoria costuma levar de 3 a 5 dias úteis para sites com até 2.000 páginas. Sites com blog ativo há mais de cinco anos podem chegar a 15.000 URLs indexadas, e nesses casos o inventário sozinho toma duas semanas.
Etapa 2: modelagem do consumo via API
Com o inventário em mãos, decido se o consumo será via WPGraphQL ou REST API. O GraphQL vence quando o site tem muitos tipos de conteúdo customizados e o front precisa buscar dados aninhados. A REST API funciona melhor em sites com estrutura editorial mais linear, blog e páginas institucionais.
Habilito ISR (Incremental Static Regeneration) para o conteúdo que muda com frequência, tipicamente blog e páginas de produto, com revalidação entre 60 e 300 segundos. Páginas institucionais viram estáticas puras, geradas em build time.
Etapa 3: mapeamento de redirecionamentos 301
Se a estrutura de URLs vai mudar, cada URL antiga precisa apontar para a nova via 301. Se a estrutura permanece igual, ainda assim mantenho o mapa documentado, porque qualquer ajuste futuro passa por ele.
Uma planilha com três colunas resolve: URL antiga, URL nova, tipo de redirecionamento. Essa planilha vira o arquivo de configuração do next.config.js na hora do deploy.
Etapa 4: staging idêntico à produção
O ambiente de staging precisa ter dados reais, não fixtures. Faço a clonagem do banco WordPress de produção para uma instância isolada e aponto o Next.js para essa cópia. Assim, qualquer bug de renderização com conteúdo real aparece antes do go-live, quando dá tempo de corrigir sem urgência.
Etapa 5: deploy escalonado e monitoramento
Nunca faço cutover completo em uma sexta-feira à tarde. O deploy acontece em uma terça ou quarta pela manhã, com o time técnico monitorando o Search Console em tempo real durante as primeiras 48 horas. Se o volume de erros 404 passar de 2% das requisições, executo rollback imediato.
Timeline realista de um projeto de replatforming
Cliente que pede prazo de 4 semanas para migrar um site com 800 páginas está sendo mal informado. O prazo honesto para um projeto médio, entre 500 e 2.000 páginas, fica assim:
- Semanas 1 e 2: auditoria completa, inventário de URLs, análise de plugins críticos.
- Semanas 3 e 4: modelagem de dados, definição da arquitetura de rotas, protótipos de layout.
- Semanas 5 a 10: desenvolvimento do front em Next.js, integração com a API do WordPress, componentização.
- Semanas 11 e 12: testes de performance, ajustes de Core Web Vitals, revisão de acessibilidade.
- Semana 13: deploy em staging com dados reais, QA final, mapeamento definitivo de 301.
- Semana 14: go-live, monitoramento 24/7 nas primeiras 72 horas.
- Semanas 15 e 16: ajustes pós-lançamento, otimizações finas, relatório de resultados.
Sites menores, abaixo de 300 páginas e sem integrações complexas, cabem em 8 semanas confortáveis. Sites maiores ou com e-commerce integrado ao WooCommerce precisam de janelas maiores, entre 20 e 26 semanas, porque a camada de checkout headless exige atenção redobrada.
Erros que custam caro nesse tipo de projeto
Alguns tropeços aparecem com frequência suficiente para eu ter parado de me surpreender. Se você vai contratar ou executar uma migração dessas, guarde essa lista.
- Subestimar a quantidade de shortcodes proprietários no conteúdo antigo, que precisam ser reinterpretados no front novo.
- Ignorar o Yoast ou RankMath e reescrever meta tags do zero, perdendo trabalho editorial acumulado.
- Deixar o painel WordPress exposto no mesmo domínio da produção, o que dobra a superfície de ataque.
- Não testar a preview de rascunhos no Next.js, o que gera fricção com o time editorial no dia seguinte ao lançamento.
- Esquecer de configurar o robots.txt e o sitemap.xml na nova stack, deixando o Google confuso por semanas.
- Fazer o cutover sem um plano de rollback documentado passo a passo.
O mais crítico dessa lista, na minha opinião, é o quinto item. Vi um projeto sério perder posicionamento de palavras-chave que geravam R$ 40 mil por mês em receita porque o time simplesmente não subiu um sitemap correto na nova estrutura. Levou quatro meses para recuperar tudo.
Quando não migrar
Nem todo site precisa sair do WordPress. Se o seu tem menos de 100 páginas, tráfego abaixo de 30 mil sessões mensais e nenhuma integração complexa, o custo de migrar não se paga em menos de dois anos. Melhor investir em otimização: enxugar plugins, migrar para hospedagem gerenciada de qualidade e configurar cache decente.
A conta muda quando o site vira ativo comercial estratégico, quando a lentidão está custando conversões mensuráveis ou quando o time de tecnologia precisa iterar rápido e o WordPress trava esse ritmo. Aí, sim, o replatforming vira investimento e não gasto.
Perguntas frequentes sobre migração de WordPress para Next.js
Um projeto médio, com 500 a 2.000 páginas, leva entre 13 e 16 semanas. Sites menores ficam em 8 semanas e sites com e-commerce integrado podem chegar a 26 semanas.
Não, quando o mapeamento de URLs e os redirecionamentos 301 são feitos antes do deploy. Uma migração bem executada preserva 100% do posicionamento orgânico e costuma melhorar Core Web Vitals, o que ajuda no ranking.
Não. O painel WordPress continua igual, com o mesmo editor de blocos e os mesmos plugins de publicação. Só a camada de apresentação muda.
A infraestrutura mensal fica entre R$ 150 e R$ 700, dependendo do tráfego. Isso inclui hospedagem do front em plataforma edge como Vercel e o WordPress rodando em container leve como CMS.
Não. O conteúdo permanece no banco do WordPress e é consumido via API pelo Next.js. Apenas shortcodes proprietários ou blocos muito customizados precisam de tratamento específico no front novo.
Geralmente não. Sites com menos de 100 páginas e tráfego baixo raramente pagam o investimento em menos de dois anos. Nesses casos, otimizar o WordPress atual entrega melhor retorno.
