Headless WordPress em Next.js ou Astro — mantenha wp-admin, elimine a taxa de plugins.

Headless WordPress é a escolha certa quando uma de três coisas é verdadeira. A configuração clássica padrão do WordPress é errada caso contrário — headless adiciona complexidade de engenharia e você não deveria pagar por isso sem uma razão real.

A primeira razão é performance. Um site WordPress vanilla com cinco ou seis plugins entrega cerca de setecentos quilobytes de JavaScript antes do H1 renderizar, e com Elementor ou Divi mais uma stack típica de addons, sites do mundo real entregam dois a três megabytes no primeiro carregamento. Há um teto duro no Lighthouse e nos dados de campo do CrUX mesmo com o melhor plugin de cache na frente. Headless em um front-end Next.js ou Astro estático ou ISR limpa noventa e cinco mais no Lighthouse em hospedagem compartilhada consistentemente e os dados de campo acompanham.

A segunda razão é experiência de engenharia sem perder o time editorial. Engenheiros que escrevem TypeScript diariamente ficam frustrados com a stack do front-end WordPress. Templates PHP, jQuery, shortcodes de page builder — a linguagem é errada, as ferramentas são erradas, a história de deploy é errada. Headless permite que o time de engenharia trabalhe em uma base de código Next.js ou Astro com controle de versão, verificação de tipos, deploy em edge, e design orientado a componentes enquanto editores mantêm wp-admin, Yoast e ACF inalterados.

A terceira razão é multi-destino. Um site de marketing, um app móvel, um portal interno e um portal de parceiros todos lendo da mesma fonte de conteúdo. WordPress clássico é um CMS, um front-end. Headless WordPress se torna o back-end editorial para quaisquer destinos que você precise, cada um com seu próprio framework de front-end otimizado para sua superfície.

Três decisões definem a maior parte da história de engenharia.

O framework front-end é geralmente Next.js com App Router para sites de marketing e apps com autenticação ou interatividade. Astro é o caminho mais simples para sites pesados em conteúdo que se beneficiam de geração estática e precisam de hidratação parcial apenas em componentes específicos. Nuxt é a escolha certa quando o time já executa Vue. Nós padronizamos em Next.js mais WPGraphQL mais um pequeno scaffolding customizado em vez de Faust.js porque Faust embarca opiniões com as quais às vezes discordamos — mas Faust é excelente se você quer que o framework tome as decisões para você.

A camada de API é WPGraphQL por padrão. API tipada por forma de query, suporte a ACF via WPGraphQL for ACF, suporte a Yoast via Yoast SEO for WPGraphQL, equivalente a RankMath. WP REST funciona sem plugin e é adequado para sites simples, mas você busca mais dados do que precisa e não há introspection de schema no front-end. Recorra a REST apenas quando WPGraphQL for bloqueado pela política de hosting ou quando você tiver um dataset muito pequeno.

O hosting separa o front-end do back-end. Front-end em Vercel, Netlify, ou Cloudflare Pages dependendo da preferência do time. Back-end em Cloudways, Kinsta, ou WP Engine em um subdomínio não-público — cms.yourdomain.com — bloqueado atrás de Cloudflare Access ou um IP allowlist. Tráfego público nunca atinge WordPress diretamente. WordPress fica invisível da web pública; apenas seus editores sabem que está lá.

Uma construção headless WordPress bem-sucedida transporta cinco coisas do lado WordPress para o front-end público sem perder fidelidade no caminho.

Conteúdo é o óbvio — todo post, página, tipo de post customizado, taxonomia, e campo ACF, buscados via WPGraphQL em build ou revalidação. Mídia segue: toda imagem enviada, com otimização WebP do lado WordPress se disponível ou otimização de imagem do lado front-end caso contrário. Metadados de SEO são o terceiro — campos Yoast ou Rank Math ponteados via esquemas GraphQL acompanhantes de plugin, renderizados como canonical, title, description, OG, e Twitter card a partir da resposta tipada.

Schema é o quarto e a maioria dos times lida com isso errado. Nós substituímos JSON-LD emitido por plugin com templates escritos à mão no front-end para output mais limpo. Article, BlogPosting, Service, Product, BreadcrumbList — todos gerados a partir de dados tipados, validados em tempo de build. Redirects são o quinto: qualquer coisa em Yoast Redirect Manager ou no plugin Redirection é exportada e enviada como 301s em vercel.json ou _redirects em Netlify, nunca como redirects JavaScript que perdem sinal de ranking em trânsito.

O transporte é automatizado. Nós não construímos à mão nenhuma dessas camadas por site. O mesmo scaffolding é enviado através de cada construção headless que fazemos, razão pela qual o custo por site diminuiu ao longo do tempo mesmo com a superfície de engenharia crescendo.

Page builders quebram primeiro. Elementor e Divi injetam CSS e HTML pesados no front-end. Nada disso funciona em um front-end headless. A maioria das migrações traz uma reescrita de conteúdo como parte do projeto — extraímos o conteúdo, reformatamos para corresponder à biblioteca de componentes do novo front-end, e pulamos importar a camada visual builder por completo. Editores ganham uma nova UX de edição mais simples baseada em blocos Gutenberg mais conteúdo flexível ACF. O conteúdo sobrevive, o visual builder não, e o peso da página cai significativamente como efeito colateral.

Comentários e formulários também precisam ser repensados. Comentários nativos do WordPress não renderizam headless sem proxying da renderização. A maioria dos times os substitui por Disqus, Giscus, ou um sistema de comentários customizado no front-end. Formulários típicamente migram para ConvertKit, HubSpot Forms, ou um endpoint Next.js customizado que dispara um serviço de envio de email. Contact Form 7 e Gravity Forms têm versões headless-friendly mas requerem integração GraphQL explícita que adiciona trabalho.

Front-end plugins são a terceira coisa que quebra. Qualquer coisa que injete HTML ou JavaScript no front-end do WordPress para de funcionar — plugins de segurança, plugins de cache, plugins de schema, plugins de social-share. Cada um é substituído por código no front-end ou por um serviço gerenciado. A contagem de plugins típicamente cai setenta a oitenta por cento pós-migração. Isso faz parte da vitória, não uma regressão.