Migro o frontend de sites WordPress para Astro ou Next.js e mantenho a edição onde está, no WordPress. Chamo-me Mariusz Szatkowski, trabalho com WordPress desde 2006 e faço cada migração pessoalmente, sem equipa nem subcontratados. Antes de propor uma troca de framework, meço onde está o problema: muitas vezes basta corrigir a cache, as imagens ou um plugin que faz consultas em cada pedido.
Quando compensa migrar o WordPress para Astro ou Next.js?
Um WordPress com cache bem configurada já serve páginas prontas. A migração faz sentido quando o problema é o próprio frontend: um tema que ninguém se atreve a mexer, construtores de páginas que carregam muito JavaScript, ou um design que pede componentes que o tema não suporta bem. Também faz sentido quando quer separar o site público da administração, para que o WordPress deixe de responder diretamente a cada visita.
Isso altera a superfície de ataque, mas não a elimina. O WordPress, os plugins, as contas e a API continuam a precisar de atualizações, controlo de acesso e cópias de segurança.
O que recebe no fim
- Uma medição inicial. URL representativos com LCP, INP, CLS e TTFB medidos antes de qualquer alteração, e a camada responsável pelo problema identificada. Se bastar corrigir a cache ou as imagens, digo-lho em vez de vender uma migração.
- Um frontend sob controlo de versões. Templates e componentes Astro ou Next.js em git, publicação por compilação e pré-visualização antes de publicar.
- A edição no WordPress. As mesmas contas, os mesmos papéis, o mesmo fluxo de publicação.
- Formulários, integrações e redirecionamentos transferidos, com a lista de URL a verificar depois do lançamento.
- Um relatório antes e depois. Os mesmos URL, as mesmas condições de teste, as duas datas de medição e os seus dados de campo, se os tiver. Sem esse conjunto, uma percentagem é um objetivo.
Astro ou Next.js?
| Astro | Next.js | |
|---|---|---|
| Renderização por defeito | Todo o site é pré-renderizado; export const prerender = false ativa a renderização a pedido por rota | No App Router, layouts e páginas são Server Components; estático ou dinâmico depende da rota |
| JavaScript no navegador | Nenhum para componentes Astro; as ilhas interativas usam client:load, client:idle ou client:visible | O React hidrata os Client Components marcados com "use client" |
| Conteúdo que muda | Nova compilação ou rotas a pedido; server:defer para server islands | ISR com export const revalidate, revalidatePath e revalidateTag |
| Alojamento | Estático em qualquer servidor; para rotas a pedido, adaptadores oficiais para Cloudflare, Netlify, Node e Vercel | Servidor Node.js ou Docker; com output: 'export' perde ISR, Proxy, Server Actions e a otimização de imagens com o loader por defeito |
O Astro encaixa em blogs, sites institucionais e documentação. O Next.js justifica-se quando o frontend é uma aplicação com sessões de utilizador, dados por pedido ou alterações feitas no servidor. No Next.js 16 a convenção de ficheiro middleware passou a chamar-se proxy; tutoriais antigos que falam de middleware descrevem a mesma função.
E se o seu frontend já estiver em Next.js?
Há projetos que chegam com WordPress headless e um frontend Next.js que já não precisa de ser uma aplicação. O guia oficial de migração de Next.js para Astro descreve o caminho que sigo:
- Projeto novo com
npm create astro@lateste a integração@astrojs/reactpara reaproveitar componentes React existentes (ficheiros.jsxou.tsx). - Pastas:
public/fica igual; o resto passa parasrc/, e sósrc/pages/define rotas. - Layout:
_documentouapp/layoutdão lugar a um layout Astro com<html>,<head>,<body>e<slot />. - Dados:
getStaticProps()é substituído porawaitno frontmatter do componente, comfetch(),getCollection()ougetEntry(). - Sintaxe:
<Link>passa a<a href="">,{children}passa a<slot />e as props leem-se deAstro.props. - Imagens:
next/imagedá lugar aImagedeastro:assetsem ficheiros.astroe.mdx; dentro de componentes React usa-se um<img />normal.
O que depende de ISR ou de revalidatePath não tem equivalente direto. Resolve-se com novas compilações a cada publicação ou com rotas renderizadas a pedido.
Como é que o Astro lê o WordPress?
O guia do Astro para WordPress usa a REST API integrada em /wp-json/wp/v2/, por exemplo /wp-json/wp/v2/posts. As leituras públicas não exigem autenticação por defeito. Com _embed vêm também recursos relacionados, como a imagem de destaque, e com _fields limita a resposta aos campos que o template usa. O WPGraphQL é opcional.
Num site estático, rotas dinâmicas como /blog/[slug] precisam de getStaticPaths(). Com renderização a pedido não é necessário, mas cada visita consulta a API e a cache à frente do frontend volta a ser importante.
Cookies e consentimento ao trocar de frontend
Um frontend novo significa um banner de consentimento novo, e é aí que muitas migrações falham. A Lei n.º 41/2004, que transpõe a Diretiva 2002/58/CE, exige no artigo 5.º, na redação da Lei n.º 46/2012, consentimento prévio, com informação clara e completa, para guardar ou aceder a informação no equipamento do utilizador. Ficam de fora o armazenamento técnico necessário à transmissão e o que for estritamente necessário ao serviço pedido pelo utilizador.
Na migração faço o inventário de cada script do site antigo (analítica, píxeis, vídeos incorporados, chat) e no novo frontend nenhum carrega antes do consentimento. Em Astro isso costuma ser mais simples, porque o HTML não arrasta JavaScript de plugins que ninguém reviu.
Cenários habituais
Site de conteúdo ou blog
O caso mais claro para Astro. Os artigos mudam pouco e são muito lidos, por isso pré-renderizá-los como HTML elimina as consultas à base de dados em cada visita. A questão prática é a publicação: compilação automática depois de cada publicação no WordPress, ou rotas escolhidas renderizadas a pedido.
Loja WooCommerce
O catálogo pode ser estático, mas carrinho, checkout e conta de cliente dependem de sessões e de dados por pedido. Antes de propor um WooCommerce headless, verifico que plugins de pagamento e de envio dependem dos templates do WooCommerce, como os de MB WAY ou Multibanco que a loja já usa. Mais pormenores em migração WooCommerce headless.
Aplicação com utilizadores autenticados
Painéis, áreas reservadas e formulários com lógica de servidor encaixam melhor em Next.js, com Server Components para os dados e Client Components só onde há interação.
Como decorre o processo?
- Auditoria. Inventário de URL, templates, formulários, integrações e scripts de terceiros, com medição inicial.
- WordPress como backend. Desligo o que só servia o frontend antigo, preparo a pré-visualização e restrinjo o acesso à API onde for preciso.
- Novo frontend. Implemento o design que me entrega, em ficheiro Figma ou num modelo onde marca que elemento fica onde. Design gráfico e wireframes não são trabalho meu.
- Testes em staging. Redirecionamentos, metadados, dados estruturados, formulários, consentimento e analítica. Cada alteração fica descrita por escrito.
- Lançamento. Troca de DNS depois da sua aprovação em staging, verificação da lista de URL e da cobertura no Search Console.
SEO durante a migração
Os URL mantêm-se ou recebem um 301. Títulos, descrições, URL canónicos, hreflang, Open Graph, dados estruturados, robots.txt e o sitemap são reconstruídos no novo frontend e comparados com o site antigo antes do lançamento. Depois acompanho a cobertura no Search Console. Uma migração bem feita evita perdas; não promete subidas.
Como começar?
Escreva-me pelo formulário de contacto com o endereço do site, o que o trava hoje e que integrações tem. Recebe resposta por escrito com as perguntas em aberto e, depois da auditoria, uma proposta com os pressupostos em que assenta. Faturo como B2B com o NIF europeu PL7393037445 e autoliquidação do IVA.
Que serviços se relacionam com a migração?
- Programador Next.js, para projetos novos em Next.js
- Programador Astro, para sites novos em Astro
- Programador headless CMS
