Em 2021, um cliente veio a mim com um briefing que eu tinha ouvido aproximadamente quarenta vezes antes: "Queremos o backend WordPress que nossos editores conhecem, mas o site precisa ser rápido. Tipo, bem rápido mesmo." Eles tinham lido algo sobre arquitetura headless em uma página de marketing do Vercel. Estavam convencidos antes eu dizer uma palavra. Peguei o projeto, construí um frontend Next.js no Vercel puxando conteúdo de uma WordPress REST API, e entreguei algo genuinamente impressionante. Os scores do Lighthouse eram lindos. O cliente adorou por cerca de três meses.fast. Like, really fast." They'd read something about headless architecture on a Vercel marketing page. They were sold before I said a word. I took the project, built a Next.js frontend on Vercel pulling content from a WordPress REST API, and delivered something genuinely impressive. The Lighthouse scores were beautiful. The client loved it for about three months.
Depois o gerente de marketing deles quis adicionar um formulário pop-up. Depois um plugin de membership. Depois live chat com lógica condicional ligada a categorias de posts. E lentamente, silenciosamente, toda a configuração começou a reclamar.
Esse projeto me ensinou mais sobre os limites reais do WordPress headless do que qualquer tutorial jamais fez. Então deixa eu te dar o quadro honesto.
O Que "WordPress Headless no Vercel" Realmente Significa
Vale a pena ser preciso aqui, porque as pessoas usam o termo de forma solta.
Você está rodando WordPress (geralmente em um servidor separado, um host gerenciado como Kinsta ou WP Engine, ou até uma VPS barata) puramente como um sistema de gerenciamento de conteúdo. Nenhum tema serve o frontend. Em vez disso, seu app Next.js (ou Nuxt, ou Astro, ou SvelteKit) busca conteúdo via WordPress REST API ou WPGraphQL, então Vercel compila e faz deploy desse frontend.Kinsta or WP Engine, or even a cheap VPS) purely as a content management system. No theme serves the frontend. Instead, your Next.js (or Nuxt, or Astro, or SvelteKit) app fetches content via the WordPress REST API or WPGraphQL, then Vercel builds and deploys that frontend.
Vercel não hospeda WordPress em si. Ponto final. WordPress precisa de PHP, um banco de dados (MySQL) e execução no lado do servidor. Vercel roda funções serverless Node.js e arquivos estáticos. Você não consegue colocar uma instalação WordPress no Vercel do jeito que colocaria em um servidor cPanel.
Então quando alguém diz "hospede WordPress no Vercel", o que eles realmente querem dizer é: hospede o frontend no Vercel, enquanto WordPress roda em outro lugar totalmente. Essa distinção importa enormemente, e fico chocado com a frequência com que é ignorada em posts de blog.frontend on Vercel, while WordPress runs somewhere else entirely. That distinction matters enormously, and I'm shocked how often it gets glossed over in blog posts.
Quando Essa Setup Realmente Brilha
Quero ser justo aqui. Entreguei projetos de WordPress headless + Vercel dos quais realmente me orgulho, e há condições específicas onde a arquitetura justifica sua complexidade.
Sites editoriais ou de mídia com alto tráfego
Seahawk teve um projeto para um publisher de mídia esportiva em 2022. Dezenas de milhares de page views por dia, time de conteúdo com doze pessoas, editores que se recusaram categoricamente a deixar WordPress. Construímos um frontend Next.js no Vercel com Incremental Static Regeneration (ISR) configurado para janelas de revalidação de 60 segundos. Em um grande dia de partida, o servidor WordPress de origem mal se mexeu. A rede edge do Vercel absorveu o pico de tráfego sem uma única conversa sobre escala.
Para sites onde conteúdo muda em lotes (artigos vão ao ar, não são editados a cada dois minutos), ISR é um encaixe brilhante. Você consegue performance de arquivo estático na edge com conteúdo razoavelmente fresco.
Sites que precisam de flexibilidade extrema no frontend
Se seu designer quer animações de scroll customizadas, transições de componentes complexas, ou uma ferramenta interativa baseada em React embutida no meio da página, um tema WordPress tradicional está lutando contra você o tempo todo. Um frontend desacoplado devolve esse controle inteiramente ao desenvolvedor. Os constrangimentos de design de temas WordPress simplesmente desaparecem.
Equipes de desenvolvedores já profundamente no ecossistema Node/React
Se seu time entrega aplicações React o dia todo e trata PHP como uma língua estrangeira, forçá-los no desenvolvimento de temas WordPress é genuinamente doloroso. Headless permite que eles fiquem no seu mundo enquanto oferece aos editores de conteúdo uma ferramenta que já conhecem. Essa é uma verdadeira vitória de produtividade no time certo.
A Stack de Ferramentas que Eu Realmente Uso
Se estou usando headless WordPress + Vercel hoje, aqui está a aparência da stack:
- Host WordPress: Kinsta ou Cloudways. Ambos lidam com backups gerenciados de MySQL sem eu ter que pensar nisso. Kinsta or Cloudways. Both handle managed MySQL backups without me thinking about it.
- Camada GraphQL: plugin WPGraphQL. Torna as consultas de conteúdo muito mais limpas do que a REST API para tipos de posts complexos. WPGraphQL plugin. It makes content queries far cleaner than the REST API for complex post types.
- Framework frontend: Next.js. App Router se o time estiver confortável com isso, Pages Router se precisarmos de uma transição mais rápida para alguém menos experiente. Next.js. App Router if the team is comfortable with it, Pages Router if we need a faster handoff to someone less experienced.
- Deployment: Vercel, obviamente. Deployments de preview por PR valem sozinhos o preço de admissão. Vercel, obviously. Preview deployments per PR are worth the price of admission alone.
- Revalidação sob demanda: webhooks do WordPress (via um plugin customizado ou hooks do Advanced Custom Fields) que fazem ping em um endpoint de revalidação do Vercel quando o conteúdo é publicado. WordPress webhooks (via a custom plugin or Advanced Custom Fields hooks) that ping a Vercel revalidation endpoint when content is published.
- Conteúdo de preview: O pacote @wpengine/headless ou uma configuração customizada de draft mode do Next.js para que editores possam visualizar posts não publicados sem um rebuild. The
@wpengine/headlesspackage or a custom Next.js draft mode setup so editors can preview unpublished posts without a rebuild.
Aquele último ponto sobre previews levou muito mais tempo para eu acertar do que me sinto confortável em admitir. Editores esperam clicar em "Preview" no WordPress e ver exatamente o que vai ao ar. Com uma arquitetura desacoplada, conectar isso corretamente leva um dia inteiro de trabalho.
Onde Isso Quebra (E Quebra Mesmo)
Certo. Aqui é onde preciso ser honesto com você, porque essa é a parte que a maioria dos posts "headless é o futuro" pula.
Plugins. Tantos plugins.
O poder do WordPress vem do seu ecossistema de plugins. WooCommerce, Gravity Forms, plugins de membros, sistemas de agendamento, ferramentas avançadas de SEO como Yoast (sim, Yoast ainda funciona, mas a renderização frontend das suas meta tags requer conexões extras), plugins de slider, qualquer coisa que toque o frontend. Em uma arquitetura tradicional, o plugin renderiza PHP diretamente na página. Em uma arquitetura headless, ele não faz nada visível a menos que você tenha explicitamente construído um componente frontend para replicar sua saída.
Tive um cliente no final de 2023 que veio para mim no meio do projeto (não um projeto Seahawk, uma bagunça de outro que herdei). Eles tinham ido headless com boas intenções e depois tentaram adicionar WooCommerce. O que se seguiu foi um desvio de quatro meses construindo um fluxo customizado de carrinho e checkout em React, chamando a REST API do WooCommerce, tratando webhooks do Stripe manualmente, e basicamente reinventando rodas que o WooCommerce já tinha construído. O custo em tempo foi aproximadamente três vezes maior do que teria sido usando apenas uma arquitetura tradicional WordPress + WooCommerce.
WooCommerce headless é viável. WooCommerce tem sua REST API bem documentada. Mas "viável" e "vale a pena" são perguntas diferentes.WooCommerce has documented their REST API well. But "doable" and "worth it" are different questions.
A experiência de preview nunca corresponde completamente
Entreguei seis ou sete projetos headless WordPress até agora e nunca tive um cliente que estivesse inteiramente satisfeito com o fluxo de preview. Sempre há uma lacuna entre clicar em "Preview" no WordPress e ver o que realmente renderiza. Às vezes é um problema de cookie de modo de rascunho. Às vezes é o timing de cache ISR. Editores que vieram de uma arquitetura WordPress tradicional acham desorientador, e as reclamações vêm quietly mas persistentemente.
Dois sistemas para manter
Isso parece óbvio, mas genuinamente pega as equipes desprevenidas. Agora você está rodando duas preocupações de infraestrutura separadas: o servidor WordPress (com suas próprias atualizações, patches de segurança, conflitos de plugins, backups de banco de dados) e o frontend Vercel (com seu próprio pipeline de build, variáveis de ambiente, limites de função serverless). Quando algo quebra às 2 da manhã, você tem o dobro de lugares para procurar.
Na Seahawk temos tido projetos onde um plugin WordPress se atualiza automaticamente e silenciosamente muda o formato de resposta de uma REST API, que quebrava um componente do frontend. Nenhum erro lançado no lado do WordPress. Apenas uma lacuna de conteúdo silenciosa no site ativo. Esse tipo de falha é genuinamente mais difícil de capturar do que um erro tradicional do WordPress.
Conteúdo em tempo real é complicado
Se seu site tem conteúdo que muda frequentemente (pense em placares ao vivo, preços de ações, comentários gerados por usuários, qualquer coisa que precise de atualização sub-minuto), o modelo de revalidação do ISR é uma má opção. Você acaba servindo dados obsoletos ou batendo no seu backend WordPress a cada requisição, o que derrota uma parte significativa do argumento de desempenho.
Os Custos: O Que Ninguém Coloca na Proposta
Deixe-me ser concreto sobre dinheiro e tempo, porque vi agências fazer lances muito baixos nesses projetos.
- Overhead de build inicial: Orçamente pelo menos 30-40% mais tempo de desenvolvimento em comparação com um build WordPress tradicional de complexidade equivalente. Essa diferença é real. Rastreei isso entre projetos. Budget at least 30-40% more development time compared to a traditional WordPress build of equivalent complexity. That gap is real. I've tracked it across projects.
- Preço do Vercel: O plano Hobby gratuito não serve para trabalho comercial. Pro custa $20/mês por assento, e os custos de bandwidth e execução de função serverless se acumulam em sites com muito tráfego. Faça as contas antes de se comprometer. The free Hobby plan won't cut it for commercial work. Pro is $20/month per seat, and bandwidth and serverless function execution costs stack up on high-traffic sites. Run the numbers before you commit.
- Hospedagem WordPress: Você ainda precisa de um host gerenciado confiável. Isso é mais $30-100/mês dependendo do tráfego. Então sua narrativa de "hospedagem estática barata" desmorona rapidamente. You still need a reliable managed host. That's another $30-100/month depending on traffic. So your "cheap static hosting" narrative falls apart quickly.
- Manutenção contínua: Duas plataformas, dois conjuntos de possíveis problemas. Considere pelo menos 20% mais tempo de retainer mensal comparado a uma configuração WordPress gerenciada tradicional. Two platforms, two sets of potential problems. Factor in at least 20% more monthly retainer time compared to a traditional managed WordPress setup.
Quando Eu Realmente Recomendaria
Depois de tudo que acabei de dizer, aqui estão os cenários específicos onde eu diria a um cliente que headless WordPress no Vercel vale as compensações:
- O site é pesado em conteúdo e leitura: principalmente artigos ou landing pages, não fluxos transacionaiscontent-heavy and read-heavy: mostly articles or landing pages, not transactional flows
- O time de conteúdo já conhece WordPress e não cogita mudar de CMSalready knows WordPress and won't entertain switching CMS
- Performance em escala é um requisito de negócio genuíno, não apenas um diferencial
- O time de desenvolvimento está confortável com React e tooling JavaScript moderno
- Não há dependências complexas de plugins no escopo, ou você explicitamente as delimitou are in the brief, or you've explicitly scoped around them
- Um proprietário técnico de longo prazo está em posição que entende ambos os lados da stack
E aqui estão os cenários onde eu recuaria:
- O cliente quer WooCommerce ou qualquer feature frontend dependente de plugin
- O time é pequeno e não consegue absorver a sobrecarga de manutenção de dois sistemas
- Editores precisam de um fluxo de preview rápido e familiar, e não há orçamento para construir isso adequadamente
- O site tem contas de usuário, personalização dinâmica ou requisitos de dados em tempo real
- O cliente apenas quer porque "soa moderno"
Esse último. Ouço mais do que deveria.
Alternativas que Vale a Pena Considerar Primeiro
Antes de usar esse stack por padrão, eu pelo menos colocaria essas opções na mesa:
- WordPress tradicional em um bom host gerenciado: Kinsta, Cloudways ou Rocket.net com caching apropriado (WP Rocket ou Nginx FastCGI cache) vão te dar scores do Lighthouse na casa dos 90 sem desacoplar nada. Já vi isso surpreender clientes que achavam que precisavam ir headless só para ser rápido. Kinsta, Cloudways, or Rocket.net with proper caching (WP Rocket or Nginx FastCGI cache) will get you Lighthouse scores in the 90s without decoupling anything. I've seen this surprise clients who assumed they needed to go headless just to be fast.
- Faust.js da WP Engine: Construído especificamente para WordPress headless, ele gerencia muito do boilerplate (modo preview, autenticação, roteamento) que você teria que construir sozinho. Vale a pena olhar se você está comprometido com a arquitetura. Built specifically for headless WordPress, it handles a lot of the boilerplate (preview mode, authentication, routing) that you'd otherwise build yourself. Worth a look if you're committed to the architecture.
- Um CMS headless feito para esse propósito: Se seu time não precisa realmente do ecossistema de plugins do WordPress, algo como Sanity ou Contentful pode ser um ajuste mais limpo para um frontend Next.js hospedado no Vercel. Nenhum servidor PHP para manter. If your team doesn't actually need WordPress's plugin ecosystem, something like Sanity or Contentful might just be a cleaner fit for a Vercel-hosted Next.js frontend. No PHP server to maintain at all.
---
FAQ
Posso literalmente fazer deploy do WordPress em Vercel?
Não. WordPress requer PHP e um banco de dados MySQL. A infraestrutura do Vercel é construída em torno de funções serverless Node.js e servimento de arquivos estáticos. Você pode fazer deploy do seu frontend Next.js (ou outro JavaScript) em Vercel e fazer esse frontend buscar conteúdo de uma instância WordPress hospedada em outro lugar, mas o WordPress em si roda em um servidor separado.
Headless WordPress prejudica meu SEO?
Não inerentemente, mas pode se você configurar com negligência. Com Next.js você obtém renderização no lado do servidor e geração estática, ambas produzem HTML totalmente renderizado que mecanismos de busca podem indexar sem problemas. As áreas de risco são manipulação de meta tags (a saída do Yoast precisa ser explicitamente consumida e renderizada pelo seu frontend) e geração de sitemap (você vai querer construir uma rota de sitemap dinâmica em Next.js que puxe do WordPress). Acertando esses pontos, SEO funciona bem.
O plano gratuito do Vercel é suficiente para um frontend headless WordPress?
Para um projeto pessoal ou prototipo, possivelmente. Para um site comercial, não. O plano Hobby proíbe uso comercial nos termos do Vercel, e você vai bater nos limites de invocações de funções serverless em qualquer site com tráfego real. Orce o plano Pro desde o primeiro dia.
Como faço para lidar com o modo preview do WordPress em Next.js?
Next.js tem um Draft Mode embutido (anteriormente Preview Mode no Pages Router). O padrão é: criar uma rota /api/preview em Next.js que define um cookie de preview, depois configurar um botão "Preview" do WordPress para chamar essa rota com um token secreto. Quando o cookie está presente, seus componentes de página buscam conteúdo de rascunho diretamente do WordPress em vez da versão estática em cache. WPGraphQL suporta queries de posts em rascunho nativamente, e é por isso que prefiro em vez da REST API para este fluxo em particular./api/preview route in Next.js that sets a preview cookie, then configure a WordPress "Preview" button to call that route with a secret token. When the cookie is present, your page components fetch draft content directly from WordPress instead of the cached static version. WPGraphQL supports draft post queries natively, which is why I prefer it over the REST API for this particular flow.
E quanto a formulários e páginas de contato?
Formulários são uma das migrações plugin-para-headless mais limpas. Um envio do Gravity Forms pode fazer post direto para a Gravity Forms REST API. Alternativamente, pule formulários do WordPress inteiramente e use algo como Netlify Forms (embora você esteja no Vercel) ou uma integração direta do Formspree no frontend. Honestamente, para formulários, normalmente vou direto para o Formspree e considero resolvido em uma tarde.Formspree and call it done in an afternoon.
---
Headless WordPress no Vercel é uma arquitetura real com casos de uso reais. Não é uma bala de prata e não é um truque. Os times que mais aproveitam disso são aqueles que entraram com os olhos bem abertos sobre o que estavam abrindo mão, orçaram o tempo de build extra e tinham um problema específico de performance ou flexibilidade que estavam resolvendo. Se isso parece seu projeto, vale a pena. Se não, poupe-se da complexidade.