Um cliente me ligou em 2021, imobiliária, orçamento decente, tinha acabado de demitir a agência anterior. O brief era simples: reconstruir o portal de anúncios deles. O dev anterior tinha passado oito meses estruturando uma aplicação Next.js sob medida. Ficava brilhante nas demos. Não podia ser atualizada por uma única pessoa do time deles sem um pull request e um pipeline de deployment. O corretor gerenciando os anúncios estava usando uma Planilha do Google como contorno.
Conclusão-chave: WordPress vence quando editores precisam de autonomia e conteúdo muda diariamente; Next.js vence quando o site é um produto com engenharia por trás. O time decide, não o framework.
Reconstruí isso em WordPress com Advanced Custom Fields Pro em aproximadamente seis semanas. Eles têm gerenciado por conta própria desde então.
Essa história não é um argumento contra Next.js. É um argumento contra escolher uma ferramenta antes de você ter entendido o problema. Já fiz o oposto também, entreguei a um cliente um WordPress multissite quando eles precisavam de uma aplicação React de verdade, e assisti ela ranger sob pressão dezoito meses depois.
Depois de construir mais de 12.000 sites na Seahawk Media, parei de me importar com qual framework "vence". Me importo com qual é entregue, performático e não volta para assombrar você às 23h de um domingo.
---
O Estado Honesto de Ambas as Tecnologias Agora
WordPress potencializa algo em torno de 43% da web inteira. Esse número é jogado por aí tantas vezes que perdeu significado, mas pare um segundo com isso. Quarenta e três porcento. Isso não é inércia legada, isso é efeito de rede, ecossistema de plugins, infraestrutura de hospedagem, e duas décadas de conhecimento institucional embutido em todo servidor compartilhado do planeta.
Next.js, enquanto isso, virou o framework React dominante para aplicações em produção. Os dados de uso de 2023 da Vercel mostraram ela processando centenas de bilhões de requisições por mês. O App Router introduzido no Next.js 13 mudou como as pessoas pensam sobre componentes de servidor, e sim, também quebrou muito tutorial publicado antes de 2023, o que ainda está causando confusão em servidores Discord por aí.
Mas aqui está a coisa: essas duas tecnologias não são realmente competidoras da forma como os argumentos no Twitter as fazem parecer. WordPress é um CMS com uma camada de tema. Next.js é um framework React com integração CMS opcional. O diagrama de Venn do que elas são realmente boas em fazer tem muito pouca sobreposição uma vez que você fica específico sobre os requisitos.
---
Onde WordPress É Genuinamente Imbatível
Sites com Muito Conteúdo Gerenciados por Não-Desenvolvedores
Vou ser direto. Se seu cliente tem um time de marketing, um gerenciador de conteúdo, ou qualquer um que precise publicar sem tocar em código, WordPress é quase sempre a resposta correta. O editor Gutenberg, goste ou não (tenho uma relação complicada com ele desde 2018), oferece aos usuários não-técnicos uma experiência de edição baseada em blocos que realmente funciona.
Nada no ecossistema React chega perto da experiência editorial do WordPress fora da caixa. Sanity.io tem um estúdio lindo, Contentful é sólido para conteúdo estruturado, mas nenhum dos dois tem o ecossistema de plugins ou a familiaridade com mecanismos de busca que WordPress tem. O contratante de marketing médio já usou WordPress antes. Eles não usaram um CMS headless.
Profundidade do Ecossistema de Plugins
WooCommerce, Yoast, Gravity Forms, WP Rocket, ACF Pro. Estes não são apenas plugins, são plataformas inteiras com seus próprios ecossistemas. Quando Seahawk faz um projeto de e-commerce para um cliente com um catálogo modesto (digamos, menos de 5.000 SKUs), WooCommerce emparelhado com uma hospedagem decente em Kinsta ou WP Engine lida bem. Estamos falando de tempos de carregamento sub-2-segundo depois do cache, gerenciamento de estoque completo, recuperação de carrinho abandonado, integração Stripe, tudo configurado numa tarde.
Replicar essa funcionalidade em um build customizado em Next.js com Shopify ou uma camada de comércio headless? Você está olhando para semanas de tempo de desenvolvimento e custos de manutenção contínua que a maioria dos clientes PMEs não conseguem justificar.
Realidades de Orçamento e Cronograma
Honestamente, a maioria dos projetos não tem orçamento para uma aplicação React sob medida. Um site WordPress bem construído com um tema premium como Kadence ou Blocksy, ACF para estruturas de dados customizadas, e WP Rocket para performance pode ser entregue em duas a quatro semanas e mantido por quase qualquer um. Isso não é uma limitação, isso é pragmatismo.
---
Onde Next.js Realmente Justifica Sua Complexidade
Interatividade e Lógica de Aplicação
Em 2022, a Seahawk tinha um projeto fintech, um dashboard para uma empresa de análise de crédito. Feeds de dados em tempo real, filtragem complexa, controle de acesso baseado em função, integrações de API com três provedores de dados diferentes. Olhei para WordPress headless por cerca de duas horas antes de admitir que era a ferramenta errada completamente. Construímos em Next.js com NextAuth.js para autenticação e React Query para busca de dados. Ainda está rodando, ainda é rápido, e o código-fonte é algo que o time interno do cliente consegue realmente contribuir.
WordPress tecnicamente consegue fazer coisas parecidas com aplicações. Mas toda vez que tentei levá-lo para território genuinamente dinâmico, pense em formulários multi-etapa com lógica condicional alimentando APIs externas, dashboards em tempo real, qualquer coisa exigindo estado client-side refinado, acabei lutando contra a arquitetura em vez de trabalhar com ela.
Performance em Escala Sem Dependência de Plugin
Next.js com Static Site Generation (SSG) ou Incremental Static Regeneration (ISR) consegue produzir páginas que são quase vergonhosamente rápidas. Sem plugins de cache necessários. Sem dials de configuração do WP Rocket. As páginas são apenas... HTML estático com hidratação onde você precisa.
A documentação do Vercel sobre ISR explica bem o mecanismo, mas a implicação prática é esta: um site Next.js para uma publicação de notícias com 50.000 artigos pode revalidar páginas individuais em um agendamento sem reconstruir o site inteiro. É genuinamente poderoso e algo que WordPress só consegue aproximar através de fragment caching.
Experiência do Desenvolvedor e Composição da Equipe
Se você é uma agência com um time de desenvolvimento React, desenvolvimento WordPress tem uma curva de aprendizado real que costuma ser subestimada. PHP, a hierarquia de templates do WordPress, arquitetura de hooks, o buraco de coelho do functions.php, não é difícil, mas é diferente. Já contratei desenvolvedores JS talentosos que olharam para um código-base de tema WordPress e se sentiram perdidos nas primeiras duas semanas.
Inversamente, se sua equipe vive em TypeScript e React, um projeto Next.js com um headless CMS como Contentful ou Sanity é um ambiente mais confortável. O código é testável, os tipos são explícitos, e o workflow de deployment via Vercel ou Netlify é genuinamente bom.
---
O Meio-termo do WordPress Headless (E Seus Problemas Reais)
Muitas agências chegaram ao "WordPress headless" como um compromisso, WordPress como backend do CMS, Next.js como frontend. O discurso soa perfeito. O time editorial mantém sua interface familiar; desenvolvedores ganham uma stack de frontend moderna.
Na prática? É genuinamente útil em situações específicas e uma dor de cabeça genuína em outras.
Os bons casos:
- Grandes plataformas de publicação onde o fluxo editorial é inegociável, mas o desempenho do frontend também é um requisito crítico
- Organizações já investidas em infraestrutura WordPress que querem modernizar o frontend sem retreinar os times de conteúdo
- Sites com relacionamentos de conteúdo complexos que se beneficiam da modelagem de dados do ACF, mas precisam de React para a camada de apresentação
Os problemas reais:
- WPGraphQL é excelente, mas debugar a performance de query GraphQL em um contexto WordPress é doloroso. Você está adicionando uma camada de complexidade que pode morder você.
- Funcionalidade de preview para editores, ver um rascunho de post no frontend Next.js, é uma fonte constante de bugs. Já desperdicei dias nisso em múltiplos projetos.
- Hospedar dois sistemas separados significa dois pontos de falha separados, dois conjuntos de custos de infraestrutura e dois pipelines de deploy para manter.
- Recursos em tempo real ainda são desconfortáveis. Você não consegue WebSockets de uma REST API do WordPress sem trabalho adicional significativo.
WordPress headless não é um meio termo mágico. É uma terceira opção com seus próprios trade-offs, e só faz sentido quando os requisitos específicos genuinamente justificam a complexidade.
---
Como eu realmente tomo a decisão (meu checklist real)
Depois de projetos suficientes, reduzi isso a um conjunto rápido de perguntas que faço antes da segunda ligação do cliente.
Prefira WordPress quando:
- O cliente ou sua equipe precisa gerenciar conteúdo de forma independente
- O projeto é principalmente páginas de conteúdo e marketing (mesmo as complexas)
- O orçamento é inferior a £20K e o cronograma é inferior a oito semanas
- E-commerce é necessário, mas o catálogo tem menos de ~10.000 produtos
- O cliente já está no WordPress e a migração não serve a nenhum propósito real
Prefira Next.js quando:
- O projeto tem requisitos significativos de interatividade ou semelhantes aos de uma aplicação
- O time é composto principalmente por desenvolvedores JS/React
- Você precisa de controle granular sobre a estratégia de renderização (SSG, SSR, ISR por rota)
- O sistema de design do frontend é customizado e orientado a componentes React
- Há uma razão genuína para integrar um headless CMS moderno como Sanity ou Contentful
- A longo prazo, o cliente quer ser dono e estender o frontend com seus próprios desenvolvedores JS in-house
E algumas bandeiras vermelhas que devem fazer você pausar independentemente de qual direção você está inclinado:
- Um cliente exigindo Next.js porque leu que é "mais moderno", isso não é um requisito
- Escolher WordPress porque "é mais fácil" quando o projeto genuinamente precisa de lógica de aplicação
- Qualquer um usando a frase "à prova do futuro" como justificativa sem articular o que o futuro realmente exige
---
Performance: Vamos Usar Números Reais
É aqui que a conversa costuma dar errado. As pessoas jogam scores do Lighthouse por aí como se fossem a história inteira.
Um site WordPress bem otimizado, hosting decente, WP Rocket ou FlyingPress, imagens WebP, um tema construído propriamente, rotineiramente marca 90+ no PageSpeed Insights. Seahawk entregou sites WordPress com 95+ consistentemente. Não é magia; é só configuração apropriada.
Uma app Next.js mal configurada com data fetching no lado do cliente em todos os lugares, imagens não otimizadas e nenhuma estratégia de caching apropriada vai marcar nos 50s. Eu já vi.
A diferença entre um "site WordPress rápido" e um "site Next.js rápido" é muito mais estreita do que os evangelistas de framework sugerem. A própria pesquisa de Core Web Vitals do Google mostra que a tecnologia de origem importa muito menos do que a qualidade de implementação. Os gargalos na maioria dos sites com desempenho ruim são imagens, recursos que bloqueiam a renderização, e tempos de resposta do servidor, nenhum dos quais é inerentemente problema do WordPress ou Next.js.
O que Next.js oferece, genuinamente, é mais controle sobre o desempenho. Você pode tomar decisões precisas por rota sobre como os dados são buscados e quando as páginas são renderizadas. Mas controle só ajuda você se exercê-lo corretamente.
---
SEO: WordPress Tem a Vantagem do Ecossistema, Não a Vantagem Inerente
Aqui está um conceito errado que tenho que corrigir regularmente: WordPress não é inerentemente melhor para SEO. Aplicações Next.js com server-side rendering apropriado são totalmente rastreáveis pelo Google. O componente <Head>, geração de sitemap via next-sitemap, dados estruturados via JSON-LD, tudo é alcançável.
O que WordPress tem é Yoast SEO ou Rank Math, que dão aos usuários não-técnicos uma interface visual para gerenciar títulos meta, descrições, URLs canônicas e schema markup. Isso é uma vantagem de fluxo editorial, não uma vantagem técnica.
Se o site será gerenciado por desenvolvedores que entendem meta tags e dados estruturados, SEO em Next.js não é mais difícil de implementar. Se o site precisa de um consultor de SEO ou gerente de marketing para ajustar títulos de página sem abrir um ticket, dê a eles WordPress.
---
FAQ
WordPress não é antigo e está sendo substituído por frameworks modernos?
WordPress está sendo "substituído" desde pelo menos 2014, quando comecei a ouvir esse argumento seriamente. Não aconteceu e não espero que aconteça. A questão não é se WordPress é moderno, é se ele resolve o problema que você tem. Para uma porcentagem enorme de sites, resolve. A Automattic continua investindo pesadamente em Gutenberg e na experiência de Full Site Editing. Está evoluindo, só não de formas que deixam o Twitter animado.
Você pode usar WordPress como backend com um frontend React?
Sim, isso é WordPress headless, e cobri os trade-offs acima. A versão curta: use WPGraphQL ou a REST API para servir conteúdo, construa seu frontend em Next.js. Funciona. Também adiciona complexidade. Faça isso apenas se os requisitos realmente exigirem, não porque soa arquitetonicamente interessante.
Quanto tempo leva para construir um site em Next.js comparado com WordPress?
Depende genuinamente do escopo, mas para um site de marketing comparável, Next.js normalmente demora 40-60% a mais para entregar na primeira vez. Você está escrevendo componentes do zero, configurando um design system, integrando um CMS, configurando deployment. WordPress com um tema premium e ACF te leva muito mais longe, mais rápido. Onde Next.js compensa o investimento de tempo é na escalabilidade em longo prazo e na ergonomia do desenvolvedor, desde que a composição do time justifique.
E quanto a Astro, Remix ou outros frameworks?
Vale a pena conhecer. Astro em particular é interessante para sites estáticos com muito conteúdo e venho experimentando com ele em projetos menores na Seahawk. Remix tem um modelo de carregamento de dados atraente. Mas nenhum dos dois tem a maturidade de ecossistema ou familiaridade do cliente que WordPress tem, nem a adoção empresarial de Next.js. Para a maioria das decisões de agência agora, ainda é uma escolha entre WordPress ou Next.js, com todo o resto como uma consideração de nicho.
Devo sempre recomendar a escolha técnica "melhor" aos meus clientes?
Não. A melhor escolha técnica que o time de um cliente não consegue manter é pior que a segunda melhor escolha que eles realmente conseguem usar. Aprendi isso da forma difícil mais de uma vez. Entregue a coisa que funciona para os humanos envolvidos, não apenas para o diagrama de arquitetura.
---
A verdadeira habilidade não é saber WordPress ou saber Next.js. É saber quando recorrer a cada um, e ser honesto o bastante com você mesmo e seus clientes para fazer essa escolha baseado na realidade deles, não nas suas preferências.
Aquele cliente do setor imobiliário de 2021? Ainda está no WordPress. Ainda gerencia seus próprios anúncios. Sem ligações de domingo à noite da minha parte.