Quanto tempo demora uma migração para headless WordPress em 2026
Seis a dezasseis semanas para projetos típicos. A forma é em quatro fases: descoberta, scoping, construção e cutover, afinação. As variáveis que esticam ou comprimem o cronograma são o tamanho do catálogo, o número de integrações, a preservação de URLs e a prontidão da equipa editorial, não a escolha do framework. Todos os intervalos de semanas deste artigo são estimativas da nossa própria prática de projetos, não um estudo de mercado; o cronograma vinculativo é fixado depois da descoberta.
Este artigo está ancorado no pilar de serviços headless WordPress e emparelha com a matriz de decisão Next.js vs Astro para o ângulo do framework e com Cloudflare Workers e WordPress no edge para a camada de runtime.
TL;DR
- Sites apenas editoriais com menos de cinquenta páginas: quatro a seis semanas.
- WooCommerce até alguns milhares de SKUs com integrações standard: dez a catorze semanas.
- Multi-região ou multilingüe com integrações personalizadas: catorze a dezasseis semanas, por vezes mais.
- As semanas caras são o scoping (semana um e dois) e o cutover (último fim de semana), não a construção em si.
- O preço é individual por projeto; publicamos o cronograma, não o preço.
Quais são as fases de uma migração para headless WordPress
As fases não são rótulos num diagrama de Gantt; mapeiam-se em modos de trabalho distintos que precisam de pessoas diferentes na sala.
Fase 1, descoberta (semana zero a duas)
As partes envolvidas, a equipa editorial, o responsável de analítica e o contacto técnico passam por três a cinco sessões ao longo de uma a duas semanas. Os entregáveis são uma auditoria do modelo de conteúdo, uma baseline de desempenho retirada do site em produção (TTFB, TTI, LCP por template), um inventário de plugins e integrações e um esboço do mapa de migração SEO.
O resultado da descoberta é input de decisão, não arquitetura. A equipa que salta a descoberta para “poupar tempo” paga o custo de volta na semana oito, quando aparece uma integração não declarada e a camada de dados precisa de ser redesenhada.
Fase 2, scoping (semana dois a três)
Decisão de arquitetura: Astro 5+ ou Next.js 15, escolha do rendering por rota, padrão de obtenção de dados (REST ou GraphQL), estratégia de invalidação de cache. O mapa de redirecionamentos é assinado aqui, não mais tarde. O fluxo editorial é finalizado: pré-visualizações, rascunhos, publicações agendadas, fluxos com vários autores.
O scoping termina com um engagement letter escrito e uma lista fechada de entregáveis. Tudo o que faltar aqui torna-se uma change order na semana dez, que é o momento mais caro para negociar âmbito.
Fase 3, construção e cutover (semana três a doze)
A construção corre em sprints de duas semanas com uma demo semanal. Cada demo é em staging, não em localhost, para que a equipa veja como o lado editorial se comporta de facto na nova stack. O primeiro sprint é o design system e um único template ponta a ponta; os sprints seguintes distribuem-se por tipo de template.
O próprio cutover é uma janela de quarenta e oito a setenta e duas horas, planeada deliberadamente. Dois padrões funcionam: troca de DNS (mais limpa, rollback mais lento) e cutover por reverse proxy (rollback mais rápido, mais peças móveis). O mapa de redirecionamentos é aplicado no edge, não em PHP.
A janela de medição lado a lado corre uma a duas semanas antes do cutover. Apanha regressões em etiquetas de tracking, validação de schema e Core Web Vitals antes de chegarem a produção.
Fase 4, afinação e retainer (semana doze a dezasseis)
Os TTLs de cache no edge são afinados por rota. A observability (Cloudflare Logpush, testes sintéticos, alertas em TTFB e taxas 5xx) é ligada. A entrega ao retainer cobre trabalho de novas funcionalidades, revisões trimestrais de Tech Radar e um roadmap para as necessidades em evolução da equipa editorial.
Esta e a fase mais frequentemente saltada. Saltá-la custa seis meses de incidentes de baixa intensidade que a equipa não consegue diagnosticar porque nada está instrumentado.
O que atrasa uma migração headless WordPress
Três padrões empurram um projeto de seis semanas para doze e um projeto de doze semanas para vinte.
Descoberta tardia de integrações. Um gateway de pagamento personalizado, uma integração de ERP legado por SOAP, um plugin de nicho sem superfície REST. Cada um exige um adaptador à medida. Cada adaptador acrescenta duas a quatro semanas de construção, mais negociação contratual se um terceiro detiver o sistema upstream.
Preservação de URLs. Um site com trinta padrões únicos de URL é trabalho mecânico. Um site com trezentos padrões mais uma reestruturação de permalinks é um projeto à parte. O mapa de 301 é assinado no scoping, não improvisado na semana dez.
Reformulação do modelo de conteúdo. Quando o conteúdo WordPress existente está estruturado em torno dos templates do tema em vez de campos estruturados, o frontend não consegue consumi-lo de forma determinística. Reconstruir o modelo de conteúdo acrescenta duas a seis semanas e exige disponibilidade da equipa editorial que a maioria das equipas subestima.
Como acelerar uma migração headless WordPress
Quatro condições encurtam o calendário de forma consistente.
Modelo de conteúdo limpo. Custom post types, grupos de campos ACF ou Meta Box, ou uma mudança recente para o editor de blocos com padrões estruturados. O frontend lê dados estruturados e renderiza de forma determinística. Poupa duas a quatro semanas.
Design system pré-existente. Uma biblioteca em Figma, um conjunto de tokens ou uma biblioteca de componentes que a equipa já usou antes. Poupa uma a duas semanas de trabalho de fundação no primeiro sprint.
Disponibilidade da equipa editorial. Quando a equipa editorial pode estar presente em pré-visualizações semanais e aprovar fluxos, a construção não fica parada à espera de esclarecimentos. Poupa uma a duas semanas ao longo do projeto.
Equipa sénior dos dois lados. Um sénior product owner do lado do cliente reduz para metade o ciclo de pergunta e resposta. A agência não pode fabricar isto; tem de vir do comprador.
O que verificar antes de uma migração para headless WordPress
Uma estimativa sem inventário é um palpite. A lista seguinte pode ser percorrida no painel e na base de dados num dia de trabalho, antes de alguém indicar uma data. Cada ponto é um sítio onde um tema clássico fazia algo de graça e uma implementação headless tem de o reconstruir.
Tipos de conteúdo e taxonomias. Quantos custom post types e taxonomias existem e quais têm arquivos próprios em URLs que estão no índice. Cada tipo com arquivo é um template e uma rota próprios no frontend.
Campos ACF e meta. Grupos de campos, repetidores, flexible content, campos de relação. É preciso confirmar se estão expostos na REST API (show_in_rest) ou no esquema do WPGraphQL. Um flexible content com uma dúzia de layouts significa uma dúzia de componentes.
Shortcodes e blocos de plugins. O conteúdo guardado na base de dados como shortcode chega ao frontend como texto em bruto entre parênteses retos. As ocorrências contam-se com uma consulta a post_content antes de decidir se são renderizadas ou reescritas.
Pré-visualização e rascunhos. Um tema clássico traz a pré-visualização de origem. Em headless é preciso construí-la: um pedido autenticado do rascunho e um modo de pré-visualização no frontend. A equipa editorial nota a falta logo na primeira semana. Para pedidos REST autenticados, o WordPress oferece palavras-passe de aplicação desde a versão 5.6: funcionam com HTTP Basic, estão ativas por omissão apenas em sites com HTTPS e não permitem iniciar sessão no wp-admin (guia de integração das palavras-passe de aplicação).
Formulários. O Contact Form 7 ou o Gravity Forms são renderizados dentro do tema PHP. Sem o tema, um formulário precisa de um endpoint, validação, proteção contra spam e os textos de consentimento do RGPD que antes o plugin acrescentava.
Pesquisa. O ?s= nativo desaparece com o tema. As opções são um endpoint de pesquisa na REST API, um índice externo ou um índice estático gerado no build. Cada opção tem um custo de manutenção diferente.
Integrações de checkout específicas de cada mercado. Plugins de gateways de pagamento locais, seletores de pontos de recolha no checkout, exportação de encomendas para ferramentas de faturação. Estes plugins são escritos para um checkout renderizado pelo WooCommerce, por isso em headless têm de ser verificados contra a API do fornecedor e não contra o código PHP do plugin. São exatamente as integrações que surgem tarde na secção sobre o que atrasa o projeto.
Redirecionamentos. Uma exportação do plugin Redirection ou das regras do .htaccess, mais as listas de URLs do sitemap e da Google Search Console. Daí resulta o mapa de 301 aprovado na fase de scoping.
O resultado é uma tabela com três colunas: elemento, onde vive hoje, quem o reconstrói. As linhas sem responsável são semanas que o cronograma ainda não tem.
Quanto tempo demora migrar WooCommerce para headless
Uma loja WooCommerce com três mil SKUs e um checkout personalizado não migra em seis semanas. Quem cota esse cronograma está a vender um âmbito diferente e a renegociar mais tarde. A resposta honesta para este perfil é doze a catorze semanas.
Um site multi-região com cinco locales e fluxos de comércio específicos por locale também não é um projeto de seis semanas. Fluxos de tradução, validação de hreflang, estratégias de cache específicas por locale e integrações de pagamento por região acrescentam quatro a seis semanas mesmo a uma baseline saudável.
Quanto demora um site headless WordPress pequeno
Um site editorial pequeno, uma instalação WordPress fresca, um modelo de conteúdo limpo e uma equipa sénior conseguem entregar em cinco semanas. Cotar dezasseis para este perfil é âmbito inflacionado.
Um site headless greenfield (sem componente de migração, apenas um novo frontend num WordPress novo) salta a maior parte da fase um e encurta a fase três. Seis a oito semanas no total.
Quanto custa uma migração para headless WordPress
O preço é individual por projeto. Não publicamos preços de serviços no site público. O engagement letter liga horas às quatro fases acima, com um teto fixo na fase um (está limitada pelo número de entrevistas, não por algo que escale) e time-and-materials ou fixed-scope na fase três (consoante a estabilidade do âmbito após o scoping).
Faturamos em EUR ou USD, jurisdição UE, contrato B2B. Veja o pilar de serviços headless WordPress para o modelo de colaboração.
Como estimar por conta própria a duração de uma migração headless
As variáveis de que depende a duração podem ser verificadas antes de alguém preparar um orçamento. São elas que movem um projeto entre seis e dezasseis semanas; o framework muda no máximo uma semana.
- Catálogo. Contar as páginas editoriais e os SKU. Um site com menos de cinquenta páginas e sem loja é um perfil diferente de um WooCommerce com alguns milhares de produtos.
- Integrações. Listar tudo o que troca dados com o WordPress: ERP, gateway de pagamento, plugins sem superfície REST. Cada item descoberto só durante a construção significa um adaptador próprio.
- Padrões de URL. Exportar a lista de endereços e agrupá-los por estrutura. Trinta padrões são trabalho mecânico; trezentos com uma reestruturação de permalinks são um projeto à parte.
- Modelo de conteúdo. Verificar se o conteúdo está em custom post types e campos ACF ou Meta Box, ou espalhado pelos templates do tema.
- Equipa editorial. Indicar quem vai aprovar as pré-visualizações com regularidade e responder às perguntas da equipa.
Com esta lista, as primeiras sessões de descoberta servem para validar dados que já existem e vê-se mais depressa a que perfil do TL;DR o site corresponde.
Como expor tipos de conteúdo e campos na REST API e no WPGraphQL
O ponto sobre ACF da lista tem uma causa técnica concreta. Um custom post type não aparece na REST API enquanto não for registado com show_in_rest => true. Esse argumento acrescenta uma rota no namespace wp/v2, e o segmento do URL assume por omissão o nome do tipo, a menos que se defina rest_base (manual da REST API do WordPress). As taxonomias precisam do mesmo argumento em register_taxonomy.
O WPGraphQL tem o seu próprio interruptor. Um tipo de conteúdo entra no esquema GraphQL quando se definem show_in_graphql e graphql_single_name (camel case, sem espaços, a começar por letra). graphql_plural_name é opcional; sem ele, o campo de lista recebe o prefixo all (documentação do WPGraphQL). A mesma documentação descreve uma armadilha típica do headless: os pedidos anónimos devolvem entradas publicadas apenas se public ou publicly_queryable for true. Um tipo registado como não público porque o tema não tem template para ele devolve dados apenas a utilizadores com permissão de edição. A documentação recomenda então definir publicly_queryable => true de forma explícita.
Por isso o inventário da descoberta deve registar três valores para cada tipo de conteúdo: show_in_rest, show_in_graphql e publicly_queryable. Se faltar um, a alteração é no código de registo, não no frontend.
Como preparar o mapa de redirecionamentos 301 numa migração headless
A Google trata uma mudança de URLs como uma mudança de site e recomenda redirecionamentos permanentes no servidor (301 ou 308) de cada URL antigo para o seu equivalente, seguindo um mapeamento preparado antes da mudança. A mesma documentação desaconselha enviar muitos URLs antigos para uma única página sem relação, como a página inicial. Os redirecionamentos devem manter-se o máximo de tempo possível, em geral pelo menos um ano. Em sites de dimensão média a Google pode demorar algumas semanas ou mais a mostrar os URLs novos em vez dos antigos, e a visibilidade na pesquisa pode oscilar nesse período (Google Search Central sobre mudanças de site com alteração de URLs).
Quando o mapa é aplicado no edge, conta o limite da plataforma. O ficheiro _redirects do Cloudflare Pages aceita até 2000 redirecionamentos estáticos e 100 dinâmicos, 2100 no total, e cada regra tem um limite de 1000 caracteres. Mapas maiores passam para o Bulk Redirects (documentação do Cloudflare Pages). É por isso que o número de padrões de URL apurado na descoberta condiciona a arquitetura: trinta padrões cabem como regras dinâmicas dentro do limite, enquanto milhares de URLs avulsos sem padrão comum precisam de outro mecanismo.
SSG, ISR ou SSR e como a renderização afeta a publicação
A fase de scoping escolhe a renderização por rota, e essa escolha decide quando uma alteração guardada no painel do WordPress aparece no site. O Astro pré-renderiza por omissão páginas, rotas e endpoints no build. Uma página isolada passa a renderização a pedido com export const prerender = false, e output: 'server' inverte o comportamento por omissão em todo o projeto. Ambos os casos precisam de um adaptador de servidor (documentação do Astro). Numa variante puramente estática cada publicação implica um novo build, por isso o fluxo editorial precisa de um gatilho de build ao guardar um artigo.
O Next.js oferece Incremental Static Regeneration. A exportação revalidate define o tempo após o qual o pedido seguinte inicia a regeneração da página em segundo plano, e revalidatePath e revalidateTag invalidam a cache a pedido, por exemplo a partir de um webhook disparado ao publicar. A documentação enumera os limites: o ISR não funciona com uma exportação estática, o suporte nos adaptadores depende da plataforma e, com várias instâncias, a cache por omissão é própria de cada uma, pelo que a invalidação só chega à instância que recebeu a chamada enquanto não houver um cache handler partilhado (guia de ISR do Next.js).
É por isso que a pré-visualização e as publicações agendadas se acordam no scoping juntamente com a renderização, e não no fim da construção.
Artigos relacionados
Os artigos de apoio do cluster, por tema.
- Cloudflare Workers e WordPress no edge sobre a camada de runtime da nova stack.
