Migrei meu 47º site WordPress na semana passada. A regra de decisão que nunca me falhou: se você gasta mais tempo lutando contra WordPress do que construindo recursos, saia.

Eu sei que isso soa reducionista. Mas depois de anos construindo no WordPress — e anos tirando projetos dele — reduzi a pergunta "devo ficar ou devo ir" em algo mais estruturado. Um framework de cinco perguntas que te dá uma resposta honesta e quantificável. Sem vibrações. Sem lealdade tribal a PHP ou React. Apenas um checklist que mapeia pontos de dor reais.

Deixe-me guiá-lo por isso, então converteremos sobre para onde ir, o que custa, e os erros que vão arruinar sua migração se não tiver cuidado.

Índice

O Framework de 5 Perguntas: Você Deveria Deixar WordPress?

Usei esse framework com clientes, com meus próprios projetos, e com times de dev avaliando sua stack. Cinco perguntas sim-ou-não. Cada uma visa uma categoria específica de dor do WordPress — bloat de plugins, custo, segurança, performance e velocidade.

1. Você Tem Mais de 20 Plugins Ativos?

Vinte é o número. Não porque há algo mágico nele, mas porque esse é o limite onde WordPress para de ser um CMS e vira um monstro de Frankenstein mantido junto por add_filter hooks e rezas.

Cada plugin é uma dependência que você não controla. Cada atualização de plugin é uma mudança potencialmente quebradora. E em 2026, o ecossistema de plugins WordPress tem um problema de segurança que é difícil de ignorar: Patchstack reportou mais de 11.300 CVEs de plugins em 2025 sozinho, um aumento de 42% comparado ao ano anterior. Mais plugins significa mais superfície de ataque.

Conte seus plugins ativos agora. Vou esperar.

Se você está em 30+, você está quase certamente rodando plugins que duplicam funcionalidade, conflitam um com o outro, ou existem apenas porque WordPress não faz nativamente algo que frameworks modernos lidam de caixa — coisas como otimização de imagem, caching, tags de SEO, ou manipulação de formulários.

2. Você Está Pagando Mais de $100/Mês por Hosting Gerenciado?

WordPress é software "gratuito" que de alguma forma custa uma fortuna para hospedar bem. Se você está em WP Engine, Kinsta, ou Flywheel, você provavelmente está pagando $30-$115/mês por um único site. Escale para 5-10 sites e você está olhando para $300-$600/mês.

Enquanto isso, um site gerado estaticamente em Vercel ou Netlify? A camada gratuita dá conta da maioria dos sites de marketing. Até um setup headless CMS + Next.js em Vercel Pro é $20/mês. Não é uma comparação maçã-com-maçã (WordPress inclui banco de dados, UI de admin, etc.), mas esse é o ponto — você está pagando por infraestrutura que talvez não precise.

Se sua conta de hosting te faz fazer careta, esse é um sinal.

3. Você Foi Hackeado ou Teve Downtime nos Últimos 12 Meses?

Essa é uma pergunta binária e importa mais do que a maioria dos desenvolvedores admite. WordPress alimenta ~40% da web, o que o torna o maior alvo para ataques automatizados. Tentativas de force-brute de login, SQL injection através de plugins desatualizados, malware injetado via temas nulos — vi tudo isso.

Se você foi hackeado, você conhece o procedimento: Sucuri scan, limpeza de banco de dados, rotações de senha, pânico do cliente. Se você teve downtime porque uma atualização de plugin quebrou seu site às 2 da manhã, você sabe esse sentimento também.

Sites estáticos modernos e apps server-rendered sem painel admin público simplesmente não têm essa superfície de ataque. Não há /wp-admin para fazer force-brute. Não há xmlrpc.php para explorar. O modelo de segurança é fundamentalmente diferente.

4. Seus Core Web Vitals Estão Falhando em Mobile?

Os Core Web Vitals do Google são obrigatoriedade para SEO em 2026. E sites WordPress consistentemente lutam aqui. Uma análise HTTP Archive de 2025 mostrou que aproximadamente 71% das origens WordPress falharam na avaliação de CWV mobile — comparado com taxas de sucesso significativamente melhores para sites construídos em frameworks como Next.js e Astro.

O culpado? CSS que bloqueia renderização de temas e plugins. Imagens não otimizadas servidas sem formatos modernos. Tamanho excessivo de DOM de construtores de página. JavaScript que não era necessário em primeiro lugar. Você pode jogar plugins de caching no problema, mas está tratando sintomas, não causas.

Execute seu site através de PageSpeed Insights. Se seu LCP mobile está acima de 2,5 segundos e seu CLS está falhando, WordPress em si pode ser o gargalo.

5. Seu Time Quer Enviar Recursos Mais Rápido do Que WordPress Permite?

Essa é a pergunta que mais importa para times de engenharia. O modelo de desenvolvimento do WordPress — templates PHP, o loop, hooks e filters, a API de bloco Gutenberg — é um jeito específico de construir. Não é ruim. Mas é lento comparado ao desenvolvimento baseado em componentes com React, Vue, ou Svelte.

Se seu time gasta mais tempo:

  • Lutando com a arquitetura React-mas-não-muito do Block Editor
  • Escrevendo PHP personalizado para contornar limitações de tema
  • Debugando conflitos de plugin após atualizações
  • Esperando invalidação de cache de página inteira

...do que realmente construindo recursos que seus usuários querem, essa é sua resposta.

Frameworks modernos deixam você enviar mais rápido. Isso não é opinião — é física. Arquiteturas baseadas em componentes com hot module reloading, TypeScript, e conteúdo orientado por API vencem o loop de desenvolvimento do WordPress em velocidade de iteração toda vez.

Pontuando Suas Respostas

Aqui está a matriz de decisão. Simples propositalmente:

Respostas Sim Recomendação Justificativa
0-1 Fique no WordPress Seus problemas são gerenciáveis. Otimize o que você tem.
2 Fique, mas planeje Comece a prototipagem de alternativas. Você está se aproximando do ponto de inflexão.
3 Comece a migrar A dor é real e não vai embora. Comece a planejar sua saída.
4-5 Saia agora WordPress está te custando tempo, dinheiro e segurança ativamente. Priorize a migração.

Apliquei isso a provavelmente 60+ projetos até agora. Nunca me deu um falso positivo. Os clientes que tiveram 3+ e ficaram no WordPress? Voltaram 6-12 meses depois, e a migração era mais difícil e mais cara então.

Para Onde Migrar (Mapeado por Caso de Uso)

É aqui onde a maioria dos artigos "deixe WordPress" caem por terra. Eles dizem para usar Next.js para tudo, ou listam 15 opções de CMS sem dizer qual se encaixa na sua situação. Deixe-me ser específico.

Sites de Marketing e Blogs

Stack recomendado: Astro + um CMS headless (Sanity, Storyblok, ou Contentful)

Astro foi basicamente projetado para substituir WordPress para sites de conteúdo. Envia zero JavaScript por padrão, gera HTML estático, e suporta hidratação parcial para componentes interativos. Suas pontuações de Lighthouse vão de "decepcionante" para "perfeita" da noite para o dia.

Construímos muitos desses na Social Animal — nossas capacidades de desenvolvimento Astro estão fortemente orientadas para exatamente esse caminho de migração. Pair Astro com Sanity Studio e seus editores de conteúdo ganham uma experiência de autoria melhor do que WordPress jamais deu.

E-commerce

Stack recomendado: Next.js + Shopify (headless) ou Medusa.js

Se você está rodando WooCommerce, você já conhece a dor. WooCommerce é poderoso mas frágil sob carga, lento sem infraestrutura séria de caching, e caro para customizar. A API Storefront do Shopify com um frontend Next.js te dá funcionalidade de carrinho, checkout, e gerenciamento de inventário sem rodar seu próprio banco de dados.

Para times que querem controle total e auto-hospedagem, Medusa.js madurcheu significativamente em 2026 e vale a pena avaliar.

Aplicações Web (Dashboards, Portais, SaaS)

Stack recomendado: Next.js (App Router) + CMS headless para seções de conteúdo + sua própria API

Se você esteve hackeando WordPress em uma aplicação com custom post types, ACF, e endpoints REST API... pare. WordPress nunca foi feito para ser um framework de aplicação. Next.js com server components, server actions, e middleware te dá uma arquitetura de aplicação real.

Sites Editoriais Ricos em Conteúdo

Stack recomendado: Next.js ou Astro + Sanity ou Strapi

Times editoriais precisam de modelagem de conteúdo estruturada, previsualizações de rascunho, e edição colaborativa. É aqui onde um CMS headless brilha. A colaboração em tempo real do Sanity é anos à frente do editor Gutenberg do WordPress. Strapi te dá uma opção auto-hospedada com um painel de admin limpo.

Caso de Uso Frontend Recomendado CMS Recomendado Hospedagem Custo Mensal Estimado
Site de marketing / blog Astro Sanity ou Contentful Vercel / Netlify $0-$20
E-commerce Next.js Shopify Storefront API Vercel $29-$79 (Shopify) + $20 (Vercel)
Aplicação web Next.js Sanity (para conteúdo) Vercel / AWS $20-$100
Editorial / publicação Next.js ou Astro Sanity ou Strapi Vercel $0-$99

Compare isso com sua conta de hospedagem WordPress atual. Para a maioria dos times, os custos de infraestrutura caem 30-60%.

Timeline e Custo da Migração (Números Reais)

Vou te dar os números que ninguém quer publicar porque têm medo de assustar clientes. Esses se baseiam em migrações reais que fizemos e observamos em 2025-2026.

Site Pequeno (Menos de 50 Páginas, Blog Simples)

  • Timeline: 3-5 semanas
  • Custo: $5.000-$12.000 (agência) / 40-80 horas (in-house)
  • Tarefas principais: Exportação e reestruturação de conteúdo, reconstrução de templates em Astro/Next.js, setup de CMS, mapeamento de redirects, cutover de DNS
  • Parte mais difícil: Extrair conteúdo de shortcodes de page builder. Se seu conteúdo está repleto de [vc_row] ou blobs JSON do Elementor, orçamente tempo extra para limpeza de conteúdo.

Site Médio (50-200 Páginas, Múltiplos Tipos de Conteúdo)

  • Timeline: 6-10 semanas
  • Custo: $15.000-$35.000 (agência) / 120-250 horas (in-house)
  • Tarefas principais: Tudo acima, mais modelagem de conteúdo no CMS headless, desenvolvimento de componentes personalizados, migrações de formulário, rewiring de integração de terceiros (analytics, email marketing, CRM)
  • Parte mais difícil: Reconstruir grupos de campos ACF personalizados e relacionamentos em um novo modelo de conteúdo. É aqui onde a maioria das estimativas de timeline explodem.

Site Grande (200+ Páginas, E-commerce, Funcionalidade Personalizada)

  • Timeline: 12-20 semanas
  • Custo: $40.000-$80.000+ (agência) / 400-800+ horas (in-house)
  • Tarefas principais: Auditoria de conteúdo completa, estratégia de migração em fases, scripts de migração de dados, migração de plataforma de e-commerce, migração de conta de usuário, preservação de SEO (redirects, sitemap, dados estruturados)
  • Parte mais difícil: Não quebrar SEO. Sites grandes acumularam anos de backlinks, páginas indexadas e autoridade de busca. Um mapeamento de redirect errado pode derrubar seu tráfego orgânico por meses.

Esses números podem parecer altos, mas compare-os com o custo total de propriedade de ficar no WordPress pelos próximos 3 anos: hospedagem gerenciada ($100-$300/mês × 36 = $3.600-$10.800), licenças de plugin premium ($500-$2.000/ano × 3 = $1.500-$6.000), resposta a incidente de segurança ($2.000-$10.000 por incidente), e tempo do desenvolvedor gasto em manutenção em vez de recursos.

Se quer conversar especificidades do seu projeto, nossa página de preços explica como abordamos isso, e você sempre pode entrar em contato direto.

Os 3 Erros Que Matam Migrações WordPress

Vi esses erros matarem migrações completamente. Não "causar atrasos" — matarem. Como em, o time desiste e volta para WordPress, tendo desperdiçado meses e dezenas de milhares de dólares.

Erro 1: Migrar Conteúdo Sem Reestruturá-lo

O maior erro é tratar migração como um trabalho de copiar-colar. Você exporta seus posts e páginas WordPress, importa em um novo CMS, e reconstrói os mesmos templates. Isso te dá a mesma arquitetura de conteúdo bagunçada em uma caixa mais brilhante.

O ponto inteiro de migrar é reestruturar. WordPress encoraja um modelo de conteúdo plano: posts, páginas, e custom post types com campos ACF anexados. Um CMS headless deixa você definir modelos de conteúdo adequados com campos tipados, referências e validação.

Gaste o tempo para auditar seu conteúdo antes de escrever uma única linha de código. Quais tipos de conteúdo você realmente precisa? Quais campos importam? Quais páginas podem ser consolidadas ou deletadas? Vi sites WordPress de 200 páginas reduzirem a 60 páginas de conteúdo bem estruturado durante a migração — sem nenhuma perda de valor.

Erro 2: Ignorar o Mapa de Redirect

URLs de WordPress seguem um padrão específico (/2024/03/titulo-post/, /category/uncategorized/, etc.). Seu novo site terá padrões de URL diferentes. Cada URL antiga precisa redirecionar para seu equivalente novo, ou você perde o valor de SEO que essas páginas acumularam.

Esse é trabalho tedioso e sem glamour. É também a tarefa técnica mais importante em toda a migração. Use uma ferramenta de crawling como Screaming Frog para exportar todas as URLs indexadas, mapear cada uma para seu novo destino, e implementar redirects 301.

// next.config.js — exemplo de mapeamento de redirect
const nextConfig = {
  async redirects() {
    return [
      {
        source: '/2024/03/slug-post-antigo/',
        destination: '/blog/slug-novo-post',
        permanent: true,
      },
      {
        source: '/category/:slug',
        destination: '/topics/:slug',
        permanent: true,
      },
      // ... potencialmente centenas desses
    ];
  },
};

Para sites grandes, você vai querer gerar esses programaticamente da sua exportação de conteúdo em vez de mapeá-los manualmente.

Erro 3: Não Dar aos Editores um CMS Antes do Launch

Desenvolvedores amam migrações. Editores de conteúdo odeiam elas. Você está tirando a ferramenta que eles conhecem (WordPress) e entregando algo desconhecido. Se você não envolver seus editores cedo — treinando-os no novo CMS, pegando seu feedback no workflow de autoria de conteúdo, tendo certeza de que podem publicar sem ajuda de desenvolvedor — eles vão se revoltar.

Vi uma migração ser cancelada duas semanas antes do launch porque o time de marketing disse "não conseguimos trabalhar com isso." O time de dev tinha construído um site Astro bonito com Sanity Studio, mas ninguém tinha mostrado aos editores como Sanity funciona até a semana do launch.

Traga seu time de conteúdo na semana 2, não na semana 10. Deixe-os criar conteúdo de teste no novo CMS. Ouça suas reclamações. Ajuste a configuração do studio. Isso é o que faz ou quebra a adoção.

FAQ

Como sei que é hora de deixar WordPress?

Use o framework de cinco perguntas acima. Se você responder "sim" para três ou mais das perguntas — mais de 20 plugins, hospedagem acima de $100/mês, incidentes de segurança, Core Web Vitals falhando, ou seu time não consegue enviar recursos rápido o suficiente — é hora. O framework não é sobre odiar WordPress. É sobre avaliar honestamente se a plataforma está te ajudando ou te segurando. Dois ou menos? WordPress provavelmente ainda está bom para suas necessidades, e você deveria focar em otimizar o que você tem.

Qual é a alternativa WordPress mais barata?

Astro com um CMS headless de camada gratuita (plano gratuito do Sanity suporta 3 usuários, plano gratuito do Contentful suporta 5 usuários) deployado em Netlify ou camada gratuita do Vercel. Custo total: $0/mês. Sério mesmo. Para um site de marketing ou blog, essa stack é pronto para produção e perfaz melhor do que um setup WordPress gerenciado de $100/mês. O catch é você precisar de um desenvolvedor confortável com Astro e o CMS de escolha — mas se você está lendo esse artigo, é provavelmente você.

Quanto tempo leva para migrar de WordPress?

Para um site típico pequeno (menos de 50 páginas), espere 3-5 semanas. Sites médios com 50-200 páginas e múltiplos tipos de conteúdo correm 6-10 semanas. Sites grandes com e-commerce ou funcionalidade customizada complexa podem levar 12-20 semanas. A maior variável não é código — é conteúdo. Se seu conteúdo é limpo e bem estruturado, a migração vai rápido. Se está preso em shortcodes de page builder e grupos de campos ACF profundamente aninhados, orçamente tempo extra para extração e reestruturação.

Vou perder SEO se migrar de WordPress?

Você pode, mas não vai se fizer certo. O passo crítico é implementar um mapa de redirect 301 completo de cada URL antiga para seu equivalente novo. Você também precisa preservar seus títulos meta, descrições, e dados estruturados (markup de schema). Crawle seu site existente com Screaming Frog antes da migração, exporte todas as URLs indexadas, e verifique que cada redirect funciona após o launch. A maioria das migrações bem-executadas veem uma flutuação de 2-4 semanas temporária em rankings, seguida por melhoria graças aos Core Web Vitals melhores.

Posso usar WordPress como um CMS headless em vez de migrar completamente?

Sim, e essa é uma etapa intermediária válida. A REST API do WordPress (ou WPGraphQL) deixa você usar WordPress como um backend de conteúdo enquanto constrói um frontend moderno em Next.js ou Astro. Essa abordagem deixa seus editores usar o admin WordPress que conhecem enquanto seu time de dev constrói um frontend mais rápido. Os contras: você ainda mantém uma instalação WordPress (com toda sua sobrecarga de segurança e atualização), e a REST API pode ser lenta sem caching. Recomendaria isso como um degrau, não um destino.

O que acontece com meus plugins WordPress quando migro?

Eles vão embora — e é o ponto. A maioria dos plugins existem para preencher lacunas no WordPress (SEO, caching, formulários, otimização de imagem, segurança). Em uma stack moderna, esses são manipulados pelo framework ou ferramentas de build. Next.js tem otimização de imagem built-in. Astro envia zero JS por padrão. Formulários de contato podem usar serviços como Formspree ou Resend. Analytics se movem para Plausible ou Vercel Analytics. Você vai precisar auditar sua lista de plugins e mapear cada um para seu substituto na nova stack.

Devo migrar tudo de uma vez ou em fases?

Para sites com menos de 100 páginas, migre tudo de uma vez. A sobrecarga de coordenação de rodar dois sistemas simultaneamente não vale. Para sites grandes (200+ páginas), considere uma abordagem em fases: migre as páginas de marketing e blog primeiro, mantenha seções complexas (e-commerce, portais de usuário) no WordPress temporariamente, e use regras de reverse proxy para servir ambos do mesmo domínio. Isso reduz risco mas aumenta complexidade arquitetural.

Preciso de uma agência para migrar de WordPress, ou posso fazer sozinho?

Depende do site. Um desenvolvedor confortável com Next.js ou Astro pode migrar um blog simples em alguns fins de semana. Mas para sites com modelos de conteúdo complexos, e-commerce, funcionalidade personalizada, ou stakes altos de SEO, trabalhar com um time que já fez isso antes economiza tempo real e dinheiro. Fizemos dezenas dessas migrações — os padrões são previsíveis, e as armadilhas são bem conhecidas. Confira nossas capacidades ou entre em contato se quer conversar sua situação específica.