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

WordPress Headless é a escolha certa quando uma de três coisas é verdadeira. O setup clássico padrão do WordPress está errado caso contrário, headless adiciona overhead de engenharia e você não deveria pagar por isso sem um motivo 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.

O segundo motivo é experiência de engenharia sem perder o time editorial. Engenheiros que escrevem TypeScript todo dia ficam frustrados com o stack front-end do WordPress. Templates PHP, jQuery, shortcodes de page builder, a linguagem está errada, o tooling está errado, a história de deploy está errada. Headless permite que o time de engenharia trabalhe em uma codebase Next.js ou Astro com controle de versão, type checking, 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 auth ou interatividade. Astro é o caminho mais simples para sites pesados em conteúdo que se beneficiam de static generation e precisam de partial hydration apenas em componentes específicos. Nuxt é a escolha certa quando o time já usa Vue. Optamos por padrão por 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 por 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.

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, fechado atrás de Cloudflare Access ou um IP allowlist. Tráfego público nunca bate em 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, custom post type, taxonomy e campo ACF, buscado via WPGraphQL em build ou revalidação. Mídia vem depois: toda imagem enviada, com otimização WebP lado WordPress se disponível ou otimização de imagem lado front-end caso contrário. Metadados SEO é o terceiro, campos Yoast ou Rank Math conectados via schemas 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 faz errado. Substituímos JSON-LD emitido por plugins 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 no Yoast Redirect Manager ou no plugin Redirection é exportada e embarcada como 301s em vercel.json ou _redirects no 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 roda em um front-end headless. A maioria das migrações embarca uma reescrita de conteúdo como parte do projeto, extraímos o conteúdo, reformatamos para combinar com a 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 ACF flexible content. O conteúdo sobrevive, o visual builder não, e o page weight 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, security plugins, caching plugins, schema plugins, social-share plugins. Cada um recebe ou uma substituição por código no front-end ou por um serviço gerenciado. A contagem de plugins tipicamente cai setenta a oitenta por cento pós-migração. Isso é parte da vitória, não uma regressão.